Copying Content Styled with Text-Transform

Using the CSS property text-transform to automatically shift copy to uppercase has been popular for a while now, but a combination of a recent explosion in the use of that style and my slow move to Chrome as my default browser has caused me to regularly paste text into emails, tweets, and blog posts that is not what I expect.

If you’ve had to support a WYSIWYG editor you are probably already familiar with the style-purging technique of copying content from a web page or Microsoft Word, pasting it into a plain text editor (Notepad in my case), and then copying it from there to then paste it into your WYSIWYG editor window. WYSIWYG editors have caught up in the last few years and offered options to paste content as plain text, sans formatting.

The problem is that none of those techniques addresses when the lowercase characters have been replaced with uppercase characters (or vice versa). This isn’t a style you can purge, the characters are truly different.

Testing It

I was curious to see how the browsers have handled text copied from a page where the content was styled to uppercase. I made the following sample block using the text-transform values capitalize, uppercase, lowercase, and full-width:

This content has no text-transform applied to it.

This content has text-transform: capitalize applied to it.

This content has text-transform: uppercase applied to it.

This content has text-transform: lowercase applied to it.

This content has text-transform: full-width applied to it.

I then fired up the following browsers and copied that block of text from each one, pasting into a Notepad (or equivalent) window each time:

• Google Chrome
• Apple Safari
• Mozilla Firefox
• Opera
• Internet Explorer 6
• Internet Explorer 7
• Internet Explorer 8
• Internet Explorer 9
• Internet Explorer 10 (beta)
• Apple Mobile Safari on the iPad
• Apple Mobile Safari on the iPhone
• Android Browser
• Mozilla Firefox Mobile
• Opera Mobile

Results

All the Webkit browsers (Safari, Mobile Safari, Android Browser, Chrome) behaved the same. They each kept the capitalized text (and the lowercase initial character, where it was styled that way):

This content has no text-transform applied to it.

This Content Has Text-Transform: Capitalize Applied To It.

THIS CONTENT HAS TEXT-TRANSFORM: UPPERCASE APPLIED TO IT.

this content has text-transform: lowercase applied to it.

This content has text-transform: full-width applied to it.

On a side note, screen reader NVDA pronounces the word “it” as “IT” (eye-tee) when it has the text-transform: uppercase style applied. This happens regardless of browser.

Workarounds?

I installed some Chrome extensions that promise to remove all formatting, specifically Copy Plain Text 0.1, Copy Without Formatting 0.31, and Plain Text Copy And Paste 1.1.0. None of them revert the text case back to what it is in the source code.

I went to both the CSS 2.1 and CSS3 specifications to see if there is direction to browser makers on how to treat text that has been styled with text-transform, but I see nothing defining how browsers should put that content into the clipboard.

Ugh

I have an issue with how WebKit handles this. The fact that it breaks from my experience with other browsers, and thus my expectation, is more my issue. I can’t hold WebKit responsible for that. I can, however, hold WebKit responsible for requiring me to either view the source code or open it in another browser to copy the unmodified text.

I feel that changing case is not just technically a matter of changing the specific character entity, but it also changes the meaning of the text when taken out of context. For example, let’s say I write a blog post titled Adrian Likes Bananas, style it with a special typeface and shift it to all caps. This reads differently when someone copies it (without my custom typeface that softens the all-caps effect) and tweets the “shouted” version of the title, ADRIAN LIKES BANANAS. It actually makes the title read as if it’s gone … bananas.

Add to this the unintended acronymization (look, a new word) by screen readers as I show in the it/IT example above, and you run a further risk of creating a confusing block of pasted copy when pulling from Chrome.

I am curious if others feel the same way as I do, or have a different expectation. Bonus if someone can point me to where the W3C specifications define how a user agent should treat this styled content when posted to the clipboard.

There is a bug filed, from July 29, 2010, that is still open as of this writing: Bug 43202 – text-transform shouldn’t apply when copying text

Update: July 8, 2016

Thanks to a kind response to a grumpy tweet, it looks like this issue is getting some attention (it is now on the radar).

Update: April 24, 2018

One critical block on addressing the browser bugs may have just been resolved — the CSS Working Group posted this at GitHub:

The Working Group just discussed text-transform on copy/paste, and agreed to the following resolutions:

• RESOLVED: text-transform doesn't apply to plain text copy paste
• RESOLVED: normative state that text-transform does not apply to plain text paste.

This information has been added to the (18 year old) Firefox bug (which seeks to override the existing behavior) and the (8 year old) WebKit bug.

Update: September 14, 2018

The CSS Working Group is about to commit this language to the spec:

This property transforms text for styling purposes. It has no effect on the underlying content, and does not apply to the content of a plain text copy & paste operation.

As a direct result (and before the code was committed), Firefox has closed its open issue. This means it will continue to correctly ignore text styled as upper/lower case when copying and pasting.

Update: March 30, 2023

As Thomas Steiner notes in a comment below, the WebKit bug may not have been ported over to Chromium’s bug tracker after the fork. So he filed a new one: Issue 1429183: Copying text that was CSS `text-transform`’ed to `uppercase` is copied in uppercase

That does not mean anyone is looking at or working on it, but at least now it is in the right place.