Twitter App Sets Browsers Back 10 Versions

Screen shot of a web page as seen in the Twitter app, with a menu showing the option to open in the user's default web browser.

The title of this post may be a bit of hyperbole for some, but it is completely true for me.

Sometime over the course of the last week Twitter changed what happens when I tap links in the native Twitter app on Android. Links now open within an embedded browser, not in my default browser.

I have Chrome 40 installed on my Android phone. The built-in web view on my phone is 10 releases back, at Chrome 30. Normally this isn't a concern of mine, but when a good deal of my Twitter timeline consists of bleeding edge web development techniques, I want to view those on a current release of Chrome.

The first image shows that the user agent string within the Twitter app includes Chrome 30. The second image shows my default browser user agent string is Chrome 40.

This change appeared while I was traveling internationally, which means I had a slower connection than usual as well as a data cap. Not only do I have to view content in an old browser, I have to know that the web view is older so that I then know to open it in my default browser.

That's at least two more taps, plus the burden of the download starting in the web view that I don't want. That extra download burden also impacts my data cap, which is an even bigger issue if I have chosen to surf with Opera Mini to make the most of my limited data cap (you know, data budgeting).

Not only did I never enable this feature, I cannot disable it. It appeared three weeks after my last Twitter app update (see the caption below).

The first image shows the settings screen in the Android Twitter app, version 5.48.0. You can see there is no option to disable the in-app browser, though it has been enabled. The second image is the note in the Google Play store that tells me the only change in the new release is updated profiles so it's easier to view bios, Tweets and photos. The final image shows the option to disable the in-app browser, but only because I updated to version 5.51.0 (when I returned from home and shed my data cap).

So What?

A couple months ago Peter-Paul Koch wrote about the massive fragmentation in the world of Chrome (Chrome continues to fall apart at brisk pace), something to which Twitter is now contributing en masse.

In the modern world of rapidly updating browsers, 10 releases may not seem like a big deal. I guess it comes down to what you want to see, or more importantly, what you want your users to see. Can I Use provides a quick way to compare Chrome 30 and Chrome 40 to see which features you may be missing. Here's a short list:

• The ability to discard many -webkit- prefixes,
• Font unicode-range subsetting,
• matches() DOM method,
• CSS touch-action property,
• CSS Font Loading,
• Custom Elements,
• picture element,
• Web Cryptography,
• WOFF 2.0 - Web Open Font Format.

If you rely on any of these (or many other) features of the open web platform, and you receive traffic from Twitter, I suggest you monitor your logs to see if the most common version of Chrome drops.

As for user experience, If you plan to allow users to toggle a new "feature," don't push that feature to them without the toggle. Especially when you exclude it from your update notes within the app store.

Best Viewed in 1 of 11 Flavors of Chrome!

Make sure you view this on Google's flavor of Chrome, otherwise, well, I have no idea what will happen.

Sometimes it's frustrating being a developer who's been around to see Mosaic supplanted by Netscape Navigator supplanted by Internet Explorer supplanted by Chrome/WebKit. Developers just love dumping one platform for the new shiny.

As I said last week, all of this has happened before and will happen again. The difference with this post is that I am not going to rant about lazy developers whining over a world that will still contain Internet Explorer and its offspring.

Instead, let's ask the average anti-IE / pro-WebKit developer a very simple question — on how many flavors of Chrome do you test?

I don't mean how many versions of Chrome. I also don't mean how many different WebKit-based browsers. No, how many flavors of Chrome?

I'll guess probably not more than a couple. I have four that I can, but typically don't, use. Even at four that's far too few.

Today Peter-Paul Koch pointed out that there are eleven (11!) flavors of Chrome (Chromia, if you will). All of them built on Chromium. Here's the breakdown from his article:

Vendor	Version	Tested	Default	Remarks
Google	40	Yes	Yes
Opera	39	Yes	No
Yandex	38	Yes	No
Xiaomi	34 or 35	Yes	Yes	Zoom reflow
HTC	33	Yes	Yes	Zoom reflow
Cyanogen	33	Yes	Yes
LG	30	Yes	Yes	Mid-range
Puffin	30	Yes	No	Proxy
Samsung	28	Yes	Yes
Amazon	37	No	Yes	Silk
LG	34	No	Yes	High-end

Peter-Paul Koch from the post Chrome continues to fall apart at brisk pace

You may have noticed that this only accounts for mobile devices. Some on Twitter also noted Chrome on Google TV, or on Android TV, which doesn't account for the Samsung Android TV nor the Sony Android TV.

So maybe it's fifteen (15!) flavors of Chrome. Either way, I suspect that number will continue to grow.

Even if I include IE6, I only have to worry about 5 versions of Internet Explorer across mobile and desktop. If I want the idyllic WebKit-only world so many seem to crave, then I need about a dozen flavors of Chrome before I can get started with the Operas, Safaris, Yandexes, and Vivaldis (plural because those forks of WebKit also have their own versions to support)

All of this written against the backdrop of a Medium post claiming it won't consider IE11 a Tier 1 browser because of what it considers an ugly border in the editor view. Unable to find IE developers anywhere, nor to figure out where to file a bug, Medium just browser-sniffs IE11 into a second tier. I'm sure Medium tested across eleven flavors of Chrome, though.

Please read PPK's piece: Chrome continues to fall apart at brisk pace

All of This Has Happened Before and Will Happen Again

Jacob Rossi from Microsoft put together an article for Smashing Magazine that discusses Microsoft's Project Spartan web browser, Inside Microsoft’s New Rendering Engine For The “Project Spartan”.

Unlike other click-bait efforts that only speculated that perhaps Spartan was going to be WebKit-based, showing their own preference instead of any real understanding of the browser world, this one is filled with lots of great information. You should read it.

The first few comments, on the other hand, started off a mess (with many more on Twitter since the initial announcement). Two examples from the article:

So here was the opportunity to swallow their pride and join WebKit to make the internet a better place

…and they built *another* closed-source, proprietary rendering engine.

[Slow sarcastic clap]

Jones

« IE did shape the web in a positive way »

This made me laugh more than it should. You seem to forget why Internet Explorer has felt the need to change its name in the first place. And it’s not because it was «too good» or «too innovative»…

Erick G.

Many folks jumped in and corrected, down-voted, and generally balanced the insipid whining. Christian Heilmann, who has logged more years working for Firefox than most devs have logged using it, waded in to challenge many of the incorrect assertions.

Bruce Lawson, who happens to work for another browser vendor (Opera) noted all the things Internet Explorer did for the web in his five-year-old post In praise of Internet Explorer 6. It's also a cautionary tale about where reliance on a single rendering engine will take us.

What these two guys have in common, besides working for the competition, is that they have been on the web since its dawn. They've seen what happens when one browser gets too big (Internet Explorer) and how we spend the next decade-plus digging out from the mess.

How did we get into that mess? By people coding for one rendering engine.

Everyone who calls for WebKit in Internet Explorer is exactly the same kind of developer who would have coded to Internet Explorer 15 years ago (and probably happily displayed the best viewed in badge).

If you are that developer, then it will all be your fault when it happens again. When WebKit is no longer the hot engine. When Chrome loses its dominance. When Apple's market share falls to match the developing world. You will be to blame.

Do you think that won't happen? Just look to Android browser fragmentation, or WebKit failing to support a standard that Firefox and IE have nailed, or Chrome introducing its own proprietary features (can't find the link; it's coming), or failing to use best practices as it tries to carry the next big thing forward, or the complete lack of developer relations from Apple. We've had over half a decade of warning signs.

It's happening again, and every petulant, lazy developer who calls for a WebKit-only world is responsible.

Related

• The Return of “Best Viewed in…”
• Everything Will Be the New IE6

Update: February 3, 2015

My rant continues in my post Best Viewed in 1 of 11 Flavors of Chrome! It's built off PPK's Chrome continues to fall apart at brisk pace. Even I didn't know there are so many Chromium variants.

Linear Gradient Problems in Chrome

Detail of the effect I wanted to re-create with a linear gradient — a gray column, a white narrow gutter, a black vertical line, and the rest as white.

I'm going to tell you up front that I don't have a fix for the issue I am raising, though there are bugs filed against it.

I wanted to create equal-height columns that don't use tables, piles of JavaScript, background images, or many of the other code-heavy techniques out there today. I just wanted a CSS-only option. I have played around with CSS gradients to define columns before, something it turns out was covered in 2010 at CSS Tricks, and I decided browser support had come along enough that I could make a prefix-free solution.

In the image above I show an example where I want a vertical line between two columns, along with a narrow gutter. This is pretty straightforward, though you're better off doing it by hand than using any of the gradient generators out there right now. Ultimately I needed a step that is one pixel wide (yes, I am using pixels for this example) that is also a solid color. Easy enough.

It turns out that Chrome, Firefox and Internet Explorer 11 just don't seem to dig making a one pixel gradient step. That's ok. I can work with that. What I wasn't prepared for was how Chrome (38 as of this writing, though this appeared in prior versions) opted to handle it.

At some window sizes, Chrome displays no step at all. At other window sizes, it's 5 pixels. Sometimes the widths of the other steps change as well. This means some Chrome users will see nothing, others will see something five times wider than I want. The animated GIF below shows what happens to the line (in red) as I scale the window width. I think you can agree that it can be a pretty jarring experience for users (part of me worries that this kind of rapid flashing on the whole page can also overwhelm some users).

Animated screen capture of the CodePen in Google Chrome 38 showing the stuttering width of the "columns" and the inability to handle a one pixel band/step.

The animated screen shot is from a Pen that I created to show the effect. I have embedded it below, though you can visit (and fork) the pen directly at CodePen.io.

There are also two open Chromium bugs and one Stack Overflow discussion that are related, though not just with single-pixel gradients.:

• Issue 233879: Bug with linear-gradient layout, Apr 20, 2013 (with a sample pen).
• Issue 281489: Linear Gradient color stops not calculated correctly, Aug 29, 2013 (sample pen missing).
• Webkit linear gradient stops render incorrectly, May 13, 2014 (with a different example pen).

Notes on the first bug offer an explanation of sorts:

skia discretizes the colors into 256 levels for (lots of) speed. hard-edged gradients like this (where there are two colors at the same color-stop) definitely show up this limitation. We can look at ways to increase precision, but there will be a real performance cost, so we have to decide how important this particular behavior is in practice.

Essentially the argument is that this is a performance trade-off. One that both Firefox and Internet Explorer seem more than capable of handling, which means I'm not buying this excuse a year and a half after it was offered. It just feels like a cop-out.

If you think that your work could benefit from having these bugs fixed, please go star them. Otherwise we may not use that awesome CSS feature, and by extension we're enabling the browser monoculture that is Chrome.

Update below the pen

See the Pen Testing Gradients as Column BG by Adrian Roselli (@aardrian) on CodePen.

Update: 10 minutes After Posting

I posted a link to my pen and this post to the bugs, and in both cases I later got email bounce notifications ("The email account that you tried to reach is disabled."). The address srsrid...@chromium.org, the only CC on 281489 and one of two on 233879, is gone which makes me think nobody is listening on at least one of the bugs.

On Hiding URLs in the Browser

This image is stolen directly from Allen Pike's post because I don't have time yet to make a proper one. It shows the same page URL as seen in the address bars of Firefox 29 and Chrome Canary 36.0.1951.

Two days ago news broke that Chrome was going to modify the address bar in the browser to hide a page's URL. Web developers reacted pretty swiftly saying it's a bad idea. The first one I saw was Allen Pike's Burying the URL, and then a thread on Hacker News.

My first reaction is that this is a terrible idea, for all the points listed.

My second reaction is different.

I'm a web developer. I rely on seeing the URL every day not only as part of my job, but also to consume content and understand its value. I've been championing human-readable URLs for 20+ years and have railed against platforms that don't use them. Non-human-readable URLs are still valuable to me, though probably not the typical user.

Whether I want to hack a URL to remove the tracking nonsense appended by buff.ly-style shorteners, posit the date of a blog post when the author hides publish dates, or make sure I am looking at the development version of a site I am building instead of the staging or production URL (which is hilarious to get wrong while trying to debug an issue), I see a lot of value in URLs.

I realize that many (most?) other users aren't using URLs the way I do. Sure, I have trained my parents to look for certain things in a URL, but for the sites they frequent, which are often news sites with long strings of nonsense in the URL, there isn't much value for them.

So besides web developers, is this really hurting the typical web user? Is our general outcry based on anything other than a variation on "looks great in my browser?"

I posted a tweet this morning that is getting some retweet action, but I'm not sure that people understand that I am framing the issue from my perspective, not the average user's perspective. If anything, it belies how little I want to be family tech support. The tweet:

I don't want URLs hidden. As a dev I always want them. As family tech support, I don't want to have to retrain my parents on copying URLs.

— Adrian Roselli (@aardrian) May 2, 2014

At the same time, Patrick Lauke was on his own tirade about how, as developers, we aren't really typical users. A couple points from the stream:

"but URLs are the basis of the web" great, but should they be exposed raw to end users? do you miss setting frequency and fine-tuning a TV?

— patrick h. lauke (@patrick_h_lauke) May 2, 2014

i argued when browsers hid "http://", "https://", etc from URL bars. now, i couldn't care less as long as same info conveyed differently

— patrick h. lauke (@patrick_h_lauke) May 2, 2014

URLs have been getting masked, obfuscated, or hidden for some time now. My mobile phone hides a URL as soon as I scroll down the page. My browser doesn't show the HTTP protocol unless it's HTTPS. Opera Coast has gone a step further as it appifies the web experience.

Opera Coast has hidden URLs all along (as I note in my review), and while I don't know how that's mattered to typical users, it was enough to make me stop using it. While it is possible to get to the URL within Opera Coast, it's a bit more of a hassle than I like.

In the case of Chrome, it will be one click (which is one more click than I would like) to show the full URL as this video (embedded below) shared by Mark Harwood shows (sorry, only MP4 for now):

If the hidden URLs feature does make it into a coming release of Chrome, we as web developers can simply disable it with a Chrome flag: chrome://flags/#origin-chip-in-omnibox.

At this point, my resistance to the change is that I am a web developer who consumes URLs and that I don't want to have to re-train my parents how to send a link (without using some nonsense "share" button). I'd rather not see URLs go away, but I'm a professional, I can sort it out.

Unrelated

App Links you say? Don't get me started on App Links.

Update: May 4, 2014: Related

Jake Archibald has shared his opinion in his post Improving the URL bar. As is often the case in technical discussions, the comments have a lot of good back and forth.

Jeremy Keith has his own response post, the mispronounced-yet-whittily-named URLy warning.

Remy Sharp offers an alternative to the proposed URL hiding in hist post On Chrome hiding URLs to protect users from phishing. In short, he tries to tackle the stated reason behind Chrome's desire to hide URLs without hiding URLs.

Not really related, but interesting nonetheless is this post, The Secret Messages Inside Chinese URLs. The post is really talking about domain names on their own, but in the context of the page-level URL discussion I think it's novel.

Update: May 6, 2014

Opera 21 has come out, and among its release notes is this nugget on URLs in the address bar:

We now provide an option to make Opera persistently show a page’s complete URL in the address field.

[…]

For more technical users who need to quickly see the entire URL at a glance, go to “Settings | Advanced: Show always full URL in address field” to view all of that “important” information.

In addition, thanks to a re-start of the conversation on Twitter Jake Archibald has found a study that, while not exactly addressing the entire topic, does address it in part: Does Domain Highlighting Help People Identify Phishing Sites? The non-paywalled PDF file was found by Manu Sporny. Some notes:

Our research asks a basic question: how well does domain highlighting work? To answer this, we showed 22 participants 16 web pages typical of those targeted for phishing attacks, where participants had to determine the page’s legitimacy. […] We conclude that domain highlighting, while providing some benefit, cannot be relied upon as the sole method to prevent phishing attacks.

Now to change gears again, for those who claim that browsers have always shown the full URL, I present the following evidence that it's not quite true: Lynx 2.8.1 (one of the browsers I used daily back in the old days, not as a novel testing tool).

A screen shot of Lynx 2.8.1 viewing a page at CNN with no visible URL, as well as no obvious way to display it.

Update: May 13

A couple more interesting reads have popped up. One is a more in-depth and sweeping discussion from Jeremy Keith that builds on his original post and equates the removal of relatively small features with the long-term removal of control from users: Seams

The other one I missed during my first update to this post. Nicholas Zakas argues that URLs are already dead.

Comparing Opera Mini and Chrome Compression

Depending on how much you spend staying up on web browsers, you've probably heard the cry of Opera did it first more than once (though the low-hanging fruit, browser tabs, wasn't technically Opera first). When Google announced that Chrome would offer a data compression mode, you may have figured you'd hear it again owing to Opera Mini.

In 2004, Opera developed Mini as a browser backed by proxies to help reduce data use and speed up the overall experience. In 2006 Opera Mini went worldwide. Sadly, StatCounter doesn't break Opera Mini out from regular Opera Mobile, so it's hard to get a sense of Mini's market share. Opera's own numbers, however, report 241 million Mini users worldwide in November of 2013, with an annual increase of 21%.

Chrome for mobile devices has been climbing in use, partly because Android devices have started to move away from the default Android browser (though this doesn't affect all the Android 2.x devices and many of the 4.x devices that will be out there for a while). By adding support for data compression, Chrome is that much more appealing to users who have bandwidth caps, poor connections, or any other factor that limits how well they can see fat pages. Interestingly, some of the data compression comes from converting all the images to WebP (ol' Gil has finally found a way to make that format work). Chrome also automatically puts you into Safe Browsing mode as part of its compression process.

So I fired up both browsers, chose a list of web pages/sites that I haven't surfed using either of them, dropped into 3G and started my compressed surfing. These are the results:

Chrome requested 18.70Mb of data and compressed it to 4.83Mb, for a compression rate of 74%.

Mini requested 12.9Mb of data and compressed it to 3.7Mb, for a compression rate of 72%.

This test was by no means rigorous or scientific. While Chrome compressed just a bit better overall, I felt like the experience was slower than on Mini. Chrome was also served much more data, perhaps owing to browser detection scripts offering more "features" to Chrome, or Mini's rendering engine just ignoring some of the elements it didn't know.

For those who have decided that Google is the great new evil, you may want to consider that Google proxies are between you and the web for every request when using Chrome's compression. For Mini users the same is true of Opera's servers, but far fewer people seem to be concerned about demonizing Opera Software. How much stock you put into Google's Safe Browsing technology behaving as some sort of censor is up to you and your own paranoia. I don't much care either way, but some folks might. As someone who's used Opera Mini for years when I travel outside the U.S., I'm very comfortable with it and doubt I'll switch — it's easier for me to just fire up Mini than it is to navigate Chrome's menus to enable compression.

By the way, the pages I used for my test:

• http://www.todaysiphone.com/2014/01/apples-iwatch-much-imagined-latest-rumors-anything-go/
• http://www.fluevog.com/code/?w[]=gender:men&perpage=-1
• http://www.orlandosentinel.com/news/local/trayvon-martin/os-metrowest-shooting-stand-your-ground-20140117,0,885944,full.story
• http://www.barrelny.com/blog/text-align-justify-and-rwd/
• http://scatterfeed.wordpress.com/2014/01/18/natures-squeegee-the-nictitating-membrane/
• http://gallery.bridgesmathart.org/exhibitions/2014-joint-mathematics-meetings/blbodner
• http://www.novayagazeta.ru/photos/61844.html
• http://pluto.jhuapl.edu/gallery/sciencePhotos/image.php?page=2&gallery_id=2&image_id=63
• http://blogs.channel4.com/factcheck/factcheck-immigrants-pay/16332

My Kingdom for Decimal Alignment on Numbers

This post isn't proposing any solutions (although I do toss out a hack). This post is a rant that I hope helps influence browser makers.

Background

Much of my web work isn't for public facing web sites. Often it's for enterprise-level software that is deployed via the web and used in a web browser. I think any web developer who does anything beyond standard brochure-ware is ultimately in the same boat. Usually we need stylistic control over elements on the page that aren't typically considered exciting.

Once again I find myself working on a reporting feature for a large piece of software. Reports are typically grids (a table) made up of columns & rows with numbers, letters, icons, colors and so on. Clients are used to seeing these reports the same way they might see them in Excel, Crystal Reports, and similar tools.

These reports are formatted for quick visual scans to identify outliers and exceptions, so control over formatting is key to their effectiveness.

Example

Often these grids contain numbers of various lengths that include decimals. Often these decimal values aren't the same number of (significant) digits. Let me offer an example of wildly divergent numbers (I cannot show real client data):

Name	Number	Units
George	1,984.0	years
Arthur	42.000	?
Ray	451.0	degrees
Marie	13.51	g·cm−3
Isaac	6.67384	(× 10-11) m3 kg-1 s-2
Sergei	289.8001	billions of dollars

It's standard practice to align numbers to the right. The problem is that some numbers have decimals lengths that don't match other numbers, thereby throwing off the formatting and making the entire column harder to read than necessary. Note that the biggest number is the same length as the smallest number.

CSS to the Rescue

CSS3 has a solution. The property text-align has an option to solve our problem. It can accept a one character string as the character on which to align the text.

Not just a decimal, but a string. This is great news for languages that use a comma instead of a period for decimals. It's great news for very large or very small values where perhaps you want to align on the multiplication sign instead.

This style will allow me to align on the decimals in my example table: text-align: "." right; (the keyword after the string still keeps my numbers aligned to the right, after the decimal is factored in)

Browser Support

Now the question comes down to browser support. What browsers support it? None.

A Hack

To achieve the effect I want, I would have to split my numbers into two columns, one for the whole number and one for the decimal value. Like in this hack:

Name	Number		Units
George	1,984	.0	years
Arthur	42	.000	?
Ray	451	.0	degrees
Marie	13	.51	g·cm−3
Isaac	6	.67384	(× 10-11) m3 kg-1 s-2
Sergei	289	.8001	billions of dollars

This table isn't ideal. I have to clear out padding values, remove borders, and accept that my numbers are split. It is unnecessary work that could be avoided if the browser makers would just fully support an aspect of CSS3 that has been around for years and whose related styles already have seen support for even more years across prior CSS versions.

The extra styles, whether inline or with per-cell classes, also add to the overall page weight. HTML tables aren't exactly examples of slim mark-up to begin with, but this can bloat them even more.

This table is also an accessibility gotcha. Users with screen readers are used to a particular way tabular data is read, so this variation may not come across so clearly. Users who scale text may see odd baseline text alignment as text wrapping in other columns can throw off everything else.

It is likely that others who have needed to represent data with alignment on specific characters have just used images instead. That solution is far worse than even this hack, particularly from an accessibility perspective.

My Request to You

If you work for a browser maker, please bring this to someone's attention.

If you don't work for a browser maker, please share this (or your own examples) so that perhaps the browser makers will see there is a need, even if it's not as sexy as animations, transitions, WebGL, and so on.

Related

Even in the modern international web, the specification is sometimes too Anglo-centric, as in the case of the input type="number", which isn't as universal as hoped. You can read about the request to allow developers to set a pattern attribute on input type="number" to specify the thousand separator, decimal separator, decimal precision and if any special characters should be allowed.

There are also people calling for Mozilla to drop support for MathML, suggesting that people who don't use numbers in financial and scientific applications on a daily basis may not see the value in stronger support for number formatting.

Chrome: Blink and You Missed the News

It's old news by this Thursday morning, but in case you had not heard, Google is forking WebKit to make its own rendering engine, Blink. Opera will be using the Blink fork of WebKit as its rendering engine.

A combination of people who are far smarter, far more well connected, and in timezones that allow them to write about this sooner, along with all the Twitter chatter, has already hashed out the major details. As such, I will link to them below. I would be a terrible blogger if I didn't offer my opinion, however.

I will format this the way I did when I provided my in-depth analysis of Opera's move to WebKit (away from Presto) less than two months ago.

So what does this really mean?

For Developers

Any developer who is complaining that this means there is another browser/engine against which they will need to test has been doing it wrong.

Web developers should always test against different browsers, regardless of their engine. In particular, WebKit has so many nuanced implementations that not independently testing against each browser that uses WebKit belies either a lack of understanding of how WebKit is implemented or laziness.

If you aren't sure what is different between each WebKit implementation (Chrome, Safari, Android browser, Opera, etc.), I encourage you to read my post "WebKit Will and Won't Be the New IE," where I provide a high-level overview of these variances.

For Users

At this point it doesn't mean a whole lot.

Google will argue this is better for users. Apple will argue that Google took its ball and left. Opera won't be arguing. None of that impacts users because we have mostly done a good job of promoting standards-based development. I again refer you to "WebKit Will and Won't Be the New IE" for how poor testing can impact users, but that's not a function of the engines.

Because Apple only allows WebKit on iOS devices, and even then it restricts those browsers to a different JavaScript engine and thus a lesser experience, Chrome and Opera for iOS may still stay on WebKit. Over time as its harder to incorporate features from Blink back into the WebKit core, there may be feature divergence which may affect users.

That's just speculation on my part.

For Standards

For a specification to become a W3C recommendation, there must be two 100% complete and fully interoperable implementations, which basically means two browsers need to support it. When Opera announced the shuttering of Presto, that left Trident (Internet Explorer), Gecko (Mozilla), and WebKit (Safari and Chrome) as the remaining engines (of measurable size). Essentially, two out of the three of them had to agree to implement a feature.

With Blink, provided the W3C recognizes it as a stand-alone engine, there is now one more engine back in the mix, essentially returning the count to where it was in February before Presto's wind-down (to be fair to Presto, it's expected to exist in the wild until 2020, but with no new feature development).

I am hoping that this is a good thing for standards.

Blink won't be using vendor prefixes (even though it will have inherited some), so I consider that a step in the right direction. While I think this matters to developers, I think it matters even more to standards.

Technical Aside

From Peter-Paul Koch:

Chrome 28 will be the first stable release to use Blink; earlier versions will use WebKit. Opera and Yandex will start using Blink whenever they start using Chromium 28.

Related

First some bits from The Twitters:

Let's bring back the Netscape engine and call it Spacer! RT @codepo8: After blink Microsoft might bring out a new engine called marquee

— Adrian Roselli (@aardrian) April 4, 2013

And *this* is how you fork a repo.

— Sylvain Galineau (@sgalineau) April 3, 2013

Can the new Blink logo be >_<?

— Mike Taylor (@miketaylr) April 3, 2013

And now to the related links:

• Blink: A rendering engine for the Chromium project, April 3, 2013.
• Developer FAQ, The Chromium Projects.
• Hello Blink, from Bruce Lawson (who clearly hates Morrissey doesn't care for most of Morrissey's solo work).
• Hello, Blink! from Paul Lewis
• Discussion on Hacker News about how Google controls WebKit.
• Well, err, that solves the WebKit monoculture problem, from Jake Archibald.
• Google Announces Blink, Its Own Rendering Engine For WebKit. at Read Write
• Blink from Robert O'Callahan.
• Discussion on Hacker News started from Apple's perspective.
• Google going its own way, forking WebKit rendering engine at ars technica.
• Just One WebKit from James Socol.
• Why What You’re Reading About Blink Is Probably Wrong from Alex Russel.
• Blink. Chrome’s new rendering engine from Eric Bidelman.
• [webkit-dev] Cleaning House thread at the WebKit mailing list in the wake of the Blink news, along with the announcement on the list.
• A Short Translation from Bullshit to English of Selected Portions of the Google Chrome Blink Developer FAQ from Rob Isaac.
• Blink from Peter-Paul Koch.
• Another first by Opera! from WebKit Memes.
• Thoughts on Blink from Krzysztof Kowalczyk.
• Welcoming Blink, Chromium’s new open source rendering engine from Peter Beverloo.

There's this one from 2010 by Haavard Moen that I thought worth highlighting: "Dear Google: Please fork WebKit."

Update, 5:35pm

A video Q&A from Google Developers about Blink (time markers available on the Chromium blog).

WebKit Will and Won't Be the New IE

Web developers have been looking to call everything the new Internet Explorer for a while now. With Opera's recent move to WebKit as its rendering engine (replacing Presto), even more developers are suggesting that WebKit is becoming the new IE.

I think they are right, but for the wrong reasons.

How WebKit Won't Be the New IE

nice! opera for android beta includes support for @ supports. AFAIK, the first WebKit-based browser to release with it.

— Tiffany B. Brown (@webinista) March 6, 2013

Unlike Trident (Internet Explorer's rendering engine), WebKit can be wielded in many different ways by many different browsers. It's less a singular rendering engine and more a collection of pieces and parts that can be assembled in different ways. The tweet above demonstrates that there can be different WebKit implementations.

You may argue that the example above is just a case of the first implementation of an update that will make it into all browsers that use WebKit. That may very well be true (we don't know yet), but there are many more examples of differences as Paul Irish painstakingly details in his post WebKit for Developers. I encourage you to read it because it's an almost hilarious dive into the rabbit hole of WebKit. The most salient and clear point is the bullet list of what is not shared in WebKit ports:

• Anything on the GPU
  • 3D Transforms
  • WebGL
  • Video decoding
• 2D drawing to the screen
  • Antialiasing approaches
  • SVG & CSS gradient rendering
• Text rendering & hyphenation
• Network stack (SPDY, prerendering, WebSocket transport)
• A JavaScript engine
  • JavaScriptCore is in the WebKit repo. There are bindings in WebKit for both it and V8
• Rendering of form controls
• video & audio element behavior (and codec support)
• Image decoding
• Navigating back/forward
  • The navigation parts of pushState()
• SSL features like Strict Transport Security and Public Key Pins

That amounts to quite a lot of potential variance between WebKit-powered browsers, which is how WebKit is not the new IE.

How WebKit Will Be the New IE

IE10 has been out mere hours, and I already see devs bragging about dropping IE9 support. Do these people build for users or ego?

— Adrian Roselli (@aardrian) February 27, 2013

Far too many developers are always looking for ways to justify testing less. It could be laziness, it could be lack of access to enough device configurations, it could be … well, frankly, I think it's the first one. My IE10 tweet above was based on watching people thrilled as much at taking a shot at Internet Explorer as they were at feeling they could test on one fewer browser.

Developers may use the common engine in one browser as justification for not testing on all the WebKit browsers, or they just may not know about the potential for dramatic differences between implementations. What happens when everyone builds for one awesome browser engine (or one perceived common engine)? We end up with a browser monoculture, devoid of testing for other variations.

As a web developer since the dawn of the web, I've seen it happen before. I remember surfing on Netscape only to find a site didn't take into account my screen colors or resolution, or on Internet Explorer only to find a site didn't take into account my laptop pixels-per-inch default. I was using the popular rendering engine of the day, but the assumption that all users on that engine would all have the same experience was wrong then, and it will be even more wrong now.

WebKit will become the new IE if web developers continue these false assumptions and fail to test other WebKit implementations. Developers will build for one implementation, test for it and maybe a couple variations, and call it a day.

Conclusion

My fear is that all the gains we've made in the last few years toward a more inter-operable standards-based web (leaving behind the Internet Explorer monoculture) will fall away as we unwittingly move toward a WebKit-tweaked yet non-multi-WebKit-inter-operable web.

In short, we'll test for one WebKit, not realize (or care) about all the other variations, and end up breaking the web all over again.

WebKit won't be the new IE, but WebKit will be the new IE.

Opera: Presto! It's now WebKit

Opera is replacing its Presto rendering engine with WebKit (Chromium, really, when you factor in the V8 JavaScript rendering engine). Big news as of this morning.

If you've been paying attention, it's not really that big or news. About a month ago a video was leaked showing Opera using WebKit (the video has since been pulled from YouTube). Within the last three weeks two of the Opera folks I follow on Twitter are suddenly no longer Opera folks (Tiffany Brown, Patrick Lauke). Heck, even Opera's founder sold off some shares yesterday. If you paid attention, you knew something was up.

All of that aside, what does this really mean?

For Developers

I feel most web developers already ignored Opera. For those developers they can continue to be lazy and ignore Opera.

For Users

The short term impact on users will be minimal. Users will upgrade, users will surf, users may notice some sites work or look a little better.

For users trapped on old Android devices with the Android stock browser (that never seems to upgrade), this could result in a better experience — assuming these users know about and download the Chromium-powered Opera.

For Standards

Opera has an impressive place in the mobile world, being at the top of the pile globally. Opera's participation in the standards process has been valuable, partly because its rendering engine has been used to help move the process forward thanks to early implementations, differences in implementations, and arguments over implementations.

While the standards evangelists at Opera may do a great job of contributing back to Chromium, Google may be the block from those changes being committed. Even when changes get to Chromium, there is no guarantee that they'll make it back into WebKit, which might involve getting past Apple. Only if those changes get into WebKit do they stand a chance of making it Apple's Safari.

From the co-chairman of the W3C CSS Working Group, Daniel Glazman:

For the CSS Working Group, that's an earthquake. One less testing environment, one less opportunity to discover bugs and issues. Let me summarize the new situation of the main contributors to the CSS Working Group:

• Microsoft: Trident
• Apple: WebKit
• Google: WebKit
• Opera: WebKit
• Adobe: WebKit and their own Adobe Digital Editions rendering engine found in many ebook readers
• Mozilla: Gecko
• Disruptive Innovations: Gecko
• HP: has delivered WebKit-based products in the past but is pretty browser-agnostic IMO
• Rakuten: ADE and probably WebKit
• Kozea: WeasyPrint
• Qihoo 360 Technology Co: both Trident and WebKit
• other Members of the Group: I don't know

Suddenly I feel like the US political term lead from behind is apt.

Some other reactions from the Twitters:

It’s becoming clear that WebKit:browsers::MS Word:word processors.

— Eric A. Meyer (@meyerweb) February 13, 2013

And all other engines perished to make way for the best, most popular one.It was called IE6 and the year was 2000…Remind you of something?

— Lea Verou (@LeaVerou) February 13, 2013

Related

...to the news about Presto

• Opera Ice: New browser for Android and iPhone coming February uses WebKit (video), January 18, 2013 from Pocket-lint.
• WebKit is not a cure-all, February 1, 2013 from Tiffany Brown, formerly with developer relations at Opera.
• 300 million users and move to WebKit, February 13, 2013 from Opera itself.
• And Then There Were Three, February 13, 2013 from Robert O'Callahan.
• Strange day for the Open Web, February 13, 2012 from Daniel Glazou.
• Jake Archibald gives his take over at Google+, February 13, 2013.
• Opera switching to WebKit: thoughts and guesses, February 13, 2013 from Peter-Paul Koch.
• The WebKit Culture & Web Rendering Engine Diversity, February 13, 2013 from Robert Nyman.
• I will miss the “Douglas Crockford of browsers” February 13, 2013 from Christian Heilmann.
• One less browser engine, February 13, 2012 from Tristan Nitot.
• Opera and WebKit: a personal perspective, February 13, 2013 from Bruce Lawson (from Opera, the guy who wrote the announcement I link to at the start).
• Hey Presto, Opera switches to WebKit, February 13, 2012 from Ars Technica.
• Devs respond to Opera WebKit switch, February 13, 2013 from .net Magazine.
• Presto Change-o, February 13, 2013 from Eric Meyer.
• Bruce Lawson on Opera’s Move to WebKit, February 13, 2013 from A List Apart.
• Hey -o-, let’s go!, February 13,2013 from David Storey.
• Another chapter of a long goodbye? February 14, 2013 from Charles McCathie Nevile.
• WebKit: An Objective View, February 14, 2013 from Robert Nyman and Rob Hawkes.
• A few folks have asked me what I think of the news..., February 15, 2013 from John Lilly.

...to older bits

• Browser Makers Caving to Vendor Prefix Misuse on this blog, Feb. 9, 2012.
• CALL FOR ACTION: THE OPEN WEB NEEDS YOU *NOW*, February 9, 2012 from Daniel Glazou.
• Reading List – Vendor prefixes, mobile, monoculture by Bruce Lawson, Feb. 13, 2012.
• The iPhone monoculture by Peter-Paul Koch, Feb. 20, 2012.
• Developers focus on the iPhone too much at .net Magazine, Feb. 21, 2012.
• Report on the activity of companies in the WebKit project, February 6, 2013.
• Don't Blame Opera, Blame Devs on this blog, April 27, 2012.

...And evidence that lazy developers can keep on keeping-on (from almost a year ago):

I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept.

— Stephanie Hobson (@stephaniehobson) April 26, 2012

Update, February 14, 2013

Since I posted this, some folks have asked just what Opera did that was so useful? This quote from David Storey's post outlines some of it pretty well:

Moving from HTML to CSS based layouts? Opera was perhaps the first to have a useable CSS engine. Håkon (father of CSS, and Opera CTO) often says it was the reason he started to believe a browser could be made in Norway, not just the USA, and joined Opera. AJAX? Opera reverse engineered this from MS’ ActiveX based approach and were the spec editors through Anne van Kesteren. HTML5? Started at Opera with Ian Hickson and others. Responsive web design? Media Queries came from Opera, and were implemented for years before showing up in other browsers. What about native video on the Web? Opera again.

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.

Three Browsers in One: Lunascape

I like to think I'm pretty smart about web browsers, sporting four on my mobile phone and six on my desktop computer in regular day-to-day use. Heck, I even started the evolt.org browser archive back in 1999 with 80 unique browsers at the time (which I am pimping to the W3C Web History Community Group).

But then this tweet came through my timeline:

Turns out there is a three-engine WebKit/Gecko/Trident browser en.wikipedia.org/wiki/Lunascape Uh.

— Sylvain Galineau (@sgalineau) May 24, 2012

How did I miss this?

So I went to the Lunascape Wikipedia article, and then to the Lunascape English site and promptly downloaded it.

It's too early for me to review it, but I did run a quick check to see how it reports itself in the user agent string as compared to the browsers whose core rendering engines it is using. My results...

Trident

Internet Explorer version 9 reports itself as:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Lunascape, when using the Trident rendering engine, reports itself as:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2; InfoPath.3; Lunascape 6.7.1.25446)

Gecko

Firefox 12 reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0

When using the Gecko rendering engine, Lunascape reports itself as:

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120410 Firefox/3.6.28 Lunascape/6.7.1.25446

Webkit

Chrome 19 reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.46 Safari/536.5

Safari 5.1.2 for Windows reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.1.2 Safari/534.52.7

Under the Webkit engine, Lunascape reports itself as:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.3 (KHTML, like Gecko) Lunascape/6.7.1.25446 Safari/535.3

Conclusions

It looks like Lunascape doesn't share the rendering engines for Gecko and Webkit with the browsers in which we've come to associate them.

Beyond that, I have no conclusions. I was just looking at the UA string and figured others might find it interesting and/or useful.

Don't Blame Opera, Blame Devs

On Wednesday news broke that Opera was going to support some Webkit CSS vendor prefixes. On its surface I thought this wasn't exactly big news. There was a good deal of hubbub about this back in February (Browser Makers Caving to Vendor Prefix Misuse) when word got out that Mozilla, Opera and Microsoft were all considering supporting the -webkit prefix.

Many standards-focused developers (including me) were horrified, even though this has been a concern for over two years (as I note in Perplexing Prefixes). Some of them even took action to either convince developers to fix their code, get like-minded developers to fix others' code, or petition browser makers not to cave.

I think it's fair to say that the first two tactics haven't worked. In light of that, it was just a matter of time before the browser makers would start supporting the dominant codebase — even if it's only dominant because of developer misuse.

Now Opera is catching a lot of heat from people for caving. Some are pointing to Microsoft's statement that it won't support the -webkit prefix as an example of how not to play the game. Others feel betrayed that Opera, often the most standards-compliant of all the browsers, would now make such a move. Few of these people consider the business case for Opera. Opera has dominated the mobile market, and when web sites don't render properly — because of a developer who is either not coding to standards or is not including the -o prefix alongside the -webkit prefix — users may move to the browser that doesn't look broken. Opera is making a business decision to protect itself.

Wednesday on Twitter I placed the blame at the feet of lazy web developers. I still feel that way. My previous posts on this topic have been clear on this. If web developers took the time to learn the specifications, look at code generated by editors (if they use them), tested in other browsers, and shed their myopic view of how people surf, we would not be in this position. Developers can fix the code, see errors when testing, and otherwise not cut corners. I suspect there are lots of developers who know this and lots more who can be educated by the names and voices on the web now.

And then I saw this, retweeted by Zeldman, possibly in a show of support:

I don't include the -o- prefix because I don't test in Opera because it accounts for 0.3% of our visitors. Not because I'm lazy or inept.

— Stephanie Hobson (@stephaniehobson) April 26, 2012

If her percentage is not hyperbole and applies to all the sites she manages, then the time it took her to see those numbers and produce that tweet is about how long it takes to open Opera and paste in a web address.

This is why the browser makers are caving. This attitude is pervasive. Hers is just one example. I have seen similar comments around the web, ranging from those who have no idea what browsers visit their sites to those who just don't care. Telling someone they are wrong, myopic, and definitely not serving the needs of their users, clients, or even the rest of the web, just causes that person to ignore you or lash out.

You can run the math yourself using the percentage in the tweet. Take a site with a million visitors and you'll see that 0.3% is 3,000 users. In accessibility circles, that's an unacceptable number of users to shut out. Imagine 0.3% is an acceptable number to ignore on a larger site, perhaps even as big as Facebook with 800 million users. At 0.3% that's 2.4 million users. At what number of users is 0.3% acceptable? How many developers of large sites feel bolstered by such an attitude, reinforcing their own poor habits?

The question to web developers really should be, how many users are you willing to sacrifice because you are too lazy to open a browser and at least look?

This example of webs.com shows that just opening the home page in Opera would have shown it's broken, meaning either they didn't look or they don't care. In Opera it looks like this (as compared to Safari), hiding its main sales pitch (the issue starts at line 86 of the webs.com CSS file):

There just isn't an excuse. Stop blaming the browsers and the editors and instead review your code and test in browsers.

Related

• Opera confirms WebKit prefix usage at .net Magazine. Read the comments, they include an Opera employee explaining the reasoning behind the -webkit support.
• Opera's supporting of the -webkit- prefix by Niall McMahon.
• A lively debate at Hacker News.
• On vendor prefixes and WODs by Ian Devlin.
• Opera Confirms WebKit Prefix Usage by Faruk Ateş.
• The Open Web and CSS prefixes by Daniel Glazman.

Posts that pre-date this news from Opera:

• CSS vendor prefixes considered harmful, March 22, 2010 by Peter-Paul Koch.
• Not Supported, March 22, 2010 by Jonathan Snook.
• Coping with CSS vendor prefixes, March 22, 2010 by Stephen Hay.
• CSS vendor prefixes redux, March 23, 2010 by Peter-Paul Koch.
• Vendor Prefixes Are Hurting the Web, November 15, 2011 by Henri Sivonen.
• CSS vendor prefixes, an answer to Henri Sivonen, November 16, 2011 by Daniel Glazman.
• Vendor Prefixes Are A Rousing Success, November 18, 2011 by Alex Russell.
• Perplexing Prefixes, November 22, 2011 by me.
• The vendor prefix mess, February 9, 2012 by Peter-Paul Koch.
• Browser Makers Caving to Vendor Prefix Misuse, February 9, 2012 by me.
• Vendor prefixes are not developer-friendly, March 4th, 2012 by Paul Irish.

And a post that pre-dates all of this stuff:

• To Hell with Bad Editors, February 28, 2001 (also at evolt.org) where 11 years ago I don't accept that browsers are the issue (To Hell With Bad Browsers), I put the blame squarely on developers. Apparently we are doomed to keep repeating the same mistakes.

Update 11:40am

Opera has posted the announcement about the vendor prefix changes: Opera Mobile Emulator build with experimental WebKit prefix support. If you read through it, you will see only 13 -webkit properties (shadow, transform, border, transition) which are just being aliased to existing -o prefixes. It looks like Opera is not trying to mimic how Webkit renders the styles, only map the prefixes to Opera's existing support.

Update April 30, 2012

More posts and articles have surfaced over the weekend and today. I link them here:

• Concerns About Opera Rendering Webkit Properties by Ian Lunn.
• On Opera’s Implementation of WebKit Aliasesby Peter Gasston.
• Prefixes by Anne van Kesteren.
• Opera Mini Now Has 169 Million Users, 56% Of Them Only Use The Mobile Web at TechCrunch.

Update May 2, 2012

• Why O, why? Thoughts on Opera's Implementation of WebKit's Prefixes at WebKitbits.
• Vendor Prefixes, the wider problem by Matt Wilcox.
• CAFBank and Server Side User Agent Sniffing from Opera, showing how a bank ignores a 5-year-old request from users and Opera to stop explicitly blocking Opera. An example of blocking for no good (presented) reason.

Update July 6, 2012

Thiemo Mättig tried to comment below, but had trouble with the form. He let me know that he reached out to Webs.com to notify them of the bad CSS I mention above. All Webs.com did was add a solid background color, no -o- prefix and no unprefixed version.

@maettig Thanks for the notice

— Webs.com (@webs) May 2, 2012

@maettig This is not one of the browsers that we currently support at this time.

— Webs.com (@webs) May 14, 2012

The Return of “Best Viewed in…”

The graphic above (and its lengthy alt) is a parody based on a rather neat utility called the HTML5 Please API. You can drop the code onto your cutting edge demo site and it will indicate to a user what browsers support the features within. The code stays current by leaning on data from CanIUse.com

You can see this code in action by grabbing any browser that isn't Chrome or the latest version of Firefox and visiting mothereffinganimatedgif.com, a browser-based utility built in 24 hours to produce animated GIFs.

The feature is great for demo and practice sites, but there is a risk that developers may drop this onto end-user facing sites without building appropriate alternates or back-ups to the features. The language for this project doesn't help:

If you've created a demo or site that requires Canvas or WebSQL DB, you've been in the awkward situation of telling some of your visitors that their browser isn't good enough.

That last part gets me. The first part does, too (demo or site), but the last part is the modern version of "best viewed in Internet Explorer." Those of us who've been doing the web thing since its start know the disdain and disrespect for our users that message entails and have moved beyond such statements. Younger developers who are fascinated with all the "new shiny," on the other hand, may take the explanation as validation that they can just ignore users who aren't on the browser the developer has decided to support.

We have plenty of evidence to suggest that a browser monoculture is coming back, a repeat of the monoculture that we as developers created when we built for IE6 only, and now we rail against as if it's the user's fault.

The ongoing battle over vendor prefixes in CSS is a current example of the Webkit, or perhaps more accurately, iPhone mnonoculture that is developing:

• Browser Makers Caving to Vendor Prefix Misuse on this blog, Feb. 9, 2012;
• Reading List – Vendor prefixes, mobile, monoculture by Bruce Lawson, Feb. 13, 2012.
• The iPhone monoculture by Peter-Paul Koch, Feb. 20, 2012;
• Developers focus on the iPhone too much at .net Magazine, Feb. 21, 2012.

An sample that came across my Twitter feed is a rather nice mini-site called "The New Web Design Guidelines." It uses an attractive design with clean cutting-edge transitions and animations, while promoting support for touch, displays of any size, and exploration. The new guidelines also suggest blocking any browser that isn't Webkit:

For this screenshot I had to scale the page down. It seems designing for displays of any size work as long as the aspect ratio isn't a netbook. Even when I could see the animations (using Chrome) I had the same height problem.

What's so frustrating is that I have seen similar effects on other sites that work fine in Mozilla and Opera, but this developer has chosen to forbid those browsers from seeing the page. If these are truly the new design guidelines, then we may already be too far into a browser monoculture to climb back out any sooner than 10 years from now.