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.
5 Comments
Reply While I'm very worried about the browser monoculture, and the web design guidelines thing is ridiculous, I'm phlegmatic about the HTML5 Please API *if it's used correctly*.
After all, some sites just can't have a backup – e.g., Paul Neave's HTML5 webcam toy just *can't* work without getUserMedia support.
The mothereffinganimatedgif.com site that you link to is a good example if an edge case. It requires Blobbuilder to construct the Gif in memory. It uses Drag and Drop as an input method and, if coded as a production site rather than just a fun demo, should really fallback to conventional file upload input elements for browsers without D&D. However, it doesn't, and that's listed as a necessary feature when actually it's only a progressive enhancement.
But at least by using the ap.html5please widget, the user isn't browbeaten to try the site author's favourite browser, but which ever ones support all the necessary features. And if the newest version of the visitor's own browser supports them all, she'll be prompted to upgrade which I think is far more polite than badgering a user to change their browser *just to see your site*.
I agree with you about the language "their browser isn't good enough" is somewhat disdainful, so forked it on github and amended it – the pull request has been merged: https://github.com/h5bp/html5please-api/pull/57#issuecomment-4325240
Reply Bruce,
I agree the HTML5please API is a very useful widget for identifying what browser can enjoy specific features on a site. I think it's well done and smart. I am concerned instead that developers who don't understand its purpose will start to drop it on production sites without appropriate fallbacks because this is easier and somehow validated by the names associated with it.
Thanks for the Git update. And thanks for taking action instead of just whining about it like it seems I am doing.
Reply Such is the modern browser fanboy mentality in me, I created a tool for working with the always-cumbersome IE6. With IE's conditional statements, anything under IE7 gets redirected to this tongue in cheek F-Off notice page that uncannily looks like a Firefox error page:
Reply The top browsers are free to download and they are only done once so I don't see the problem. Many PCs like mine have IE, Firefox and Chrome. For HTML5, only Chrome and the latest Firefox supports it because it is new technology. Many programmers are and should be thinking ahead by programming for HTML5 and making use of the latest features on offer. I'm sure a user will not mind switching browsers to see the latest HTML5 has to offer.
Reply Ezani,
A user like you or I, who have some sense of what is on the horizon and are technically capable, won't mind switching browsers.
Users like the average office worker or home user don't care about HTML5 — if they even know what it is. Those are the bulk of the users on the web.
The argument you make goes back at least 15 years and has consistently proven that it doesn't pan out as we hope. If so, Microsoft wouldn't have had to start a "kill IE6" campaign a decade after the browser was released.
As for browsers supporting the latest HTML5 (or, rather, its related specifications) has to offer, a quick look at the WHATWG mailing list or the CSS vendor prefix chaos demonstrates that the latest things change quickly and developers do a poor job of going back and correcting old projects.
Leave a Comment or Response