tech support 8

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Wednesday, 6 June 2012

Copying Content Styled with Text-Transform

Posted on 11:36 by Unknown


A ≠ a
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.

Email ThisBlogThis!Share to XShare to FacebookShare to Pinterest
Posted in accessibility, browser, Chrome, css, fonts, rant, Safari, standards, W3C | No comments
Newer Post Older Post Home

0 comments:

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

  • Social Media Day 2011 in Buffalo #smdayBUF
    Last night marked the second Mashable-sponsored Social Media Day here in Buffalo. With 154 RSVPs for the event, the venue, The Eights Bist...
  • Web Accessibility Sorta-Infographic
    WebAIM is a non-profit organization within the Center for Persons with Disabilities at Utah State University. It has a reputation (perhaps o...
  • New Google Analytics Features
    In the article " Google Analytics Now More Powerful, Flexible and Intelligent " from last Tuesday (yes, I know I'm behind on t...
  • Speaking: Accessible Web Apps & Standards
    I will be speaking twice in September, both of them sponsored by Infotech Niagara. If you're in the Buffalo area, these are great opport...
  • The Science of Trust in Social Media
    I am one of those people who always needs to see proof of some assertion, evidence to back up a claim. While I can accept anecdotal evidence...
  • Current CSS3, HTML5 Support
    The Tool Last week saw the launch of FindMeByIp.com , a very handy web site that displays a user's current IP address (along with a geog...
  • HTML5 Finally Gets... a Logo?
    Start Rant With all the debate about elements , attributes , semantic meaning and who really owns HTML5 , it's thrilling to see that t...
  • Speaking at WordCamp Buffalo 2013
    This Saturday I will be speaking at Buffalo's second WordCamp . Last year was a great day-long event filled with many good speakers (not...
  • Speaking at Mom 2.0 in Houston, TX
    I will be in Houston this week to speak at the Mom 2.0 Summit (Feb. 18-20, 2010, Houston, TX). To make it a little easier to describe, here...
  • Now the Mobile Web Is Dead?
    It was barely two years ago that I scoffed when Wired declared the web dead ( Enough about the Death of the Web ). Fast forward to today and...

Categories

  • accessibility
  • Adobe
  • analytics
  • Apple
  • apps
  • ARIA
  • Bing
  • Blink
  • Brightkite
  • browser
  • Buzz
  • Chrome
  • clients
  • css
  • design
  • Facebook
  • Firefox
  • Flash
  • fonts
  • food
  • Foursquare
  • g11n
  • geolocation
  • globalization
  • Google
  • Gowalla
  • html
  • i18n
  • ICANN
  • infographic
  • Instagram
  • internationalization
  • internet
  • Internet Explorer
  • JavaScript
  • JAWS
  • Klout
  • L10n
  • law
  • localization
  • Lynx
  • Mapquest
  • Microsoft
  • mobile
  • Netscape
  • ning
  • Opera
  • patents
  • picplz
  • Plus
  • print
  • privacy
  • project management
  • QR
  • rant
  • RSS
  • Safari
  • SCVNGR
  • search
  • SEM
  • SEO
  • social media
  • Sony
  • speaking
  • standards
  • SVG
  • touch
  • translation
  • Twitter
  • typefaces
  • usability
  • UX
  • Verizon
  • video
  • W3C
  • WAI
  • WCAG
  • WebKit
  • whatwg
  • Wired
  • WOFF
  • xhtml
  • Yahoo
  • YouTube

Blog Archive

  • ►  2013 (39)
    • ►  December (1)
    • ►  November (7)
    • ►  September (4)
    • ►  July (3)
    • ►  June (2)
    • ►  May (5)
    • ►  April (3)
    • ►  March (6)
    • ►  February (2)
    • ►  January (6)
  • ▼  2012 (63)
    • ►  December (2)
    • ►  November (4)
    • ►  October (5)
    • ►  September (5)
    • ►  August (4)
    • ►  July (6)
    • ▼  June (7)
      • Twitter Cards Are Now Valid HTML
      • Accessibility Bookmarklets and Tools
      • Another Anti-IE Gimmick
      • ICANN Announces Requested gTLDs
      • Image alt Exception Change Re-Re-Requested
      • Copying Content Styled with Text-Transform
      • Picplz Shutting Down, as Free Services Often Do
    • ►  May (7)
    • ►  April (8)
    • ►  March (5)
    • ►  February (3)
    • ►  January (7)
  • ►  2011 (67)
    • ►  December (5)
    • ►  November (7)
    • ►  October (5)
    • ►  September (4)
    • ►  August (8)
    • ►  July (3)
    • ►  June (8)
    • ►  May (3)
    • ►  April (1)
    • ►  March (6)
    • ►  February (6)
    • ►  January (11)
  • ►  2010 (100)
    • ►  December (8)
    • ►  November (7)
    • ►  October (5)
    • ►  September (10)
    • ►  August (7)
    • ►  July (11)
    • ►  June (12)
    • ►  May (6)
    • ►  April (8)
    • ►  March (10)
    • ►  February (5)
    • ►  January (11)
  • ►  2009 (51)
    • ►  December (9)
    • ►  November (6)
    • ►  October (21)
    • ►  September (13)
    • ►  August (2)
  • ►  2003 (3)
    • ►  October (1)
    • ►  January (2)
  • ►  2002 (9)
    • ►  December (1)
    • ►  June (3)
    • ►  April (1)
    • ►  March (3)
    • ►  January (1)
  • ►  2001 (1)
    • ►  February (1)
  • ►  2000 (4)
    • ►  October (1)
    • ►  July (1)
    • ►  June (1)
    • ►  January (1)
  • ►  1999 (7)
    • ►  November (1)
    • ►  September (2)
    • ►  August (2)
    • ►  July (1)
    • ►  June (1)
Powered by Blogger.

About Me

Unknown
View my complete profile