35148 - copying style="text-transform: uppercase;" doesn't preserve transformation when pasting as text

Status: RESOLVED WONTFIX

(Core :: DOM: Serializers, enhancement)

Description

[Jesse Ruderman]

On <URL:resource:/res/samples/test0.html>, try copying the first few lines of  
to the "text styles" section.  It copies them without applying the text 
transformation.

(Is that intended behavior?  IE does it like that too.)

Comment 1

[Kathleen :Brade]

I'm guessing this should really be Akkana's bug since it isn't really a selection 
issue.  Changing severity from minor to enhancement since I don't think 4.x 
handled this either.

Comment 2

[Akkana Peck]

This refers to constructs like the following:
 <SPAN style="text-transform: capitalize;">
  this text was capitalized &aring; &egrave;
 </SPAN>

Yes, this would be my bug.  We don't guarantee anything about preserving style
in copy/paste ... but in this particular case, where style is inline in the span
tag, it seems like it would be easy to do.  No guarantees, but I'll check in a
quick fix if I find one, otherwise helpwanted.

Comment 3

[rubydoo123]

moving to future milestone

Comment 4

[rubydoo123]

reassigning back to Akkana

Comment 5

[Akkana Peck]

Re-accepting.

Comment 6

[Blake Ross]

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...

Comment 7

[Karl Ove Hufthammer]

Are you all *sure* this isn't 'invalid'? In my opinion, it should be.

Comment 8

[Akkana Peck]

I don't think it's invalid -- it would be nice to be able to copy the style,
perhaps optionally based on the input flags.  But it's also a pie-in-the-sky RFE.

Handing off to anthonyd, who is taking over Output bugs.

Comment 9

[Jesse Ruderman]

See also bug 39098, which wants invisible elements to not be copied.

Comment 10

[rubydoo123]

--> kin

Comment 11

[Blake Ross]

changing selection qa to tpreston.

Comment 12

[Adam Hauner]

Attachment: Testcase

Comment 13

[Peter Asemann]

Someone told me that this:

div style="text-transform:uppercase;font-family:fixedsys,monospace;">
[<a href="javascript:self.close()">Fenster schlie&szlig;en</a>]
</div>

will cause Mozilla to convert the &szlig; / ß to "SS". This is in some way
logical as there is no uppercase ß, though doing nothing with the ß would be as
logical from my point of view and understanding of german.

Whatever, Mozilla will eat up the last letter of the link text (the n)         
                                for no good reason, probably because it is not
aware of that the string has grown.

Maybe this also has to do with bug 93168?

Comment 15

[Nickolay_Ponomarev]

Since we preserve inline styles when pasting in HTML context, I'm clarifying (morphing?) this to be about HTML->Text conversion case:

1. Open the attached testcase https://bugzilla.mozilla.org/attachment.cgi?id=99514
2. Select all, copy
3. Switch to a plain text editor, paste

Expected results: "UPPERCASED TEXT" pasted
Actual results: "Uppercased text" pasted

Comment 16

[Pavel Roskin]

I believe the existing behavior is not user-friendly. Users expect that Firefox would preserve the text that they see on the screen. Arguments that web developers could use capitalized text don't always apply. The reason I'm writing here is because I'm trying to put instructions to a Mediawiki based system that should include capitalized username, and I have no other way to do it apart from using styles. If Firefox users cut and paste my instructions to the command line, they would end up running a wrong command.

Chrome and other Webkit based browsers do the right thing. This is the fixed bug for Webkit https://bugs.webkit.org/show_bug.cgi?id=3429

Attempts to reverse that behavior have not been met with enthusiasm: https://bugs.webkit.org/show_bug.cgi?id=43202

Comment 17

[Adrian Roselli]

I encourage you to retain the existing behavior.

The presumption is that the raw text is the correct copy, and that styling it to upper case is just that -- style. When I copy text and paste it into a text editor, it sheds all style, and text case should be part of that.

I wrote a thing on this in 2012 and my own frustrations with how WebKit behaves (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.

Comment 18

[ejsanders]

Although text-transform is part of the "style"sheet, it is not stylistic in the same way that say, bold or italics are. Text case is clear semantic information about the plain text, and can even change the grammatical meaning of the sentence.

Also, without inspecting the HTML of the document there is no visible difference between 'UPPERCASE' and '<span style="text-transform:uppercase;">uppercase</span>', so the user can't possible expect them to copy as different text.

Comment 19

[ejsanders]

Not also that as of FF 45, the Node.innerText property has been implemented which returns upper case text for text-transform:uppercase, as does WebKit/Blink. According to MDN, Node.innerText "approximates the text the user would get if they highlighted the contents of the element with the cursor and then copied to the clipboard." - so the clipboard should behave like Node.innerText.

Comment 20

[Fuqiao Xue [:xfq]]

CSSWG has resolved that text-transform doesn't apply to plain text copy paste:

https://github.com/w3c/csswg-drafts/issues/627

Comment 21

[Mats Palmgren (inactive)]

And the spec text has now been changed:
https://github.com/w3c/csswg-drafts/pull/3107/files