CSS text-transform and clipboard functionality

Over at Twitter, some of us are trying to have a 140-character debate on how to copy text with text-transform applied. If, for example, a website specifies

p{text-transform:uppercase}

the text inside paragraph tags will appear in upper case even though in the source code it may be lower case or mixed case. If you copy this upper case-transformed text, what should end up on the clipboard? To test your current browser's behaviour, try to copy this text and see if you get lower-case or upper-case on the clipboard.

WebKit has fixed a bug saying that the copy operation should copy the case as shown, with the transform applied. Now, not everyone agrees that's the right thing to do and no other browser implemented it yet, so there's a counter-bug reported.

On Twitter we've been trying to figure out whether the case of a text is semantic or a style matter, and what the correct behaviour for plain text copying is. Kenneth Newman (@WraithKenny) builds a conceptual argument for copying "content, not style" on this reasoning:

I think that, like with color, if pasted into a program that doesn't support text-transform, the text should not be styled.

While Marcus Pope (@marcuspope) posted a more practical line of thoughts on pastebin:

In the event that a user copies text that was in ALL CAPS and they paste "All Caps" most editors can uppercase that for them if case preservation was important. But I'd argue the reverse is far more difficult – pasting "ALL CAPS", and desiring "All Caps" because people don't like to yell in text form, there are fewer editors that offer a titleize option. And when they do give a titleize option, Mr. McIntosh often gets screwed. So from a user perspective my desired option is most optimally reached when I paste the original case context, and in the rare case that I want to yell, it's only one or two mouse clicks away.

My view on this is of course informed by my background – and my first task at Opera was in customer support. I think we should above all avoid confusing users. The points above are valid, but trying to obey user expectations and avoid confusion is in my view more important than theoretical content/style distinctions and guesswork as to what might be more useful in a given situation. "WHY did the computer lower-case the text when I copied it?" is not just a question that will cause support requests and debugging time for soft- and hardware vendors and computer stores, it's also one of those little things that will add to the user's feeling of just not understanding or mastering this mysterious thing called a computer.

And that's what it's all about: giving the user a feeling of mastering her digital tools.

If you disagree or have other arguments, comments are open.

Advertisements

49 thoughts on “CSS text-transform and clipboard functionality

  1. What I would expect as a user? Either one of this scenario:# Scenario 13 copy choices, 1 paste. – "Copy Text" (default)- "Copy Text with style" (letters and colors)- "Copy Markup"# Scenario 21 copy choice, 3 pastes- "Copy" (with all the DOM context included in the clipboard)Then – "Paste Text" raw- "Paste with Style" rich- "Paste Markup" richerThe interesting thing is that MacOSX currently is applying the scenario 2 or equivalent. Except the user doesn't have the choice, but the application applies a choice for the user. See my screenshot.http://www.la-grange.net/2012/11/08/copy-paste

  2. "Copy Text with style" (letters and colors)

    But do you think users can/should be expected to understand that character case is sometimes "style" and sometimes "content"?

  3. From that quote i think Marcus Pope sees things a bit too black and white. What if you have a text where only some parts of it are in caps? To attract attention to important sections/words for example (some (legal) documents even require this). Having that text converted to lower-case would be very annoying. In order to get the original styling back you'd have to hunt down and manually alter every bit of text that was in upper case.Now, you could argue that the writer should have used caps in the source rather than rely on text-transform. But a) there's nothing the user can do about that. And b) You could equally argue the opposite, text-transform allows a more complete separation between form and content and allows greater flexibility in appearance.In sum, i agree that browsers should carry over text-transform when copy-pasting. Certainly, i think it's what most users would expect. After all, they don't usually know whether a text is shown in caps because of CSS or because it was typed that way.

  4. agreehowever computers should be smart, so there should be option to copy with style or copy without style, like in Office applications 'match destination/source formatting'

  5. In the case of "copy with style", what ever is the original content, the results will be the same no?"Boo" with CSS uppercase + copy with style = BOO"BOO" with no CSS + copy with style = BOOThe issue arises when you do "copy text". There are also:"BOO" with CSS lowercase = boo"BOO" with CSS capitalize = Boo"boo" with CSS capitalize = BooSection titles of English articles. CSS "capitalize" could/(should?) be used for titles?

  6. I use text-transform instead of .toUpper() for that precise reason (provide the normal case to copy actions). What is the point of having two functionnalities if they produce the same result?

  7. In my humble opinion, we should stop thinking as developers and think of the user. If I knew nothing about Web programming and did a copy and paste of uppercase text, I would expect that no matter what. My 80 year old Dad would go nuts if it didn't do this, and that, ultimately, is what I think of when I hear about UI decisions like this. Trust me… You don't want my heart my Dad when he goes nuts over stuff like this…., 🙂

  8. Most people arguing for WebKit's new behaviour are putting emphasis on what the user expects. As a user, when I copy text I expect to copy *WHAT THE AUTHOR WROTE*, not what the designer wrote (regardless of whether they may be the same person).If, as an author, I want my text in ALL CAPS, I will hold shift or put Caps Lock on. CSS text-transform is a 100% stylistic alteration, and – most importantly – highly dependent on visual design context.If WYSIWYG editors were to start doing something mad like this

    <span style="text-transform: uppercase">all caps</span>

    when capturing a keypress of Shift or Caps Lock, then perhaps this proposal might have some weight but otherwise it's ludicrous.

  9. Originally posted by lucideer:

    Most people arguing for WebKit's new behaviour are putting emphasis on what the user expects. As a user, when I copy text I expect to copy *WHAT THE AUTHOR WROTE*, not what the designer wrote (regardless of whether they may be the same person).

    A distinction the average user does not and cannot make. He sees text in all caps and (i think) expects those caps to be copied over. EDIT: For that matter, you or i don't know either untill we take a peek at the source. Would you seriously not be, at least initialy, confused and annoyed when caps were not carried over?

  10. As a user when I copy a text, I want it to be pasted exactly as it is shown to me on the page, because thats what a copy is.But 'text' means plain text to me, therefor I dont want to copy the style (weight, color, size).Technically seen a text-transform is style, but how can an average user know if the original text is written or styled uppercase? They wont look in the source code for this to know. But they see when a text is colored, styled or has a different weight.And I would get really angry if I copy an uppercase shown text TESTTESTTEST and have it pasted as tEsTTEStteSt only because the author of the text is too lazy to correct every error he made and instead decided to uppercase everything to hide it.

  11. At first you should consider what for text-transform:uppercase is used. So if it used for emulating small-caps—which most fonts doesn't support—along with smaller font-size but larger font-weight and letter-spacing or so, then it's totally wrong to copy text uppercased.On the other hand, based on user expectations, I believe, it would be wise to copy formatted text lowercased with a style like text-transform:uppercase, but just uppercased if it's non-formatted text.

  12. I would say content. Otherwise you can get different copied content from the same source but with different userCSS. That's also confusing.Furthermore if style (text-transform) is set as inherited, the content should take the style of ancestors elements. After paste, it should not have a style of it's own. That breaks when you copy with style applied…Confusing for the user? Maybe for the ignorant? Please learn the difference between outward appearance and quintessence.We shouldn't judge people by their looks, why should we judge text.luckily I just created:https://addons.opera.com/en/extensions/details/change-case/

  13. The end user is going to see this text in upper-case, and that's what he will expect from his clipboard. He is unconcerned with the authenticity of the words, and whether they accurately portray the original author's intent. And it's not the same thing as colour or other markup. This alteration affects the content of the text, this is much more akin to the designer or page creator altering the text, not just decorating it. And when a user copies this text, he's copying from the altered content page, not direct from the author's output.Copying something in upper case and pasting lower case would be as frustrating and confusing as copying something that was translated into English and getting a paste in the original Greek. It's not what I see, it's not what I expect, it's not right from the user's perspective.

  14. Now that I can use more than 140 characters, I can better explain my position.As dahulevogyre and lucideer pointed out authors/designers intend text-transform only as style. If case is content, either the source will be in uppercase, or JavaScript will be used. This issue is only an issue when text-transform is used, which is a rare (its usually in the source) and the only case for using it is when the case is style, not content. If uppercase is part of the content, as in legal documents, the uppercase will be copied as content, because text-transform isn't used for that.As for user expectation, text-transform will only be used when the style case and content case differ, some users will be confused and disappointed either way. I appreciate, as does Marcus Pope, when the browsers copy the actual content. Other users will be disappointed if the case appears to change. Marcus pointed out the pragmatic benefits of not changing the content.My proposal is to make available the style information as is done with color, so that if the program being pasted into recognizes it, it can style it. Since I don't know any program that does, this would be effectively the same as doing nothing for now. I do feel that this isn't a problem that browsers should solve, and certainly, not in a destructive way (i.e. modifying content).Additional thoughts: Stylistically, uppercase is sometimes intended to match the graphic design, but sometimes semantically intended more as a Strong, or Emphasis. The easy way to tell is if the text-transform is attached to a tag that has semantic meaning. For example, the restyling of a strong tag to use uppercase in place of bold, could be reflected in the pasted program by its default handling of strong (i.e. bold), if it supports it. How do browsers currently handle strong and em information? What about strong which is font-weight: normal? (Just some thoughts.)

  15. ouzowtf: To answer your question, the above average user can tell the when its just style by if it's only applied via css. An average user can tell by how it looks when they paste it. I think we may be underestimating user intelligence here. As for that thing that makes you angry, it makes me angry too… at the lazy author. 😉

  16. Just because the content can be changed to emulate the style doesn't mean it should. If that user copies a 30px bold red uppercase paragraph and paste into a program that doesn't have style capabilities, won't that user still be confused when the text is 16px black normal (whether it's uppercase or not)? The only difference among the 4 example styles is that only one can be emulated through directly modifying the content. I don't think it's the browser's place to "fix" this.

  17. "case-transformed text"? Some users are asking to do "copy with format" over ten years! :irked: "THIS TEXT" – only with "designMode=on" Opera "copy" like it should.If you can`t paste text with the style, it's not problem of copying… Style doesn't change content, it only changes its look, any case conversion broke this rule. It should only depend where you past it, like Newman sad.Opera already does a lot of things that are "not as you expect", why add more?When you copy image in opera 12.xx alpha channel (transparent part) replaced with black color, although earlier and in other browsers – white.

  18. @Ken NewmanSo you rather confuse 90% or more of the users bad-mouthing their browsers (and computers in general) because of absurd behavior and wasting their time by fixing pasted text, not even understanding why its broken from what they copied?Sometimes it really makes sense to differ between 'copy plain text' and 'copy text with style information' (color, size, weight) and there should be a possibility to choose. But I dont want to be the guy trying to explain every average user again and again why a copied text is pasted different and why capitalization is sometimes considered as a style and sometimes not. Color, size and weight will be understood as style, but not capitalization. I bet that you dont want to be this guy too.

  19. (Would love to have copying of rich text + plain text to the clipboard like other browsers, so adding that into the suggestion below.)For the 'copy' action in Opera's command system, make use of the 2 parameters the action can accept.The first parameter is the copy-type flag:0 (default) : rich and plain text (where both are available on the clipboard)1 : rich text (if available)2 : always plain textThe second parameter is the copy-transform flag:0 (default): honor case transform1 : ignore case transformSo, the default 'copy' action that we currently have would be the same as:copy, 0, 0(so, you could express it as just 'copy')Then:copy, 0, 1would be tied to a modifier key to ignore the transform when copying.There could also be an opera:config option to flip the case transform values so that they do the opposite. This would allow users that don't like the default to *easily* revert to the old behavior.There could also be an opera:config option to change the default for the first param too.There could be 2 more values for the copy case transform flag:2: honor case transform (ignore opera:config flipping option)3: ignore case transform (ignore opera:config flipping option)if it'd be beneficial to advanced users.Also, since the commands can be used separately, advanced users could add *separate* menu entries/buttons/shortcuts for each command if they want.The first param could even be controlled by a modifier key too. For example, in addition to the default 'copy' action and the one with a modifier key to change the case transform, another modifier key could invoke:copy, 2, 1for example.so, just by adding some opera:config options, the reading of the params passed to the 'copy' action and some adding of keyboard shorcuts (and maybe buttons not shown on the toolbar by default), Opera should be able to take care of all the angles. Then, it's just a case of what the default should be and if you see above, my suggestion is to copy the transformed case by default.(I know Opera is afraid of adding more options, but I love options.)

  20. Originally posted by wraithkenny:

    This issue is only an issue when text-transform is used, which is a rare (its usually in the source)

    I think it's used quite a lot in heading (h1 etc), legitimate goalOriginally posted by ouzoWTF:

    But I dont want to be the guy trying to explain every average user again and again

    You should sell financial derivatives.IMHO there is a difference between content and style (and thus also in web), they should teach that on schools, once you know that knack, it isn't that difficult, just surprising sometimes. It's quite common thoughh that you lose some with copies, not all are lossless ;)Like said above, copying with style IMHO isn't that easy when style is inherited, it isn't the style of the text, it's the style of the document. Should you copy the style of a div, when you copy a child p, and paste it in another div?

  21. Originally posted by Janghou:

    IMHO there is a difference between content and style

    Yes, of course, but how can the average user see the difference between uppercase text and uppercase styled text? They wont look at the source code or at dev tools trying to understand the problem. And even when they understand, they have to change the text manually.Conclusion would be that they curse the software and computers for not doing what they want and/or call their tech-savvy friend to fix the problem. Both will be dissatisfied, because "fixing" is not really possible.Originally posted by Janghou:

    they should teach that on schools, once you know that knack, it isn't that difficult, just surprising sometimes.

    Yeah, lets wait 5 to 10 years till some schools maybe start to teach this. Those students will then swarm out to teach their knowledge to the average users in the world. And when they are done, they ride home on their unicorns.

  22. I'm with burnout426. My right-click menu already contains regular copy, copy with formatting and copy source. I usually want plain text copy (without text-transforms or anything), but not always. What should you do? Both. Let me choose. What should be the default? Unfortunately, probably not what I'd like to be the default (i.e. plain-text copy without transformations).

  23. text-transform is considered harmfull – scratch it from the CSS specification.rationale:If I want to write UPPERCASE, I do it like that – as I do With every Other case, eVEN if It is WrOnG.There is no need to do it by "style" because each and every keyboard I know has a Key for that, even touch keyboards, if they are meant for serious writing. The Capitalization Rules are not so easy to understand for non-native English speakers like me. @Karl Dubost: See rule #8 here:http://www.grammarbook.com/punctuation/capital.aspCapitalizing every first character of a word in a Headline might be wrong in most cases…. back to topic:I would prefer copying the plain text nodes, not the styles when doing a normal copy. May be "carbon copy" or "copy with styles applied" option can be added as an option for users who prefer different.The solution of Michael A. Puls II seems to be too convoluted, this is a thing for normal users and not Geeks|Nerds etc. as we are. In my experience normal users do not alter settings in opera:config unless someone points them at doing so, instead of that a second entry in the copy pop-up would give a clear hint about the two different options.

  24. As some users would be upset that what they see is not what they get, I would be upset if I would need to manually fix words to their correct form because a browser decided it would be a great idea to transform the case of the text (and therefore break it!) to match previous visual appearance.What about other cases where the user doing copy operation couldn't directly see whether the visual appearance is content or style? For example an image which is clipped using CSS. As far as I know, all browser with "Copy image" copy the whole image, even the parts not visible to the user. Or if the image is translucent and there is a background property attached to it, is the result of copying that image the original image or with the background superimposed on it? In each of these cases the user couldn't originally know whether the image had been modified with CSS or not. Why should text be treated differently?

  25. Originally posted by Frenzie:

    My right-click menu already contains regular copy, copy with formatting and copy source.

    … but "copy with formatting", which I have in my context menu too, does not copy all of the formatting and fails with text-transform (just tested) and copy source does just copy the source but can not apply CSS that is not inline.PS: Internet Explorer copies "uppercase" transformed text as uppercase but fails with "capitalize", Chrome copies WYSIWYG; So two of the 4 major engines apply some of the styling …

  26. I think you should be considering more important problems in Opera development than the case of copied text. As a developer, I know to expect it to happen sometimes (you can usually guess when text is uppercased by css) and it doesn't surprise me when it happens. Most users are not going to care much either way for short snippets and for a long one that's been stylistically uppercased they'll probably be glad to get proper case, but unsurprised if not.Either behavior makes f*ck all difference to me, in this case it's probably better to just leave it how it is, and if the topic is revisited later and it's found that Opera is the only inconsistent browser in this behavior then change it just to fit in, because it really doesn't matter.

  27. Originally posted by QuHno:

    … but "copy with formatting", which I have in my context menu too, does not copy all of the formatting and fails with text-transform (just tested) and copy source does just copy the source but can not apply CSS that is not inline.

    I didn't mean to imply it's equivalent, merely that I already actively use as many copy options as I can (albeit plain-text copy more actively than the others). Like I said, I fully support everything burnout246 said.

  28. Originally posted by QuHno:

    I don't – because it is geeky and the average user is not as geeky as we are.

    What I suggested was more for the implementation side. All of it is hidden to a regular user by a good default (whatever Opera decides is the good default).

  29. Originally posted by QuHno:

    I don't – because it is geeky and the average user is not as geeky as we are.

    What goes in the default GUI is a completely separate discussion to which I'm largely indifferent. I do not use Opera for its default GUI or keyboard bindings. (However, I think there should be some kind of "advanced" interface, reminiscent of the Opera 7.x days, that does a much better job of exposing all kinds of built-in functionality to newbies through menus.)That being said, everyone I know understands and loves the Microsoft Word option to special paste without formatting, so I'd wager they'd understand copy without formatting and copy with formatting just fine and would appreciate the option. They may not appreciate copy without text transform (with or without formatting), but I would.

  30. Hm, may be we forgot something:I did a little test today with a simple page I set up with various text-transforms and other styles and asked 11 "normal" people to paste the text into the applications they used for daily work. While my study was in no way representative, it gave me a little hint about the expected behavior:For me, the most interesting part was watching the initial reaction when a text containing "uppercase" was pasted: I heard several "WTF?! What went wrong?" when they saw the paste …After looking what they did I asked them what they expected:10 of 11 people used some flavor of Office or similar to work with normal text and 9 people wanted the text copied in the case as they see it. Same goes for Styling that results from semantic elements like UL or H but not everything. Colors borders etc. were almost a draw, 4 wanted it, 4 didn't and the rest answered with "it depends".If they pasted it into some flavor web application, 10 of 11 wanted the text transform, because in most of the web applications there is no easy way to correct the styling afterwards.Interestingly I heard no complaints about not pasting "capitalize"d but that might depend on our language, we don't capitalize words in a headline different than normal because our language is case sensitive. (hint: different languages and cultural behaviors must be taken into account in this discussion too)I think we can mull over this a long time, but as long as nobody takes a bigger group of of average users (which normally do not look into source codes of any kind) and looks at what they do, not what they say -especially the first reaction and then in which way they re-format the text -, we never will get the right solution for the problem.

  31. Perhaps instead of worrying about the copy-paste feature, you should be lobbying the standards people to remove text-transform from the spec?

  32. I'm sorry, I was just being snarky. I apologize.I just did a test using FF and Mail on Mac. I copied text with a text-transform: uppercase on it. I pasted into the subject line and body of a new email. In the subject line, the text-transform was not applied. In the body, the text-transform was applied. I think this behavior is what browsers in general should emulate.Browsers should try to do the "right" thing up until it's out of their control, and not preemptively try to "fix" things. In the case of FF and Mail, FF appears to hand off the info, and Mail appears to make the call based on it's own context.

  33. Originally posted by wraithkenny:

    Perhaps instead of worrying about the copy-paste feature, you should be lobbying the standards people to remove text-transform from the spec?

    Why should it be removed?

  34. Perhaps twitter was a better medium to discuss this issue considering how much more confounded we've made the problem here with unlimited word counts 😉 (jk)It's doubtful many will even see these points given the number of comments already, but since I was quoted and referenced I figure I'll add two more cents to the jar. Here's where I see things differently:Here are my base assumptions from which I build my position (they're not meant to be debated as they are simply opinions, they're here simply to explain how I frame my other points below): I don't think this issue is a big source of confusion for the average user since the behavior hasn't really changed in 20 years. I think that knowledge is cheap to obtain – telling them that the browser is copying the content as the author typed it versus how the designer styled it clears up any confusion. I think other problems wrt pasting content cause greater confusion to end users than case context. I think that computers should infer what the user intended versus be strict in its computation (when done appropriately this works well like a good autocorrection algorithm, there is no need to point out when this has failed in the past.) And I think that when a behavior of a computer makes a user do more work than would otherwise be necessary even under the worst of outcomes, the computer has failed its purpose.1. 80/20 rule, how often do you copy and paste text-transformed context and think "Darn, I wish that had kept all of the uppercase text?" I'd say it's pretty rare given that most people don't like all caps – even people who type with all caps by default are a rare breed these days. Most developers create content properly – using text-transforms to uppercase header elements, and actually upper-casing content that should be in all caps like acronyms so typically your experience will match your intentions. Rarely if ever would legal content be all lowercase in content, yet marked up with capitalizations via CSS, forcing the user to reapply all casing as in the example provided by @Zoltan. In all cases where you wish it had kept the entire word or sentence in uppercase, it probably will because the author probably created it like that, but even still most editors can do an amazingly accurate transform on the text to meet your needs in two mouse clicks effectively O(2) processing. In all cases where you wish it had not copied over all uppercase characters and instead whished it had used title case as it was entered – the #1 use case when copying an article titles uppercased in an h1 with a transform, your editor will very wrongly uppercase the first letter of each word, if it even supports such a feature at all. Since most don't, you are left with O(n) changes to your text to lowercase the remainder of every word. And even when you do have this feature – Mr. McIntosh has to go back yet again, and fix his name capitalization by hand (and it's not just McIntosh's name that's the issue – iPhone is a far more common problem word for titelize() algorithms.) This is not a black and white issue, this is an 80/20 issue – I recognize that there are use cases for keeping the capitalization, but there are good and easy solutions for that problem, and they start with the creators of content, not the end users.2. Kenny is right in that people are a lot more intelligent than they're given credit for, speaking from a career of end user support under various roles, I know that end user support is a concentrated sample set of ignorance(see 80/20 rule) that is not representative of the general end user base, so *most* users are intelligent enough to understand the reason. The comments in the bug ticket like: "Any other result would be […] impossible for me as a user to explain." are ridiculous hyperbole… Impossible??? Really?? And the strictness in which some are applying "user expectations" is unrealistically extreme – "The end user is going to see this text in upper-case, and that's what he will expect from his clipboard" (As a user, I expect proper title casing when I copy the title of a news article even if it was bolded in all caps.)3. Under no circumstance will we ever be able to explain every aspect of computers to everyone because both the x and y axis are infinite. So you have to make pragmatic decisions that take that into account, and in this case I think letting any trivial amount of user confusion that exists in the world on this issue continue in lieu of making the millions of people who write research papers and essays tediously alter the casing of bibliography text every time a designer thinks the art direction of a header is best represented by all caps.4. @KafeneSoftware is about the only person on this thread with som real world sense. Everyone else (including myself) is speaking in ideals and absolutes. On one side – people expect the text to copy exactly as they see it in all scenarios because all users would expect it and making any assumptions otherwise would be bad and impossible to explain. On the other side, people expect the source to be copied as written because it would make the user's life easier in almost every case – even if a small degree of confusion entered into the equation. The only case where it makes their lives more than trivially harder is when the author doesn't create the content with proper casing to begin with which was the overlooked crux of @Zoltan's first point – but that's not a user problem, that's a developer/content creator problem.5. @QuHno – The fact that most of your users were shocked in your survey show's how effectively the paste behavior worked for them as they expected it to, in the contexts that they were using it in the past. Otherwise they probably would have said WTF every other time it happened to them in the last decade and they would have told you up front how frustrating it is before they even started the survey. The real insight from your study was that this was the first time most even noticed it. People generally expect the paste to operate in the same way an author would intend to write it, so in reality the paste behavior is usually not a surprise even when the casing does change.6. @Joonas Lehtolahti makes the other great point about this topic which is that paste behavior is wrought with quirks and deficiencies that people deal with all the time. I don't think that makes the computer any more mysterious to the general populace. And I don't think there is a one-size fits all approach to the paste problem, so again, ideals are not best applied to this problem.If we can move past the discussion of assuming what user's want, and that every user wants the same thing, and simply start discussing the consequences of the design, I think we can create a pretty clear chart of when source-case copying is beneficial and when rendered-case copying is beneficial. Included in that chart should be how easily the problem is rectified when it goes against the user's intentions. For me, that comes down to how easy it is to titleize() (either manually or programmatically) and how prevalent that use case is in education and research.

  35. Originally posted by QuHno:

    because it is case sensitive, e.g. Weiß vs weiß (transl.: white vs know, knowing), Wagen vs wagen (transl.: car vs dare).

    Off topic, but that's not quite true. Language is first and foremost spoken, where you have no capitalization or spelling to help you out (such as flour vs. flower). But perhaps more important, no one could ever confuse the examples you gave because they're nouns and verbs. "Ich habe ein Wagen" will not be confused for anything else if you spell it "ich habe ein wagen."None of that discounts the fact that text-transform would have adverse effects on the proper written form and is therefore presumably less likely to be used, but the argument that it would otherwise be confusing is clearly disproved by spoken German. 🙂

  36. Originally posted by marcuspope:

    The fact that most of your users were shocked in your survey show's how effectively the paste behavior worked for them as they expected it to,

    Nope, it just showed that we usually don't use those transformations in our language because it is case sensitive, e.g. Weiß vs weiß (transl.: white vs know, knowing), Wagen vs wagen (transl.: car vs dare). The all uppercase loud crying or capitalization of the first letters of a word in headlines (which afaik is wrong in English headlines too when done indiscriminately) normally does not happen here, so the normal user does not run into such problems.For me this issue could be resolved in a very simple manner: 2 copy options, one plain as it is now and one with full formatting and all transforms. Let the user decide where (s)he clicks, plain and simple and easy to understand for everyone after the first time. May be an additional option somewhere in the preferences for setting the default Ctrl+C (copy-gesture, -touch, -whatever) behavior for people who prefer one of the copy types.PS: Ctrl+Shift+C seems to be free to use for formatted copies.

  37. There is a lot spoken here, I still feel it should copy the source: that way you copy the text as the author meant, not as the lay-out is showing.But on the other hand it makes sense to copy WYSIWYG.What confuses me the most is that Opera can have multiple selections (in forms), then it's absolutely not clear what will be copied.Screenshot@Hallvord, is there a reason Opera can do this? in FF and Chrome it's not possible.

  38. Originally posted by Zotlan:

    EDIT: For that matter, you or i don't know either untill we take a peek at the source. Would you seriously not be, at least initialy, confused and annoyed when caps were not carried over?

    In theory this may hold true, but in practice content is king and formatting would – I believe – generally be considered by a user (even a completely technophobic one) to be context-specific.At least in the English and in most European languages, capitalisation is generally standardised throughout a language. In English – for example – the standard is for the first character in a sentence, "proper nouns" and nouns, verbs and adjectives in titles of artworks, to be capitalised. Outside of this, capitalisation is generally exclusively used to impart tone.As such, when copying and pasting text, tone is the only thing that would be intended to be carried with the text. If the text is TO BE SHOUTED LIKE THIS, it would be capitalised in source, and not via CSS. If it's not intended (either by the author or the copypaster) to be SHOUTED!!!, then neither would it be capitalised in source, nor would the copypaster ever want it to be.I agree they may be surprised copying some capitalised text and seeing it pasted "normally", but I can only imagine any average user would always be "pleasantly surprised" at this behaviour as any normal (English-speaking at least) person would usually manually uncapitalise text after pasting in order not to impart an inappropriate tone.Furthermore, to the case of using text-transform:lowercase;, I really can't imagine any case were a user would want any text to be pasted all lowercase. Even if they copied the middle of a sentence, they would either:(a) capitalise it after the fact after pasting(b) add quotation marks with preceding and proceeding ellipses(c) be too lazy to capitalise it properly, but would certainly appreciate it being done so for them automaticallyEither way, pasting author's content over displayed – while it may not be "expected behaviour" – will ALWAYS be eventual "preferred behaviour" regardless of the level of technical knowledge of the user.You can of course quote the "Principe of Least Astonishment" but I think this is a definite exception – this is a principle that only really applies when "astonishment" is synonymous with "annoyance". One shouldn't assume that what a user expects and what a user wants are always the same thing.

  39. @lucideer: I emphatically disagree. As I stated earlier, when the text is capitalized it's basically changing the content. The middleman (publisher) is changing the source author's text. This is a content change, not a decorative change. If you're correct that the author's content is most important, I have to ask: which author? The one who wrote it originally, or the one who changed it before I saw it?I've got several decades of copy/paste experience that says decorative styles are usually thrown out and only the basic ASCII (UTF8 now I suppose) remains. This is what I expect, and what I want. To reiterate my earlier point: this is just like copying an English sentence and pasting a Greek one because the source I copied was translated from the original. The original is not important to me, I'm copying what's on the page in front of me.

  40. Originally posted by Janghou:

    Screenshot@Hallvord, is there a reason Opera can do this?

    That screen shot shows an interesting case – Opera normally distinguishes the "active" and various non-"active" selections by colour, but it seems your screenshot is taken from a web site that uses CSS to style selections, overriding the active/non-active distinction. (Quite possibly, CSS has no concept of a non-active selection). It certainly ends up confusing!

  41. @HallvordIf I try e.g. http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_form_submit then other browsers deselect whatever was selected while in Opera all selections remain and keep the same color. This is a deficiency in Gnome I never noticed before. In the Gnome appearance dialog I cannot choose an inactive selection color like in opera:config#Colors|SelectedBackgroundUnfocused Nor does there seem to be any option to do it manually in the theme file. So it may have to do with the platform or the user's own selected colors rather than the website.

  42. Originally posted by NFGman:

    The middleman (publisher) is changing the source author's text. This is a content change, not a decorative change.

    If this is true, then CSS should not be used. It should only ever be used if this is not the case. If you believe any change is always a content change (which I disagree with) then you should argue for the removal of the CSS "text-transform" property, not the misuse of copy-paste in its presence.

  43. After some further reflection I agree more with lucideer and renounce my earlier view that applying text-transform in regular copied text is probably a relatively decent idea as the default.text-transform:lowercase|uppercase (capitalize is useless) is really no different than font-variant:small-caps. It's something that, as an author, I might apply to e.g. the :first-line pseudo-class. Would I then want whatever visually turns out to be the first line to be copied in uppercase into a program where the first line will be something else entirely? Only if I put it there in the source without any CSS changes.I chose this example very consciously: I remember quoting parts from newspaper articles where the first line was in all-caps. I consequently had to spend time changing that. I would've been pleasantly surprised if that hadn't been necessary. I also recall adding proper capitalization to lowercase text. I don't recall ever changing normal text to all-caps, or normal text to all lowercase. Besides, it's much easier to change normal text to all uppercase or all lowercase than it is to change text in either of those forms to a proper combination of upper- and lowercase.If someone's using text-tranform as anything other than a mere stylistic effect, they're doing it wrong.

  44. Originally posted by Frenzie:

    So it may have to do with the platform or the user's own selected colors rather than the website

    Aha, this is interesting. I can see why Opera's behaviour is confusing (and therefore wrong) if the platform itself has no "inactive selection" concept..

  45. IMHO Opera's behaviour is confusing because it CAN HAVE MULTIPLE selections. In Ubuntu / Unity / Gnome / XFCE all selections have the same color by default. My OperaAFAIK in Windows Opera can't have multiple selections( tried in Windows 7)Do we consider this *nix behaviour a bug or a feature?Originally posted by Zotlan:

    EDIT: For that matter, you or i don't know either untill we take a peek at the source.

    I fail to see that. userCSS important has the highest priority in the CSS cascade.* {text-transform:none !important;} will overrule any author CSS and by that disable text-transform effectively. That's why I said above that copying with style will raise more confusion, because people on different computers will copy different things from the same site/content, because they have different userCSS styling defaults. Maybe userCSS isn't used that much, it makes Opera shine for me. It's power is underrated, and I never understood why Opera dropped the button on the default toolbar.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s