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. ;)

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. :)