Paul Irish

You may soon be developing for 76 browsers.

(╯°□°）╯︵ ┻━┻

Lemme take a step back… So it's fair to say that for most of us, IE6 has gone the way of the dodo. Good! Now in IE7, we have less CSS issues, working PNGs, but pretty much the exact same JavaScript engine (though faster). IE8 gives a few more goodies (localStorage, postMessage, hashchange event) that'll be nice to use when we retire IE7, but IE8 will be with us for a while.

Since Windows XP still accounts for 46.6% of Windows users, IE9+ adoption has a significant upper bound. More: How Microsoft is handicapping its own web browser and IE9 adoption is painfully slow. Google to the rescue?

IE6 has been a source of pain for… I'd say four years. IE8 will be a source of pain for the next 9, it appears. You're clearly aware that IE9 (and IE10…) are not available on Windows XP, even though Firefox and Chrome continue to ship versions for that operating system (still 40% of the Windows market), so unless the whole world shells out $79 for an upgraded OS, they won't get an upgraded browser, without switching. That's terrible, clearly. But this isn't the worst part. No, no…

How many browsers would you like to support?

Personally, I'm totally happy supporting the latest version of each of the five browsers. IE10 will be a very impressive browser, and the latest releases of Chrome, Firefox, Safari, and Opera are all incredible as well. Supporting the legacy versions is not exactly my idea of a good time, but ya know.. With IE6,7,8,9.. I'm used to it.

It's about to get worse

IE looks to be on a yearly release cycle. Great! IE10 out in March-ish.. IE11 a mere 52 weeks after that. (Mind you, Firefox and Chrome are shipping every 6 weeks these days). But what's far more important than shipping frequency, is the browser half-life.

Products like Windows and Office have a lifecycle policy that typically runs 10+ years because that’s what these organizations need. As part of Windows, IE honors that 10+ year commitment.

~Dean Hachamovitch, IE Corporate VP

IE9 and IE10 are both scheduled to be sunset (as far as official Microsoft support) in 2020. Since IE8 shipped with Windows 7, we can expect the same death date for it. Yes, IE8's death date is 9 years from now. Meanwhile, you won't have to worry about supporting Firefox 6 or Chrome 13 in November.

Extrapolating this, if they maintain the same policy, IE17 be released in 2019, before IE8, 9 and 10 finally die. So in a few years from now, you'll be supporting one version of Chrome, one version of Firefox, one of Opera, (probably) one of Safari, and ten versions of IE.

Did I say 10 versions of IE? I meant to say 72.

72 versions of IE on the wall, 72 versions of IE… Maybe drinking beer at this point in the post would be a smart move.

So you're aware that IE ships with multiple document modes. IE essentially ships with legacy versions of the renderer so that you can upgrade your browser but still see content that was terribly coded and cannot withstand the reality of web development, therefore it needs to be locked into a single version. I worded this differently a bit ago.

We seem to be using this term of “intranet apps” or “internal corporate apps” just as a euphemism for poorly written code.
Consumer facing apps have been handling new and unknown browser versions day in and day out for years. Like Kroc said, “Corporate users should be testing their applications against standards, not browser version numbers.”

So IE9 contains IE8, IE7, and IE5 modes. IE10 contains modes for IE9 and on down the line.

The problem percolates when you come to terms with the fact that many of these modes are not the same as the original browser. For example:

• IE8's IE7 mode: adds sessionStorage & localStorage, false positives on a feature test for the hashchange event, mishandles rowspan, and some other event and attribute differences.
• IE9's IE8 mode: intermittently false positives on a feature test for inline SVG. Renders CSS differently than true IE8, and is crashier than the real one.

These are not browsers with reliable replicated browser versions embedded, these are frankenstein versions that behave unpredictably. (To better understand the internals, the new JScript engine (these days it's called Chakra) is used in the compatibility modes, but IE engineers remove features and add bugs to make them "match" earlier behavior. Luckily they run at their modern speed, but run with a whitelist of bugs being put in place. MSFT has all reason to keep these compat modes as identical as possible, so we should expect fewer issues in IE10+'s compat modes.)

Of course, there is the matter of what % of market share it takes for you to "support" a browser (test against during dev / QA against / customize your experience for).. It's possible some of these IE versions won't have enough numbers for us to care. Kind of like how we support Firefox 3.6 and 6, but not 4 or 5. (btw, Mozilla will soon pull the lever to prompt 3.6 users to upgrade).

Where, from here? Do we have solutions?

All this news isn't the best, certainly. What are our options?

Asking your users to upgrade their IE version to the latest? We've been naively doing this for a while now, but we've only been shooting ourselves in the foot. Without an upgrade policy for IE that takes the web seriously, you can't responsibly ask your users to upgrade to the latest IE (the future's boat-anchor browser.)

boat-anchor browser (noun): the browser with enough users and not enough capability, holding back the potential of the web. ^[via]

IE version pigpile. Chrome's silent auto-updates (charts via arstechnica)

Microsoft's move. Maybe the IE team will introduce a way to upgrade their users well and also serve their business audience that are interested in a snapsnot of the web that doesn't change. Maybe they'll also introduce a better solution for testing in their browsers than running four (soon five) unique Windows OS images.

Chrome Frame gives us a solid option for handling this situation. (Also, if you haven't read these three posts by Alex Russell… do so.)
At the very least, Chrome Frame will automatically update and has the user-perceived benefit of being "just a plugin" (that all users can install) instead of switching to a whole new browser.

I'm almost done, I swear

Clearly, having your users on a browser that not only iterates quickly but appreciates developers by guaranteeing a short browser half-life is a boon to you and the success of the experiences you can deliver. All the browsers are racing to deliver features and speed to you and your users (including IE).

Seriously, all browser engineers are doing incredible, fantastic work. But without a strategy for how this turns out in the long term, this IE situation will become a complete mess—costing you enormous time in designing how scale your design to 76+ browsers, testing it, QA'ing it, and maintaining it.

The IE team is incredibly talented and wise; I think they have a great opportunity here to make the right move (like when they reversed policy on X-UA-Compatible). Perhaps with Win8 and Metro we'll see a more aggressive approach towards bringing the full potential to the web to all its users.

Jonathan Snook asked me how to get insight in the Chrome DevTools on which elements are getting repainted in the browser's paint cycle.

My answer, in video form, dives into --show-paint-rects and the Timeline view. (4 min long)

Lots of small text, so fullscreening will help.

Mentioned links: Chrome's command line switches & crbug.com/71035

… or … On "the site must look the same across all browsers"

I think we're all pretty well convinced that our sites can look different across browsers. Sometimes, though, our team or our clients don't totally understand that.

Lemme take a stab at convincing them that each browser gets an experience that is customized to that browsers's capabilities.

Paul Boag actually created a small booklet for your clients on why this is good. Take a look below and download the PDF to share.

Paul lays out these arguments for things looking and acting differently:

• More time for what matters
• Develop for your growth audience
• Improve site performance by letting the experience scale
• Better search engine rankings through faster sites
• Your work will be more future proof
• … and more maintainable
• Wider and more impressive design possibilities
• Users don't open your site in two browsers

(Andy Clarke's book Hardboiled Web Design also covers this ground well)

The TAFEE approach

Taking a TAFEE approach is critical if you expect to deliver worthwhile experiences to your clients while continuing to support the legacy browsers that tend to linger around. Lemme give this guy a definition:

TAFEE (pronounced: taffy): tiered, adaptive front-end experiences. Customizing the experience to the unique capabilities of each browser, prioritizing a fast and good UX over consistency.

It's also worth bringing up a term I mentioned a bit ago:

oldIE (pronounced: oldie): Internet Explorer 6, 7 & 8. aka, the three browsers often getting the low-res experience.

Your alternative to a TAFEE approach, of course, is taking a 'same' approach, wherein things are visually and functionally consistent across all your target browsers. In my experience, this takes much more time to develop and QA—not to mention you've set the baseline experience very low.

One of the best metaphors for scaling the frontend experience comes from Nicholas Zakas I'll let his slides do the talking:

Zakas's TAFEE vs 'same' TV analogy

speedy site > consistent site

Now, it's worth pointing out that javascript runs at incredibly different speeds in the various iterations of Internet Explorer…

Given that, it's up to you to guarantee a performant and responsive experience for ALL your users. That means making it easier for oldIE to chug on your pages, serving them a lighter weight experience, in order to keep it quick.

Why should you keep your site as fast as it can be? Read up on The Performance Business Pitch by Stoyan Stefanov who lays it out best. Suffice it to say that highly performant experiences are KEY to your site

None of your users open your site in multiple browsers, so if you're actively trying to make things look the same for that false goal, then you're slowing down the page for your users on older browsers. You're loading them up with images that mimic border-radius and box-shadow, piling on scripts to maintain visual consistency when you should be focusing on making something that looks good enough and is fast. Louis Lazaris touched in this in The browser performance pickle where he identified that our goal of speed conflicts with our ability to polyfill nearly all features. (There are best practices for this, specifically… stay tuned as Divya Manian and I have something coming for this… ;)

delivering multiple versions

Consider what Google has done with the Google doodles: show off cool <canvas> or bouncing balls with just HTML+JS in "good" browsers and just keeping it the same old Google logo for slow browsers. You heard anybody complaining that they don't get the bouncy balls in IE6?

Facebook, Google, Yahoo all embrace a TAFEE approach to show different browsers different things. It'd likely be wise for you to, as well.

It might make sense for you to segment your experiences into HD (high-def), SD (standard-def) and LR (low-res) tiers. Then you might move to clarify exactly which features are required for each to identify which features are required for your HD tier and so on. IE7 and IE8 may get the LR tier, and if you've punted supporting IE6 completely, I'd recommend prompting to install Chrome Frame. It's what we're now doing in HTML5 Boilerplate 2.0, in fact.

You have some choices to make in how you scale the front-end experience, and I hope you'll have a better idea of how you'll do it and how to communicate this plan to your team and client.

Thank you to Divya Manian, who helped me tremendously with crafting this. Also she just got a sweet interview on Mozilla Hacks.

A quick 365 days after we launched the project, the community finished up 2.0 today! Briefly, what's new:

• We shifted to using normalize.css instead of the bulldozer reset.css (and base) approach. This ends up being smaller, faster, and easier to develop with.
• IE6 users will now be prompted to install Chrome Frame by default. It's time. :)
• The build script continues to get massively improved: any css @imports get inlined into your file before it gets concatenated with other files and minified together, the application cache's manifest is generated automatically for you if you want to take your app offline, also this whole build process is way faster now.
• Build script also has optional tasks for CSSLint, JSHint, splitting your CSS into modules, and more customizability.
• Added respond.js to allow true responsive development; use media queries with full cross-browser support now!
• PNGFix, Handheld.css removed along with lots of other smart removals. The full h5bp payload is now smaller and faster than ever.

View the much larger/detailed++ announcement at h5bp.com/#v2.

We've also added Mathias Bynens and Nicolas Gallagher, two very talented frontend researchers and developers, to the core development team.

Thanks to all the many many awesome code contributions, discussions, and most importantly research and documentation that lead to world-class front-end development!

Thanks: alrra, Adeel Ejaz, David Murdoch, Jonathan Fielding, Robert Ros, Mathias Bynens, Nicolas Gallagher, Mickael Daniel, Jonathan Verrecchia, Calvin Rein, Rob Larsen, William Meleyal, Bruno De Barros, Mike Almond, Frank, Joey Baker, Ben Word, Mike Botsko, Carlos Rosquillas, Todd H. Gardner, rdeknijf, John Attebury, Ryan Seddon, Dayle Rees, Ryan Smith-Roberts, Brian Blakely, Steve Heffernan, Barney Carroll, Osman Gormus, Jason Tokoph, See Guo Lin, Jeremey Hustman, James Williams, John-Scott Atlakson, stereobooster, walker, François Robichet, leobetosouza, Matthew Donoughe, Patrick Hall, Andy Dawson, Daniel Filho, Clément, Joe Morgan, Han Lin Yap, Gregg Gajic, Michael Cetrulo, Robert Doucette, lexadecimal.com, Adam Diehm.. and more people I'm sure… like Gavrisimo ♥ and Guillaume Moulin (Ping me and I'll add you! (sorry!)

Join the fun

So feel free to dig into the 2.0 code and join the fun development community at our github issue tracker where we welcome all frontend hackers and researchers. Hop on the follow train of @h5bp for project news as well. Thanks everyone

Heard of Sjoerd Visscher? I would venture to guess you have not; however, what he considered a minor discovery of his is at the foundation of our ability to use HTML5 today.

Back in 2002, In The Hague, Netherlands, Mr. Visscher was attempting to improve the performance of his XSL output. He switched from createElement calls to setting the innerHTML property, and then realized all the unknown non-HTML elements were no longer styleable by CSS.

Fast forward to 2008, HTML5 is gaining momentum. New elements have been specified, however in practice, Internet Explorer 6-8 pose a problem as they do not recognize unknown elements; the new elements cannot hold children and are unaffected by CSS. This sad fact was posing quite a big hinderance to HTML5 adoption.

And it's now, half a decade after his discovery that Sjoerd innocently mentions this trick in a comment on the blog of the W3C HTML WG co-chair, Sam Ruby:

Btw, if you want CSS rules to apply to unknown elements in IE, you just have to do document.createElement(elementName). This somehow lets the CSS engine know that elements with that name exist

Ian Hickson, lead editor of the HTML5 spec, stood surprised, along the rest of the web, that he had never heard this trick before and was happy to report: "This piece of information makes building an HTML5 compatibility shim for IE7 far easier than had previously been assumed."

John Resig, one day later, wrote the post that coined the term "HTML5 Shiv". While it technically is a "shim" and John admitted this later, the proliferation of assorted HTML5 shims nowadays makes a good case for us to continue using "shiv" for this solution. Chris Wilson, then of the IE Team, said “I want to jam standards support into (this and future versions of) Internet Explorer. If a shiv is the only pragmatic tool I can use to do so, shouldn’t I be using it?”

Now, from here, a quick timeline:

• January 2009: Remy Sharp creates the first distributable script for enabling HTML5 element use in IE.
• June 2009: Faruk Ateş includes the html5shiv in Modernizr's initial release.
• February 2010: A ragtag team of superstar JavaScript developers including Remy, Kangax, John-David Dalton, and PorneL collaborate and drop the filesize of the script.
• March 2010: Mathias Bynens and others notice the shiv doesn't affect pages printed from IE. It was a sad day.
• April 2010: Jonathan Neal answers the challenge with the IE Print Protector (IEPP), which captured the scope of the html5shiv but also added in support for printing the elements as well, through clever use of the onbeforeprint & onafterprint events, along with a faux DOM reconstruction.
• April 2010: Remy replaces the legacy html5shiv solution with the new IEPP.
• August 2010: JD Bartlett introduced the innerShiv, which is necessary for shiv'ing content going in via innerHTML.
• February 2011: Alexander Farkas carries the torch, moving the IEPP project to github, adding a test suite, fixing bugs, and improving performance.
• April 2011: IEPP v2 comes out. Modernizr and the html5shiv inherit the latest code. Meanwhile developers everywhere continue to use HTML5 elements in a cross-browser fashion without worry.

This is what the HTML5 community is all about to me: distributed folks, working collaboratively, to bring the promise and potential of HTML5 into reality.

Just for emphasis on all the bright minds that engaged on this one.. Here are the people who worked on the HTML5 Shiv: Sjoerd Visscher, Sam Ruby, John Resig, Remy Sharp, JD Bartlett, Faruk Ateş, Kangax, John-David Dalton, PorneL, Mathias Bynens, me and last but certainly not least, Jonathan Neal and Alexander Farkas.

It's a very good book on practical HTML5 and CSS3 development with a lovely learning curve. Buy it if you like. ;)

Heyo, I'm Paul Irish.

I'm a front-end developer,
a Google Chrome dev relations guy,
a jQuery Team member,
a lead developer of Modernizr, CSS3 Please and HTML5 Boilerplate,
a creator of mothereffingtextshadow, mothereffinghsl, W3Fools, Chromium Web Platform Status, HTML5 Readiness, JSON-P DB, --> Front-end Coding Standards, Type Rendering Project, Infinite-scroll.com, jQuery plugin stuff.
a host on the yayQuery Podcast,
and an mp3 blogger at Aurgasm.

Pretty new to San Francisco.

Contact me or read more about me

Add +Paul Irish to your Google+ circles

These posts are the bees' knees

• Browser CSS Hacks
• 10 Things I Learned from the jQuery Source
• @font-face gotchas
• Duck Punching with jQuery
• DOM-based Javascript Execution pattern

Random Posts

• The Refresh CSS Bookmarklet -or- How to iterate quickly when debugging CSS
• Infinite Scroll: 1.2 Release and Grid-a-licious support
• Web Typography Presentations
• You must restart your system
• The two CSS Selector bugs in IE6