Paul Irish

… 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.

Paul Irish front-end development

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

Paul Irish front-end development

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.

---

The narrative above appears in my foreword for the book HTML5 & CSS3 for The Real World by Estelle Weyl, Louis Lazaris, and Alexis Goldstein.

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

Paul Irish front-end development

Pavel Feldman (Dev Tools engineering lead) and I just spoke at Google I/O about the Chrome Developer tools.

We covered a whole lot of enhancements to style manipulation, timeline inspection, script debugging, DOM and Event listener breakpoints.

If you haven't looked much at the dev tools in 12 months, you need to give this another look. But if you're also using it daily, I can guarantee we show some features in here you have overlooked. ~36min.

We announced a few brand new features I'm really jazzed about:

• Remote Debugging
• minified script pretty printing (look for the {} icon on the bottom bar)
• revision history with save to disk functionality
• freeform style and script editing
• Dev Tools Extension APIs

Lots of these require the Chrome Canary or Dev Channel build, so hop on those, or wait 6 weeks. :)

Also…

My colleague Boris Smus has also crafted a nice cheat sheet for the Dev Tools:

The cheatsheet is available for download in PDF and PNG. (You can also fork it)

If you guys have any questions about the dev tools, I can try to answer them below. :)

Paul Irish chrome, front-end development

I've been using a technique for a while now to reduce twitter noise, and I suppose it deserves documenting. I like to keep my tweet volume low (specifically your regular broadcast tweets, rather than replies.

When attending a conference…

I'll oftentimes write a tweet as a reply to the conference's twitter account. For example, I'm off to JSConf right now. So I might do

@JSConf just landed. here in PDX. anyone wanna share a cab? also beerz. nao.

Similarly when using twitter as the backchannel, I don't search just the #jsconf hashtag, but purely 'jsconf' so I get both the hashtags and the replies.

When targetting a smaller portion of your followers…

Sometimes I wanna tweet some info that's interesting to only some folks, like strictly people interested in javascript language details or straight up designers. I'll pick a pretty popular person in that area and shoot it of almost like a reply to them:

@kangax et al, Annotated ECMAScript 5.1 now @ http://es5.github.com incl. links to MDC and @DmitrySoshnikov's research

Wha?

This all makes sense because of how twitter handles replies. If I reply to @homeboy1 and you don't follow him, you don't see that one in your timeline. If you do, you do.

So there it is.. mostly I see it as a polite thing to do when at a conference and the rest of your followers want to put you on mute for 3 days. :)

Paul Irish hacks