| Summary: | text-transform shouldn’t apply when copying text | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Mathias Bynens <mathias> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | 247fetishstore, ap, aroselli, beidson, code, dauwhe, dev, hi, info, johanneswilm, jwieczorek, kojii, mathias, m.goleb+bugzilla, mmaxfield, paulirish, pioupioum, plroskin, tomac, webkit-bug-importer, wraithkenny, xfq.free, zzeligg |
| Priority: | P2 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://jsbin.com/iqice3 | ||
|
Description
Mathias Bynens
2010-07-29 11:13:28 PDT
Test case: http://jsbin.com/ewaqu This should be fairly simple to fix. Looks like RenderText::textWithoutTranscoding() should not include the text transform. That function is only used in TextIterator so there shouldn't be any side effects of such a change. (In reply to comment #2) > This should be fairly simple to fix. Looks like RenderText::textWithoutTranscoding() should not include the text transform. That function is only used in TextIterator so there shouldn't be any side effects of such a change. Actually, it's a bit more complex than I thought. *** Bug 101478 has been marked as a duplicate of this bug. *** This behavior is intentional per bug 3429. It's not obvious to me which behavior is really preferable. From a web developer's point of view, when I use a text-transform in CSS (as opposed to changing the text of the html source) the intent is pretty clear. I think an approach similar to the copying of color would be more appropriate then modifying the content itself: Copy the style information, and if pasted into a program that understands that data, let it apply its style. I prefer to look at this from user's point of view. When I copy text that looks like "ABC", I expect pasted text to look like "ABC". Any other result would be surprising and impossible for me as a user to explain. Unlike color, font family etc, there is no way to preserve text-transform in pasteboard for receiving application to make its own decision. Capitalization is more likely to have semantic meaning than color, so I think that it's correct that platforms don't treat it as part of style. I am also a user. I don't like my browsers altering content to preserve style. I find it surprising and disappointing. From a user point of view, the not-impossible explanation is, "Oh, I guess the shoutiness was just an effect." I won't underestimate the users intelligence or ability to learn from experience... unless of course you nerf their experience. Yes, letter case isn't always style; sometimes it is content. But in those cases I don't use text-transform, and no one should. The only time I (and every other developer I know) ever uses text-transform, is to explicitly declare that the case is ONLY style. I just test the clipboard using the Mac version of Firefox and Mac Mail as the pasting program. The sample text had various variations of text-transfrom, and also font-weight as a control group. I pasted the sample text into the "subject line" and the text appeared without font-weight and without text-transform applied. I then pasted into the message body, and the styles including text-transform where applied. This to me seems the proper behavior. Information regarding text-transform was presented, the pasting program (Mail) decided whether or not to apply the style in different contexts. This shows that the clipboard is capable of preserving this information separately. It's been done. > I won't underestimate the users intelligence or ability to learn from experience. Again, there would be no way to know at copying time whether the case would be preserved or not. I appreciate that this is not the case for you when you are copying text from a website you designed yourself, or when you are frequently copying text from the same site, but it's hardly the common case. What a user would be able to learn from experience in normal scenario is that text copying works erratically, and the computer cannot be trusted. > This shows that the clipboard is capable of preserving this information separately. It's been done. This is not something to argue about. If you want to study the inner workings of pasteboard, empirical testing will likely be confusing. You can read Apple's documentation about pasteboard flavors, and/or use an application like Pasteboad Peeker or Pasteboard Inspector to see what is actually inside a pasteboard. FWIW, I cannot replicate your results with OS X 10.8.2 and my own test case, but I don't think that this is important in the context of this bug. Eric Bidelman just posted a tweet in all caps because of this bug. https://twitter.com/ebidel/status/306437191956045825 $priority++; (In reply to comment #9) > > I won't underestimate the users intelligence or ability to learn from experience. > > Again, there would be no way to know at copying time whether the case would be preserved or not. I appreciate that this is not the case for you when you are copying text from a website you designed yourself, or when you are frequently copying text from the same site, but it's hardly the common case. I "appreciate" the tone of your response which is condescending. > What a user would be able to learn from experience in normal scenario is that text copying works erratically, and the computer cannot be trusted. > > > This shows that the clipboard is capable of preserving this information separately. It's been done. > > This is not something to argue about. If you want to study the inner workings of pasteboard, empirical testing will likely be confusing. You can read Apple's documentation about pasteboard flavors, and/or use an application like Pasteboad Peeker or Pasteboard Inspector to see what is actually inside a pasteboard. A popular browser figured out how to not alter the content while preserving the styles for pasting. > FWIW, I cannot replicate your results with OS X 10.8.2 and my own test case, but I don't think that this is important in the context of this bug. If you weren't able to replicate my results, try downloading FireFox first. Pasting text-transfromed text into the body of Mac Mail (for example) should appear transformed, and pasting it into the subject line shouldn't. Stating that users would be confused to the point they won't trust the computer is quite exaggerated. Especially if (all?) other browsers do not behave like that. I actually ended up reading about this issue here because one of my users was complaining of the odd behavior of Webkit when they pasted text-transformed text and asked me if it was possible to have it behave like Internet Explorer and FireFox. I guess user confusion happens no matter what, so it shouldn't be the deciding factor here. If you look at any other CSS property, absolutely none persists within the context of plain text (it's the whole idea behind CSS). Of course, if you paste in a Rich text or HTML context, then CSS formatting should be applied. Clipboard/Pasteboard functionaly has been designed so that data can be represented in different formats. This is precisely what "Paste matching style" on MacOS and "Paste Special..." on Windows do. So I will have to agree with others on this issue and ask that the actual source text (before transformation) be the text copied to the clipboard **when plain text is expected**. It is the destination context which chooses the representation it prefers. The source should not impose a given text transformation. Please keep the existing behavior. The website contents comes from different sources. The text author doesn't always have full control over the whole HTML that is served to the user. I'm using a Mediawiki based system at work, and the only way to show the uppercase version of the username is to use text-transform. It is used in step-by-step instructions, and I want users to copy and paste commands to the command line and run them without editing. Chrome users can do it. Firefox users end up with a wrong command (lowercase username). So I decided to report a bug to Firefox (there is one already: https://bugzilla.mozilla.org/show_bug.cgi?id=35148) and found it quite surprising that somebody is questioning the WebKit behavior. Removing all styles is not what users expect. They cannot see all styles on the screen. They can see font variation, color or indentation. But they cannot see if an upper-case letter on the screen was lower-case in the source. If the user decides to copy and paste text, they expect an accurate translation of the screen text to plain text (if the paste target wants plain text). Changing case silently is very unfriendly to the user. Curious if this bug will be addressed. Ideally I'd like to bring it in line with other browsers (IE, Edge, Firefox) and have it copy the unstyled text as it appears in the page source. The presumption is that the raw text is the correct copy, and that styling it to upper case is just that -- style. I wrote a thing on this in 2012 and my own frustrations (and testing examples): http://adrianroselli.com/2012/06/copying-content-styled-with-text.html I also find (anecdotal, I know) that many people who choose to style text as all-caps do so with a corresponding typeface that mitigates the visual harshness or intensity. Copying text with the all-caps style and pasting it into another context, especially lacking a specified typeface, can result in a change in perceived meaning. In today's CSSWG call this was mentioned as an issue and it was agreed that this is a bug (see first https://logs.csswg.org/irc.w3.org/css/2016-10-26/#e736063 ) Also, 4 of 5 JS editor projects see this is a bug that needs to be resolved, see: https://lists.w3.org/Archives/Public/www-style/2016Oct/0124.html (The 5th editor is Ok with data loss when copy/pasting between applications; it uses it's own copy/paste mechanism internally) The same bug has been filed with Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=325231 Further discussion to happen here: https://lists.w3.org/Archives/Public/www-style/2016Oct/0128.html This issie also impact accessibility of web pages. For example, if you get a button "Add to Cart" that is rendered uppercase, then VoiceOver will also spell-out the "Add" word as "A D D". This behavior is quite confusing for blind users and those using screenreaders. You can check the following example with Voice Over enabled on macOS. https://jsfiddle.net/sgamel/qyp5avne/ If something similar happens with VoiceOver, please file a new bug. That's not the same as pasteboard support. So, is there any conclusion here if this is going to be addressed or not? It’s still marked as "NEW" 7 years after it’s been created. Since the W3C seems to have agreed on this being a false implementation, I’d love to see this fixed at some point, if that helps to motivate some of the WebKit developers here (and I’m happy to buy you a virtual coffee for it). :) Anselm, could you please elaborate on your specific scenario where this behavior was undesirable? (In reply to comment #20) > Anselm, could you please elaborate on your specific scenario where this > behavior was undesirable? Of course. To be honest, this applies to every single copy I made in the past years from a web page but let’s focus on the main issue I have with the current behaviour: Open a page that applies text-transform: uppercase to i.e. the author’s name, now copy the text and paste it into another document. You now have a transformed uppercase name in your new document. For me this is never the desired format, so I now need to retype manually the name (which can sometimes be quite challenging) to achieve what is a simple copy/paste action in any other browser despite Chrome and Safari. We just resolved a few months ago in the CSSWG that text-transform shouldn't apply when copying text. IIRC, CSS WG didn't, did it? To give some more context on our discussion in Blink. All people who paste to HTML source files want text-transform not applied, which makes sense. Other people want it applied, which also makes sense. Either way we go, someone will probably file a bug. Here's Gecko bug requesting to apply text-transform: https://bugzilla.mozilla.org/show_bug.cgi?id=35148 I think these two are different use cases and better to support both, but we haven't come to the conclusion yet. Here are the relevant threads I can find about it in the W3C: https://lists.w3.org/Archives/Public/www-style/2016Oct/0115.html https://lists.w3.org/Archives/Public/www-style/2016Oct/0130.html The last one states: - RESOLVED: Rich text copy/paste is undefined in text level 3. - Originally the group resolved that plain text copied to the clipboard must (or should) not be affected by text-transform in text 3, but there was an objection from koji so the group will revisit next week. ... but we either didn't revisit it "next" week, or I can't find where we revisited it. IIUC CSSWG has resolved that text-transform doesn't apply to plain text copy paste now: https://github.com/w3c/csswg-drafts/issues/627 My formal objection still stands though. Just opened a Chromium bug for this: https://crbug.com/1429183. I reckon the present bug was filed when Chrome was still based on WebKit. |