Monday, June 25, 2012

Twitter Cards Are Now Valid HTML

Screen capture of an expanded tweet from the Twitter web site.If you've used the Twitter web interface much you might have noticed that sometimes a tweet that links to a popular site includes previews of the pictures, or perhaps video, or even maps.

For example, when I check into a venue on Foursquare and allow that to be auto-tweeted, the web version of my tweet includes venue details including a map, address, number of check-ins and (if I posted a photo) a cropped picture.

This sample image shows how that appears (albeit scaled down to fit on this page since it's so darn tall), but sadly (or goodly, depending on your objective and grammar) the embedded tweet feature doesn't contain all that detail when drawn:

If you go directly to the Foursquare page for that check-in and look at the source code you will find these two meta tags (among many others):

<meta value="@foursquare" name="twitter:site" />
<meta value="photo" name="twitter:card" />

In fact, if you look for other sites whose Twitter references tend to include images, videos, and so on, then you may find these meta tags rolling around in the page header. Here is a sample block from a YouTube video:

<meta name="twitter:card" value="player">
<meta name="twitter:site" value="@youtube">
<meta name="twitter:player" value="https://www.youtube.com/embed/dQw4w9WgXcQ">
<meta property="twitter:player:width" content="640">
<meta property="twitter:player:height" content="480">

This feature is called a Twitter Card, and Twitter has a detailed tutorial of how to enable Twitter Cards for your site at its developer site. If the code looks a bit familiar, it's based on Facebook's OpenGraph, which also stuffs content into meta tags for the use of Facebook embeds.

Not all sites that use Twitter cards will be automatically supported — at least not yet. Twitter is trying this out on some clearly major sites (Foursquare and YouTube are examples) and for anyone else to get their site content embedded into tweets like this they must apply to participate.

Unfortunately, you first have to implement Twitter cards on your site. Only once you have implemented them can you apply to participate, and even then there is no guarantee you'll be included. From Twitter's sign-up page:

As we roll out this new feature to users and publishers, we are looking for sites with great content and those that drive active discussion and activity on Twitter. Unfortunately we will not be able to respond to or approve all requests.

Even more unfortunately, the documentation Twitter provided (as of Friday morning) required you to use meta tags that would not validate. In both HTML4 and HTML5, a meta tag with a name attribute must have a corresponding content attribute, not a value attribute (or, more accurately, there is no content attribute).

A developer filed a bug report noting that the Twitter card code as presented on Twitter's site does not validate. Though Twitter did not respond to this bug report, on Friday afternoon Twitter updated its sample to make the code valid HTML — though nowhere in its document does Twitter notify readers what was updated or that the unnamed change made the code valid.

For those of us who implemented the Twitter Card on our sites in anticipation of wider roll-out of this feature, we are now faced with going through our code to update it at additional expense. Sadly, since this is relatively new and unannounced, there is no way to notify developers that the code has changed.

Twitter will now also be forced to support both variants, since it's clear Foursquare, YouTube, and probably everyone else who has this code in place has not changed it since Friday and may not change it for some time to come. In the end, if web developers just copy content from other sites as a base, they could end up propagating this bad markup.

Having already set up pages on our not-for-profit Buffalo Soccer Club site to use Twitter Cards on Friday morning (which Twitter does not honor yet), I now have to go back through and change them to use the new and valid meta. On the bright side, if you use a content management system that allows you to put custom meta tags on your pages, then you may not need to spend any money to get a developer to implement this feature (hint about our CMS, QuantumCMS).

The bright spot to this story is that Twitter made the change and the code will validate. Those of us trying to be early adopters should be more than happy to make the change.

Interesting aside — I actually wrote this up on Friday when the Twitter code was still broken, but when I went back to review/edit this post on Friday I saw Twitter had updated its code. I hate wasting a blog post, so you have now read my re-write.

Update: March 26, 2013

A List Apart has a new story today outlining not just Twitter cards, but also the the Open Graph meta data that pre-dates Twitter cards: “Like”-able Content: Spread Your Message with Third-Party Metadata

Wednesday, June 20, 2012

Accessibility Bookmarklets and Tools

Testing accessibility on your web projects can be a tricky task if you have no firsthand experience with visual, audible, physical or even cognitive impairment. Having resources in the community is important as is tracking down the same tools in use in that community.

Despite all this it's nice to have some quick techniques for testing your sites without the need to break from your regular workflow. Conveniently, there are a number of tools already out there. Here is a quick rundown...

WCAG 2.0 parsing error bookmarklet

From Steve Faulkner, this experimental bookmarklet uses string matching to evaluate a page against the WCAG 2.0 success criterion for section 4.1.1 Parsing. It leans on the W3C Nu Markup Validator to do its job.

Get the WCAG 2.0 parsing error bookmarklet from The Paciello Group for yourself and while there, read up on how to use it.

Nu Markup Validation Service Bookmarklets

Excuses for failing to use the W3C Nu Markup Validator fall away when all you have to do to validate a page is click on a bookmarklet. Also from Steve Faulkner, this collection of four bookmarklets allows you to validate the current page (in the current window or a new one) or provide the URL of a page to validate (in a new window or not).

Get the four Nu Markup Validation Service bookmarklets (also from The Paciello Group).

Favelets for Checking Web Accessibility

Jim Thatcher has come up with a series of bookmarklets (or as he calls them, favelets) that allow him to make the human review process easier by highlighting details he might otherwise have to wade through code to see. Bookmarklets include image checkers, heading counters, data table notes, ARIA details, and form features.

Get the full collection of "favelets" for checking web accessibility and be sure to read the detailed instructions on how to use these in conjunction with a manual testing process.

Web Accessibility Toolbar

This particular tool is not a collection of bookmarklets. It is also not built to work for any browser other than Internet Explorer. It does, however, provide far more features than bookmarklets can do on their own. Used in conjunction with a manual test and the bookmarklets listed above it can help our overall accessibility testing process far more than just the bookmarklets alone.

Download the Web Accessibility Toolbar For IE and give it a test run on your sites.

If for some reason you are running Opera 8 or Opera 9, there is a version of the Web Accessibility Toolbar for Opera (but again, only 8 or 9).

Juicy Studio Accessibility Toolbar

This toolbar is a Firefox add-on from Gez Lemon. Like the toolbar above, it provides a bit more control than a bookmarklet will afford. This will show you ARIA live regions, show you ARIA landmarks and roles, provides a table inspector and a color contrast analyzer.

You can get the Juicy Studio Accessibility Toolbar from the Mozilla add-on site.

NonVisual Desktop Access (NVDA)

Since I've strayed far afield of bookmarklets I thought I would toss this last one into the mix. NonVisual Desktop Access (NVDA) is a free, open-source screen reader for Windows. While it's intended for the entire OS, it's also great for testing web pages. Its support of different accents makes for much fun when it speaks to me as a Scotsman.

Download a copy of NVDA for yourself and make sure to donate when you do — this is how projects like this are able to continue and how you can support the disabled community.

Somewhat Related on This Blog

Updated

Added Juicy Studio Accessibility Toolbar on June 25, 2012.

Thursday, June 14, 2012

Another Anti-IE Gimmick

Internet Explorer has been the whipping boy of the internet for some time now, particularly Internet Explorer 6. Now it seems Internet Explorer 7 may be the new cool target.

Australian electronics seller Kogan has decided to impose a "tax" on users of Internet Explorer 7. The justification from Kogan's blog post:

One of the things stopping [us from keeping prices low] is our web team having to spend a lot of time making our new website look normal on IE7. This is an extremely old browser, so from today, anyone buying from the site who uses IE7 will be lumped with a 6.8% surcharge - that's 0.1% for each month IE7 has been on the market

Kogan proudly displays a screen shot of the message IE7 users will see (click for a full-size image):

Screen shot of Kolgan tax message in IE7.

The text from the message:

It appears you or your system administrator has been in a coma for over 5 years and you are still using IE7. To help make the Internet a better place, you will be charged a 6.8% tax on your purchase from Kogan.com

This is necessary due to the amount of time our web team has to waste to ensure our site appears correctly in IE7.

Avoid the tax, use a better browser: [images for Chrome, Firefox, Safari, Opera]

Why This Is a Gimmick

The claims made in the blog post and the statement are just not true. I'm not calling them outright lies, but they are at least misrepresentation.

Not a "Tax"

This is not a tax. It is a surcharge, as Kogan says in its blog post. However, in the message to end users it refers to it as a tax four times and even uses a "stamp" to imply it's a tax notice. A savvy user should get it, but this tongue-in-cheek attempt to look official is in contrast to the statement on the blog. This can be a problem from an accessibility perspective when you consider users with cognitive disabilities.

Nothing Informing Users of Tax Hike

The blog post claims the "tax" is assessed based on how many months IE7 has been around. This month it is 6.8%, next month it will 6.9%, in August it will be 7%, and so on. There is nothing to indicate that to users.

No Tax for IE6

There is no "tax" for Internet Explorer version 6. If there was a tax for IE6 using the same calculation as for IE7, then the rate would be 13% (as of this month). A simple argument is that the site is not intended to work well in IE6, and if that's the case then there is no reason to not also display a message to IE6 users saying as much.

Doesn't Work in IE7 Anyway

While visiting the site in IE7 to get the screen shot above, not only did it render poorly (if at all), it hung my virtual machine twice. Kogan claims it is spending effort to make the site look normal on IE7, although it not only doesn't look the same, it doesn't function the same. The 24 separate JavaScript files and 1MB of files (made up of 97 requests from 19 domains) probably doesn't help the page render. I would argue that Kogan is misrepresenting its efforts.

It Doesn't Need to Look the Same in IE7

Again, Kogan claims it spends time making the site look normal on IE7, but not only doesn't define normal, it doesn't acknowledge that it doesn't need to look the same. Kogan's decision to spend time and effort trying to replicate the exact same experience for IE7 is what is costing users, not users' inability to upgrade their browsers.

No Indication of IE7 User Base

Kogan does not state in its blog post how many users of IE7 come to the site. It may very well be only 3 users a year. If that's true, it makes this even more of a gimmick and likely would not have had the splash Kogan wanted. If far more, then Kogan can justify its position by providing an outline of how it will track the success of its campaign — short of proving that IE7 users who cannot upgrade won't be back.

Doesn't Suggest IE8 or IE9

Kogan doesn't tell users in its message to upgrade to a more recent version of Internet Explorer, it tells users to use a better browser and lists Chrome, Firefox, Safari and Opera. It doesn't even list Internet Explorer 8 or 9.

It's Bullying

I don't much care about rudeness. When I see language like this that talks down to me I typically decide the copywriter/management is/are an idiot and that's it. Not all users will feel that way, particularly users who cannot upgrade their browser. Having witnessed what happens when either non-savvy users or users who are trapped on a platform are told they aren't good enough, I am confident this message will only offend those on IE7. It's just a technical form of bullying. That it draws hoots of support from those who only care about the new shiny only bolsters my point.

How Kogan is Being Dishonest

Kogan claims on its blog that "we all have a responsibility to make the Internet a better place. By taking these measures, we are doing our bit." Given that the site doesn't even support IE7 nor does it help users with useful language, I am suspect. If Kogan's claim is true, then Kogan should donate the "tax" money (it clearly isn't using) to support organizations who cannot upgrade for financial reasons, perhaps starting with not-for-profits in its hometown.

Yes, There Are Users Who Cannot Upgrade

There are users who are trapped in work environments that will not allow an upgrade. There are users who are not technically savvy and don't know how. There are users who cannot afford a new computer with a newer OS. There are users who can only access the web from libraries or internet cafes. There are users who stay on a browser version because it works with their add-ons (such as accessibility software).

Kogan is a private business (I assume based on the site) and may choose which customers to support. It doesn't need to even try to support IE7 (I argue it doesn't anyway). However, its gimmick will be taken up by web developers who only see arguments to support their own bad behaviors and who may very well work for organizations where supporting all users (poor, disabled, technically clueless, trapped) is necessary.

If a web developer cannot come up with valid reasons on his or her own for why someone may not be able to upgrade, then I argue that person is a terrible web developer.

If you still don't understand, I refer you to some of my past posts on this topic, each of which contains some nugget on browser use assumptions:

Wednesday, June 13, 2012

ICANN Announces Requested gTLDs

ICANN LogoA week shy of a year ago now ICANN revealed a process to allow organizations to submit applications for new generic top level domain extensions (in addition to the .com, .net, .org and 18 others excluding ccTLDs). You can get more detail in my post Make Your Own TLD? (I want .bacon).

Today ICANN has revealed the list of gTLDs for which random people and businesses have applied. During the January 12 — May 30, 2012 window to submit applications, 1,930 came in.

The process wasn't without some controversy, as when 87 business associations and companies banded together to oppose the process, as outlined in this November 2011 press release: Eighty-Seven Major National and International Business Associations and Companies Join with ANA, Forming the Coalition for Responsible Internet Domain Oversight (CRIDO), to Oppose ICANN's Top-level Domain Expansion Program

Despite that, the ICANN process has been moving along. If, like me, you are curious about the gTLDs for which people are vying, you can get the full list as a CSV file from ICANN, or you can search through the list on the ICANN site.

Of the 1,930 gTLDs, 116 of them are in character sets that the average English-speaking American won't ever see or be able to use (such as Chinese, Cyrillic, and so on). As you go through them, you'll see lots of brand and company names, and even a few slogans in the mix. You'll see some cases where a brand name (such as .youtube) is not registered by the brand owner (Google, in this case), or perhaps ones where the target audience seems a little too targeted (such as .aarp).

Selected Duplicates

Of the remaining (the ones I can read), some of them seem odd, some of them seem too long to type, and some of them are duplicates which means an auction process will kick in to determine who should get rights. Of the over 750 duplicates, here are some of the ones that stood out to me (or just look at my favorites):

String Applicant Location Region
APP .APP REGISTRY INC. KY EUR
APP Charleston Road Registry Inc. (Google) US NA
APP dot App Limited GI EUR
APP Webera Inc. AE AP
APP NU DOT CO LLC US NA
APP Amazon EU S.à r.l. LU EUR
APP Lone Maple, LLC US NA
APP Dot App LLC US NA
APP DotApp Inc. US NA
APP TRI Ventures, Inc. US NA
APP Afilias Limited IE EUR
APP Merchant Law Group LLP CA NA
APP Top Level Domain Holdings Limited VG EUR
BLOG BET Inc. JP AP
BLOG Afilias Domains No. 1 Limited IE EUR
BLOG Top Level Design, LLC US NA
BLOG Corn Shadow, LLC US NA
BLOG Personals TLD Inc. AE AP
BLOG Charleston Road Registry Inc. (Google) US NA
BLOG Merchant Law Group LLP CA NA
BLOG PRIMER NIVEL S.A. PA LAC
BLOG Top Level Domain Holdings Limited VG EUR
BOOK R.R. Bowker LLC US NA
BOOK Top Level Domain Holdings Limited VG EUR
BOOK Charleston Road Registry Inc. (Google) US NA
BOOK Global Domain Registry Pty Ltd AU AP
BOOK Bronze Registry Limited GI EUR
BOOK NU DOT CO LLC US NA
BOOK Amazon EU S.à r.l. LU EUR
BOOK Double Bloom, LLC US NA
BOOK DotBook, LLC US NA
CASINO dot Casino Limited GI EUR
CASINO Binky Sky, LLC US NA
CASINO Afilias Limited IE EUR
CASINO dotBeauty LLC US NA
CLOUD Symantec Corporation US NA
CLOUD Top Level Domain Holdings Limited VG EUR
CLOUD Charleston Road Registry Inc. (Google) US NA
CLOUD Amazon EU S.à r.l. LU EUR
CLOUD Dash Cedar, LLC US NA
CLOUD ARUBA S.p.A. IT EUR
CLOUD CloudNames AS NO EUR
DESIGN STARTING DOT FR EUR
DESIGN BET Inc. JP AP
DESIGN Top Level Domain Holdings Limited VG EUR
DESIGN Top Level Design, LLC US NA
DESIGN NU DOT CO LLC US NA
DESIGN Black Avenue, LLC US NA
DESIGN Design Trend Registry Inc. CA NA
DESIGN Uniregistry, Corp. KY EUR
DOCS Microsoft Corporation US NA
DOCS Charleston Road Registry Inc. (Google) US NA
FREE Top Level Domain Holdings Limited VG EUR
FREE Charleston Road Registry Inc. (Google) US NA
FREE Amazon EU S.à r.l. LU EUR
FREE Over Keep, LLC US NA
FREE Uniregistry, Corp. KY EUR
GAY Top Level Domain Holdings Limited VG EUR
GAY Top Level Design, LLC US NA
GAY United TLD Holdco Ltd. KY EUR
GAY dotgay llc US NA
MAIL Afilias Domains No. 2 Limited, IE EUR
MAIL Charleston Road Registry Inc. (Google) US NA
MAIL 1&1 Mail & Media GmbH DE EUR
MAIL Amazon EU S.à r.l. LU EUR
MAIL Victor Dale, LLC US NA
MAIL WhitePages TLD LLC US NA
MAIL GMO Registry, Inc. JP AP
MAP United TLD Holdco Ltd. KY EUR
MAP Amazon EU S.à r.l. LU EUR
MAP Charleston Road Registry Inc. (Google) US NA
MOBILE Amazon EU S.à r.l. LU EUR
MOBILE Pixie North, LLC US NA
MOBILE Dish DBS Corporation US NA
MOVIE Charleston Road Registry Inc. (Google) US NA
MOVIE dot Movie Limited GI EUR
MOVIE Webdeus Inc. AE AP
MOVIE NU DOT CO LLC US NA
MOVIE Amazon EU S.à r.l. LU EUR
MOVIE New Frostbite, LLC US NA
MOVIE Motion Picture Domain Registry Pty Ltd AU AP
MOVIE Dish DBS Corporation US NA
MUSIC DotMusic Inc. AE AP
MUSIC DotMusic / CGR E-Commerce Ltd CY AP
MUSIC dot Music Limited GI EUR
MUSIC Amazon EU S.à r.l. LU EUR
MUSIC Victor Cross US NA
MUSIC Charleston Road Registry Inc. (Google) US NA
MUSIC .music LLC US NA
MUSIC Entertainment Names Inc. VG EUR
NEWS DotNews Inc. AE AP
NEWS dot News Limited GI EUR
NEWS Amazon EU S.à r.l. LU EUR
NEWS Hidden Bloom, LLC US NA
NEWS Uniregistry, Corp. KY EUR
NEWS Merchant Law Group LLP CA NA
NEWS PRIMER NIVEL S.A. PA LAC

Favorites

And now some of my favorites:

  • .adult
  • .afamilycompany
  • .diet (three of these)
  • .dot (there were two of these)
  • .dotafrica (for the slashdot-literate)
  • .family
  • .fish
  • .foo
  • .goo
  • .gripe
  • .hiphop
  • .ieee
  • .imdb (by Amazon)
  • .ketchup
  • .kids
  • .law
  • .lawyer
  • .legal
  • .lgbt
  • .lol (two of these)
  • .men (with no corresponding .women)
  • .mormon
  • .ninja (for all those self-declared web and social media experts)
  • .porn (but no corresponding .pr0n)
  • .republican (with no corresponding .democrat or .libertarian)
  • .sex (two of these)
  • .sexy
  • .sucks (three of these)
  • .web (seven of these)
  • .website (three of these)
  • .wtf

So there is a proposal for .ketchup, but nothing for .bacon? Internets, you have let me down.

Related

  1. Icann [sic] reveals new internet top-level domain name claims at BBC
  2. Here comes .NETFLIX: New Web domain applications revealed at CNN Money
  3. ICANN unveils new domain names at net Magazine.
  4. Make Your Own TLD? (I want .bacon) by me

Update: 11:41am

I see a lot of traffic coming to this post from people looking for "Charleston Road Registry." A couple minutes in the ICANN application shows that not only does that entity have its address at Google HQ, but the contact is Google's policy analyst. From the application (section 18(a)):

Charleston Road Registry is an American company, wholly owned by Google, which was established to provide registry services to the Internet public. […] As discussed further in the responses to questions 23 and 31, Charleston Road Registry intends to outsource all critical registry functions to Google Registry Services.

I have updated the table above accordingly.

Update: May 8, 2013

The marketing manager for names.co.uk guest-writes a post at .net Magazine ("Google sets precedent for new gTLDs to be open") detailing how Google may be opening up any of the new gTLDs it acquires, instead of restricting their use to just Google brands. The writer hopes others will follow Google's lead.

Monday, June 11, 2012

Image alt Exception Change Re-Re-Requested

HTML5 logo — I am the 'alt,' not the 'title' Just over a year ago now I covered how the HTML5 specification is going to allow the alt attribute to be excluded from img elements under some very specific circumstances (Image alt Attributes Not Always Required in HTML5 and More on Image alt Requirement in HTML5).

The one I am covering today is that the presence of a meta name=generator element, which implies the HTML was generated by some sort of WYSIWYG editor or automated tool, makes the absence of an alt attribute valid.

The motivation here seems to be about making it easier for developers and authoring tools to get pages to validate — but to the detriment of accessibility. Whereas failed validation due to a missing alt can be a clue to a less technical page author (including WYSIWYG users) that something needs to be done, giving a free pass to pages generated from WYSIWYG editors means that authors won't be alerted and therefore are likely to make image content inaccessible.

When comparing the two options (ease of validation versus accessibility for users with disabilities), there doesn't seem to be a complex argument required to make the change. That is not the case, however.

Late last week the latest change request (Issue 31c Meta Generator Updated) was handed in for removing the meta name=generator exception. If you look at the table of contents you can see that it has been batted down twice before, though without addressing all the points raised. This of course left the meta name=generator exception open to be challenged again.

Each of the nine core arguments has been updated and two more have been added:

  1. Fixing something bad by introducing a document-global switch is a Bad Idea (new)
  2. "Legacy use" of meta generator is never likely to be supplanted by use conforming to the current spec text (new)
  3. Inadvertently and retroactively introducing new, undocumented, magic semantics (minor update)
  4. Fatal ambiguity in the specification (minor update)
  5. Tool-mediated insertions of alternative text are ignored (minor update)
  6. The "generator exception" obviates the intent of the Validator (updated)
  7. The "generator exception" results in inequitable rendering of graphical content (updated)
  8. The "generator exception" breaks harmonization with other standards and guidelines (updated)
  9. The "generator exception" inappropriately gives authoring tool conformance considerations precedence over end-user requirements (updated)
  10. Harmful consequences of the generator exception include harm to web authors and to web content users with disabilities (updated)
  11. The weighting of objections against the "generator exception" is opaque (updated)

It's a hefty read. If you already agree that the meta name=generator exception is a bad idea, then you probably don't need to read through it. If you are unsure or want to know, then the detail is good. Sadly, the previous rejections mean that so much detail has been tossed in here that it's not an easy read.

Even if you don't care for all the detail, the statement of impact at the end should be enough to convince you that it's kind of an easy decision:

Positive Effects

  • Authors can more safely assume that when they use a validator it will appropriately check the conformance of the document, rather than some arbitrary subset of requirements.
  • The use of meta name=generator will not change in a way that is contrary to its current usage and effects.
  • Authors will be made aware that they have not provided a text alternative giving them the opportunity to fix their error and produce a conforming document.
  • Upholds the structural integrity of <img> element.
  • Enables automatic validators to programmatically detect occurrences of the presence or absence of text alternatives. Bug 9218.
  • Facilitates accessibility awareness and education.
  • Upholds the HTML section 3.2. "Priority of Constituencies" Design Principle.

Negative Effects

  • None

Raising a stink about this on your blogs, in your tweets, and (ideally) face-to-face with anyone from the HTML Working Group might mean that the third time is the charm.

Wednesday, June 6, 2012

Copying Content Styled with Text-Transform

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.

Saturday, June 2, 2012

Picplz Shutting Down, as Free Services Often Do

Picplz is a photo/image editing and sharing app/service that has been compared to Instagram and long referred to as the Android alternative (Instagram didn't support Android until recently).

At 10:17pm EST on a Friday night (last night), June 1, Picplz sent out the following cryptic tweet:

Even though I hate shortened-URL-only tweets, Picplz doesn't tweet often so I followed it to read this in the brief blog post:

On July 3, 2012, picplz will shut down permanently, and all photos and user data will be deleted. Until then, users may download their own photos by clicking on the download link next to each photo in their photo feed.

And that's it. Just about a month before it's gone. Just over 30 days to manually download each one of my photos.

My take? Oh well. It's a free service that just saw the darling of the photo manipulation and sharing space (Instagram) get bought up for an absurd amount of money. I suspect Picplz just gave up. I knew going into it that at some point I'd have to pull my stuff out (hence my regular requests on the support forum for an RSS feed of my full history).

In December 2010 I wrote about our reliance on and sense of entitlement to free services in You Get What You Pay For. This is the same thing. It's a perfect example of how you need to be prepared from the start that your favorite free service will change or go away. When it does, don't expect great (or even good or maybe any) notice or customer service.

Years ago I started using Brightkite to post images (and track my travels, share them with Twitter and Facebook, live as an online gallery, feed to mapping services, etc.). When Brightkite went away I dabbled in Gowalla and sensed its demise, so tried out Plyce, which also changed direction. I found Picplz and still dabbled in others just in case Picplz went away. Now I just need to choose my next photo posting platform and hope I can get a couple years out of that one, too.

In the meantime, I will be writing a script to wade through my 1,400+ Picplz photos and pull down all my images, descriptions and geo-data. Considering I paid nothing to use the service for over a year and a half, I think this is a fair cost to me.

Related

Update: Sunday, June 3, 2012

This post got a lot of traffic overnight and didn't realize why at first. It seems I scooped the regular tech news outlets and so for a while this post was the only one out there. Cool. These other posts have popped up since then:

Interestingly, less than two months ago Lifehacker ran the article Don't Bother with Instagram; Here are Five Better Alternatives for Android. Of those five, Picplz is going away and Lightbox Photos got gobbled up by Facebook.

Update: Sunday, June 3, 2012, 11:20pm

Earlier tonight Picplz tweeted out some hope for those of us with lots of photos who don't really have the time to download each photo individually:

Update: June 15, 2012

Picplz notified users (via another cryptic tweet that led to a blog post) on Wednesday that it would make each user's photo archive available as a download. Users would be notified via email when their archives were ready. I received my email late last night and am in the process of downloading my 1.5GB archive now (so I have no idea the formats of anything).