My slides:

Because there are so many tools around, I wanted to break them down somehow. I think contextualizing the tools as to what phase of development that assist with works well:

(You could think of the Y-axis here as the amount of code in a project..)

Looking at our tools this way we end up with:

• Boilerplate
  • You likely start a project with more than a single blank text file.
• Authoring Abstractions
  • CSS preprocessors, Languages that transpile to JS, Templating
• Frameworks and Application Stack
  • Clientside MVC, UI Components, Widgets
• Iteration Workflow
  • Browser Devtools, Browser/Unit/Integration Testing
• Performance Tuning
  • Profiling, Memory mgmt, browser instrumentation
• Build & Optimization
  • Minifiers, Concat, Image compression…
• Deploy
  • Continuous Integration, Continuous deployment

I've been thinking a lot about workflow and integrating these tools together. Screencasts like Andrey Tarantsov's Sublime Text Workflow really excite me and I'm eager to see more people exploring a robust development setup.

The premise of prefixes makes unrealistic demands on how developers maintain sites

There's a lot of conversation about making prefixes work (by changing policy), but I believe they already are at odds with the developer workflow. In this proposal I hope to show that:

1. prefixes are not developer-friendly
2. recent features would have been in a much better state without prefixes
3. implementor maneuverability is not hampered without prefixes

The developer experience

If I'm using a feature that's prefixed, I have a choice of using a tool to help me manage outputting the various prefixes I need or I'll do it myself.  Based on my informal poll last week it looks like 40% of developers are not using tools. Without tool usage, authors are not including -ms-, -o- or the unprefixed variants. Page 4 of Mozilla's prefix report verifies this; developers don't write necessary prefixed properties about half the time (e.g. -o-transform) and in fact, they already write out the unprefixed variant well before the spec goes to CR (and do this well before adding in -ms- or -o- compatibility).

This matches my experience as well. I don't want to return to this code to maintain it, so I'm going to add the unprefixed version. There is less of a cost to me leaving the unprefixed version and assuming I won't need to change it vs. returning to my CSS of shipped-to-production work to add unprefixed variants each time a feature hits CR.

Any successful evangelization plan for prefixes relies on tools, but all tools prioritize the unprefixed state. prefix-free, compass, and css3 please (I'm a tool vendor, too) all heavily suggest starting with the unprefixed state. So any successful evangelization push will just result in the unprefixed version being 100% deployed from the get-go, which ties implementors hands anyway and defeats the purpose of the prefix. I don't have data to show that developers are not returning to their deployed, production code to update prefixes, but anecdotal evidence suggest so. Opera’s Web Opener team, for example, reports a <10% success rate when directly contacting sites to request updates to their prefixes.

PPK wrote “If standards make web developers’ lives much harder, web developers ignore standards. This was true back in 1998, it’s still true today.” Without prefixes, implementors have an opportunity to empower developers to do the right thing while still allowing room for innovation.

Existing W3C prefix policy provides false expectations

PPK covered this ground well last week, but in short the policy of binding prefix-drop to CR has failed plenty. Developers have no expectation of when this will happen, nor should they. Mozilla’s roc has confirmed developers are using prefixes and they won't stop regardless of their supposed "experimental" status.

Let’s imagine there were no prefixes

So without prefixes, vendors hands would be tied and the first implementation to ship would be the one to stick, right? Nah. I think we can walk through a few examples from recent history too see what it would have been like if there had been no vendor prefixes in play.

transitions, transforms, animations

While plenty of implementation bugs were fixed, the developer would never have updated their syntax and would have complete browser support.

box-sizing

No problems. No changes.

css-gradients

Gradients has been the most tumultuous css spec, but if they had been implemented without prefixes, the feature would be in a better situation today.

Browsers discard properties and values they don’t parse successfully, so developers would have just included a cascade of the iterations of the spec. This would have successfully targeted all shipped versions of gradients:

.blacktowhite {
  background-image: gradient(linear, left top, left bottom, from(black), to(white)); /* initial webkit proposal */
  background-image: linear-gradient(top, black, white); /* mozilla proposal */
  background-image: linear-gradient(to bottom, black, white); /* likely the CR */
}

flexbox

Mozilla started Flexbox v1, WebKit followed with a slightly stronger implementation. Both Alex Russell (post) and I (article) recommended boilerplate code that assumed no change for unprefixed state and blocked out IE10’s upcoming implementation.  

Flexbox v2 debuted and has an implementation in Chrome. Syntax is already different enough that the fallback story is happy. Without prefixing, the resulting browser support of shipped author code would be better. Again, I see no drawbacks in this example had these properties not been prefixed.

requestAnimationFrame

Soon after this feature debuted, shims were written to manage all prefixed implementations including the unprefixed state.  (Sorry). Combined with quick adoption, browser  have as much ability to change the feature as they would if it were unprefixed to start (that is, not much ability).

Risks and Resolutions

In CSS, new breaking changes have to introduce syntax changes that would break previous parsing attempts, as seen in the gradients example. However, if the semantics of a feature changed without syntax changes, we’d have a situation where developers are forced to detect each behavior and write compatibility code.

border-image introduced a similar situation recently: WebKit changed its semantics and required a `fill` keyword to match previous behavior. Sounds like trouble, but this change happened when the unprefixed variant was exposed, matching implementor best practices of changing a feature. The result: Greg Rewis of Adobe blogging that Chrome broke his site.

This is truly how it is supposed to work, but still expectations are broken. Developers have plenty of motivation to leave in the unprefixed state at the beginning, but this means that any change will always break them. With prefixes or without prefixes, we would have gotten the same resolution here.

In JavaScript/DOM we have a more secure safety net, as behavior can be detected. Take for example querySelectorAll(); it was shipped without prefix and while implementation differences exist, JavaScript libraries detect and route around them. Of course, semantics can change and the prefix → unprefix move provides an opportunity, but in my experience it’s more common to see these changes happen early on (like blob.slice()’s change).

Without prefixes there will be no mechanism to notify developers “beware, thar be dragons!”. Prefixes don’t do this now, as their removal isn’t prioritized so developers accept them as a fact of life rather than an indication of instability.  The solution: getting accurate metrics of feature usage and adoption can inform implementors of if it’s too late to change a feature or still early enough to modify.  

Yes, but…

As vendor prefixing is a well-worn debate, allows me to deflect common challenges to this proposal to:

1. Vendor Prefixes Are Hurting the Web by Henri Sivonen (see “Pre-Emptive Rebuttal to the Most Common Counter-Arguments” and on)
2. Alternatives To Supporting -webkit Prefixes In Other Engines by Robert O’Callahan
3. CSS vendor prefixes considered harmful by PPK (from 2010)

Logical Actions

1. The community to evangelize use of tools like Compass that protect authors from bad authoring practices and so folks who publish tutorials don't solely define their -webkit- styles.
2. Browsers to track feature adoption to inform better decision-making around changes. (Answering the question: Are we stuck?)
   • This data should be public and update regularly.
   • Should be based on pageviews, to accurately weigh when a CNN.com implements something
3. Other browsers to implement a defined set of -webkit- prefixes on their mobile browsers. I don’t see a way around this nor do I think it’s bad.
4. Drop the notion that evangelism gets us out of this mess. I've been doing this evangelism myself for the past 3 years, but I'm also a realist. This situation needs new policy and (clearly) needs speed out of the CSS WG.
5. Browsers to clarify a feature detection strategy that it supports. For example, developers have no reliable way of detecting Chrome’s 3D transforms support ^{[1, 2]} or discounting Chrome’s -webkit-hyphens false positive[3]. All proposals for handling experimental properties need accurate feature detection techniques to be effective.

In summary, the ideal developer experience is 1) using tools to manage prefixes and 2) always using the unprefixed state to reduce maintenance cost. These two facts eviscerate the benefits that prefixes were introduced for, leaving only the drawbacks.

Ugh. If I say the width is 200px, gosh darn it, it's gonna be a 200px wide box even if I have 20px of padding. So as you know, this is NOT how the box model has worked for the past ten years. Wikipedia has a great history of this box model. Jeff Kaufman also dove into the history

Anyway, I have a recommendation for your CSS going forward:

/* apply a natural box layout model to all elements */
* { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box; }

This gives you the box model you want. Applies it to all elements. Turns out many browsers already use border-box for a lot of form elements (which is why inputs and textareas look diff at width:100%;) But applying this to all elements is safe and wise.

Browser support

Due to browser support, this recommendation is only for projects that support IE8 and up. (Full browser compat at MDN) Firefox still needs the -moz- prefix, and <= iOS4, Android <= 2.3 need the -webkit-, but everyone else uses the unprefixed. You can find more info about a box-sizing polyfill for IE6 & 7 at html5please.us/#box-sizing (which was developed with * { box-sizing: border-box!).

Is it safe to use?

Totally. jQuery works pretty great with it (except this). As mentioned, browser support is excellent. And a number of projects use this layout model by default, including the WebKit Web Inspector (aka Chrome DevTools). I heard from Dutch front-end developer Yathura Thorn on his experience:

We've been using *{box-sizing: border-box;} in one of my projects (deployed in production, averaging over 1mln visits a month) at work for about a year now, and it seems to be holding up just fine. The project has been tested in IE8 & 9 and the latests Firefox and Chrome versions and we've had no problems. All jQuery (+UI) offset calculations and animations run fine, even in any element we've displayed as inline-block. As of late we've started testing the project on mobile devices (iPhone, iPad and Android) and we've had no issues regarding box-sizing with any of them yet, so it seems to work just fine.

One of my favorite use-cases that border-box solves well is columns. I might want to divide up my grid with 50% or 20% columns, but want to add padding via px or em. Without CSS's upcoming calc() this is impossible... unless you use border-box. So easy. :) Another good one is applying 100% width and then wanting to add a padding to that element.

Performance

Lastly on @miketaylr's inquiry, I also tested perf overhead. Anecdotal evidence suggests border-box isn't significant.

You might get up in arms about the universal * selector. Apparently you've heard its slow. Firstly, it's not. It is as fast as h1 as a selector. It can be slow when you specifically use it like .foo > *, so don't do that. Aside from that, you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If you aren't getting 90+ Page Speed scores, it's way too early to be thinking about selector optimization. See also: CSS Selector Performance has changed! (For the better) by Nicole Sullivan.

So... enjoy and hope you'll find this a far more natural layout model.

This Wednesday, me and a ragtag team of like-minded developers launched Move the Web Forward, an initiative to direct people's passions into productive efforts that assist not only the web community but the entire web platform. People often feel the need to "give back", but when it comes to contributing it's a challenge to find the right place. This is something I've seen happen firsthand in the jQuery and HTML5 Boilerplate communities.

The MWF effort was inspired by a tweet by WebKit extraordinaire Dimitri Glazkov. Me and Divya started brainstorming on an etherpad. We rounded up some folks on Google+ and IRC and started collecting a lot of excellent resources. Soon after a design was in the making and we started working in an open repo on github…

At this point, I want to call out Mat Marquis aka @wilto, in particular, for really taking early ownership of this project and spearheading the design and frontend development. His efforts really made the site communicate its content effectively.

Naturally the site is on github if you'd like to contribute. We have a few issues open that we'll be improving the site with. (Also, let me just say for projects like this, a cron job to pull latest from Github makes for such a relaxing workflow.)

Thanks to Divya, Mat, Aaron Forsander, Connor Montgomery, Stephanie Rewis (great writeup!), Nicolas Gallagher, Addy, and all these awesome folk. Truly a socially developed site; everyone collaborating on IRC, etherpad and github (with as many having commit rights as possible). Fun project to work on and I hope to see everyone find the right place for them to get more involved in actively making the web as awesome as you want it to be.

Beyond all the people who signed up (with the avatars) on the site to commit to things.. We've seen some moves in the community already:

• Ben Schwarz is joining the CSSWG to redesign how specs look and act

• Connor Montgomery, wrote up a patch regarding fullscreen support in Firefox
• Josh Adam is inspired to become better
• Alex Ball is going to contribute to BuddyPress
• Lots of folks in the accompanying Smashing Magazine article are ready to dig in.
• Colin Gourlay will be documenting what he learns more

\o\ \o/ /o/

Frontend development exploration, techniques, tips. Lots of JavaScript. 258 feeds.

Standards development and browser dev news. 49 feeds.

It's easy to click through and subscribe in Google Reader. There is also OPML files if you want to take 'em elsewhere.

Also, a short commentary on blogging vs tweeting.. while a lot of people have changed to twitter+jsfiddle only, tweets are not available via search after 30 days, so if you expect anything you share to last, blog it for real. :)

Also please subscribe to these guys which do a great job of highlighting the top stories of the week:

• JavaScript Weekly
• Web Design Weekly
• HTML5 Weekly

The Primitives of the HTML5 Foundation – Slides

I do discuss optional start and end tags as well as not quoting your attributes. I concede that these ideas scare the shit out of people. In fact, when I first heard Jens Meiert propose the idea in 2009 my brain rejected it.

Still, I think many of the markup parsing curiosities that can be frightening only need to be understood by HTML minifiers. Always leave it up to tools to make your frontend payload smaller; you just want the most comfortable and maintainable authoring environment possible.

I shared them in this talk because 1) it can lead to writing more beautiful HTML that is easier to maintain. Leaving off </li>'s is a good example. 2) I just want people to consider browsers less of a black box of uncertainty. There are rules and specs that define behavior, so once understood you can feel confident relying on a consistent behavior. We certainly don't have that consistency across all the web platform, but for these examples you do.

In summary, I'm not advocating you write more spartan markup if you don't want to. But if it makes you feel good, by all means, go at it; you know now how the browsers work.

ps. the monkey HTML shirt I wore is from a store in tokyo; solo location. but they also sell on this delightfully overwhelming site

Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors.

Jeremy’s gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1’s depending on section nesting. Recent browsers do indeed style the h1’s different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1’s all as top level headlines or a mishmash of heading nesting levels that don’t match any expected behavior (As an aside, this is completely unrelated but if anyone’s curious what CSS it takes to make that new h1 styling work across browsers… feast your eyes on this beauty)

Additionally, <hgroup> is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke’s comment digs in deeper to the messy semantic state of the outlining algorithm.

The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn’t complete unless you’re listening to the results in a screenreader.)

My recommendation: follow the work of Steve Faulkner and Jason Kiss. These two guys are publishing the only data that illuminates what’s actually happening at the AT level in response to our work. Steve’s comment on this post does a solid job of unraveling this complex topic by showing all the many layers involved: specs, editors, authoring experience, aria, browser impl, screenreader compliance.

Also if you’d like to investigate what’s happening under the covers, I recommend:

• HTML to Platform Accessibility APIs Implementation Guide – Understand how HTML elements and attributes map to accessibility APIs
• HTML5, ARIA Roles, and Screen Readers in March 2011 – Implementation of HTML5 elements in screenreaders isn’t perfect yet.
• HTML5 and the myth of WAI-ARIA redundance – Will HTML5 make the use of WAI-ARIA in HTML redundant? Definitely not.
• JAWS Support for ARIA – Originally published by Freedom Scientific as a MS Word document. *facepalm*
• html5accessibility.com – Also from Steve Faulkner; this research is hugely comprehensive and backs up the examples Divya provided
• delicious.com/paul.irish/aria – My own bookmarks on semantics, aria and accessibility.

In summary, I think it’s best to ground our efforts in pursuing semantic value by identifying precisely what the results will be. A fair rule of thumb: when it comes to semantics, if it’s confusing enough for you to ask a question about it, chances are the answer won’t make a realistic difference. Let’s build incredible stuff on this impressive platform and avoid getting mired in semantic inconsequentialities. There’s also room for more author engagement and screen-reader involvement in the standards process regarding these issues; but that’s a large topic I’ll have to save for another day.

We're very interested in seeing web browsers advance and implement the interests of web developers.

We got a great response (230+ responses). After a triage of the responses, we narrowed down things to a hitlist that jumped out as having no immediate solution and would be great for the platform:

• flash capturing keyboard events, cursor
• WYSIWYG form element
• inset text shadow
• css blend modes
  • usecase: image i want to tint on hover
• Why CORS requires a preflight with cookies disabled
• being able to verify the content sent was the content delivered. Probably via headers & apis useful when deploying for mobile/roaming use or in corporate networks when behind proxies.
• Text Flow or caret(Position/Range)FromPoint
• A unified and publicized set of selectors for styling the shadow dom of input/select/etc. elements
• a way to manipulate asset request urls with js on the client before they go out (for serving responsive imgs, etc).
  • or media query attributes on image tags
• UIKit for Javascript.
  • Native UI bindings to JS that remove overhead and layers of HTML+DOM in the way. Sony's Trilithium did this by binding HW accelerated scene graph, ala Core Animation. see also playstation webapp
• render a DOM element to canvas, webgl
• DirectWrite in all browsers on all platforms.
• simulate keyboard and CLICK events
• a base tag for CSS
• Filesystem API limitation: IDE cant save files back to disk in original location
• XHR2
• fragment.innerHTML

There are a lot more where that came from. A few people wanted to see all the responses… So.. here you are. :)

Right now they are partially categorized. I'd love your help with that..Thank you SO much to rworth and evan, who organized this list. Awesome :)

Broad and Sweeping

• a fundamental rethinking of the DOM would be a good start. ~blrandel
• Get rid of HTML. Make web JavaScript/CSS driven. ~nextinterfaces
• the standards process ~sethladd
• Browsers suck. Give us a VM that lets us not care about the browser. ~rxgx
• the “feature” that allows browsers to render bad/poorly formed HTML. I want that fixed please. ~durple
• In a perfect world I’d say ditch the DOM and give me a real displaylist-style interface, with a consistent composite architecture. ~awebneck
• consistent implementation of standards across browsers. ~BrettBearce
• performance ~mislav
• Should be ilegal to release a browser that doesn’t accomplish all the w3c standards ~FedePaterno
• web page cloud pre render. Then pipe one asset to the browser. :-) ~halfcube
• create something that makes ads suck less and do not blocking my page ~jaydson

Just Everything, all of it, and then some

• all HTML5 features supported by all browsers. ~chrisreister
• full html5/css3 support cross browser and signed off specs! #inaperfectworld ~Japhex
• Better support for html5 and css3 (all browsers and platforms) = less hacks, less vendor prefixes, less js = happier life :) ~rodrigonoales

IE & Mixed Browser Support

• Can I say “IE”? Or is that joke too overdone already? ~coreyschram
• as usual, IE is holding everything up. I’d like wide support for SVG today. ~nathan_vaughn
• other browsers to keep up the speed of Chrome’s implementation of standards and to auto-update to latest version ~illyriad
• force update IE. ~Fallion
• An alternative to animated gifs (apng)! FOR GOD’S SAKE!! ~TechBobOmb
• fast upgrade cycle for IE comparable to Chrome’s excellent model, and the dropping of compatibility modes going forwards ~ffub
• Add support for data:image/png;base64, … to IE6/7. ~ndorfin
• sorry, release schedule != update strategy; the latter is what I meant to say. Resubmitting… ~jswartwood
• IE’s update strategy. Most important feature to add to the Web is an ability to use feature X in reasonable time. ~jswartwood
• how many people answered with IE? ~omarqureshi
• Legacy Internet Explorers. Patch them all to autoupdate to IE9+ or a third party engine. ~joegaffey
• i’d fix the ‘Microsoft having a browser’ bug ~shanecarmody
• oh yeah ie7,8,9 ~negrond
• ie6 ~negrond
• Advanced CSS3 selectors in IE7 and 8. If I had to choose one it would be nth-child. ~Chris_Krammer
• if I had the chance to fix one it would be to get rid of IE. :) ~markbates
• IE ~samullen
• One browser bug? It’s the one people refer to as “Internet Explorer.” It’s a notorious bug. Evil bug. ~rerouse
• the IE self destruct button! ~jeremywoertink
• the complete removal of ie 6 and upgrade of everybody to modern browsers ~Mark_Kellett
• IE6-8 ~manufaktor
• am I allowed to classify everything < IE 10 as a bug? ~chrisdarroch
• Can the bug be ie? ~bbommarito
• legacy browsers! And all browsers which don’t auto update ~stefanpenner
• And of course a forceful auto-update of all IE installations to version 9 :) ~craigpatik
• frequent & transparent update for all browsers like Chrome, more coherence on supported features across browsers ~xeppelin
• the one browser bug would be to eliminate all versions of IE. ~stash_tray
• Internet Explorer. ‘nuff said. ~aviraldg
• Auto upgrade for every browser. ~ojohnnyo
• regular silent automatic delta updates. ~simbolo
• Bug fix: Android browser. ~kylebarrow
• automatic Chrome-like updates (along with actual updates) for IE…? #nevergonnahappen ~alexrussell101
• Does killing all IE below 8 count? ;) ~ryanolson
• I’d add a feature to Chrome that “accidentally” detects IE as a virus and deletes it from the user’s machine. ~wmbenedetto
• chrome! ~JomGapuz
• That’s easy … it’s called Internet Explorer #abug ~trymbill
• An easier way to communicate with databases? and microsoft deprecate IE6 & 7. ~Tsouloftas
• Internet Explorer retroactively updating itself ~MyHeroDevon
• automatic updates for all browsers (ie like chrome). rate of innovation would skyrocket ~smartalec43
• a browser on Android that auto-updates ~boblet
• Browser bug to fix? I’d say, make every browser with out-of-date rendering instantly bitch-slap the user until they upgrade. ~J6M8
• to that end, mobile web browsers have terrible documentation on what features they support/don’t support. ~bcardarella
• Silent auto updates for IE. If only there were a way to cut that half life… #webdeveloperheaven ~josiahsprague
• I suppose IE is the main reason For not improving my websites. ~gerherz
• Desktop, the bug I’d like fixed is “IE” ~ljharb
• Crossbrowsing for christ sick! I wish I can see one day all browsers rendering the sites in the exactly same way once for all! ~FedePaterno
• I would fix IE6 so it would automatically crash itself as soon as anyone decided to open it. ~adamholwerda
• Can Internet Explorer be considered a bug or feature I’d like to improve… aka eliminate? ~JtheBruce
• Android is woefully behind desktop Chrome. ~andybastable
• “the one browser bug” = Android. ~danmux
• Decent HW rendering in Android please ~danmux

Authentication / Identity / Crypto

• identity. I hate having to create a username and password. ~sethladd
• Integrated browser authentication. When’s the last time you logged in to a native app? ~madeofcode
• Identity, in a way that’s comprehensible and controllable by the user. ~johnjoseph
• And w3.org/2011/identity-… will be a great advance too ~cbullokles
• I wish I didn’t have to handle identity and SSL. Let my users sign in with existing credentials, and an assurance of encryption. ~abackstrom
• a full crypto & authentication stack ~jarrednicholls
• Add SSL over HTTP (instead of HTTP over SSL) to handle Certificate-based authentication in the application instead of the web server ~genezys
• secure storage for things like OAuth keys (no more proxies needed) ~manuel

Browser Testing

• A better way to test across browsers and browser versions. ~jacelevine

Development tools

• Better memory debugging tools. Like YourKit for JavaScript ~sethladd
• i’d say a built-in vim-style code editor w/ git hooks. maybe… ~csanz
• saving changes (js,html,css) made thru google chrome dev tool/firebug directly back into the codebase would be cool. ~4mo1
• an ssh client integrated into google chrome ~travisglines
• ability to debug CoffeeScript in the browser would have high impact (ideally with IDE/editor integration during debugging) ~ltackmann
• Merge firebug’s realtime CSS editor with chrome developer tools ~danielcgold
• combine the IDE and the browser. ~jwaltonmedia
• Summary of my position — improved native development experience over features that I haven’t imagined yet :) ~justinfrench
• I’ve been making use of the 3D CSS3 box model inspector in Dev Tools for a heavy interactive site. Godsend. Thank you dude ~joecritchley
• a better developer tools for IE, remote debugging for iPad ~mohsen__
• something that will fill in a form while I’m testing client side validation, checkout, etc. ~jwaltonmedia
• UIKit for JavaScript. ~sandofsky
• And a built-in bandwidth throttler / slow-mo mode. ~kpk

Languages

• I want a new client language. I’d love to see browsers switch to bytecode that we can compile other languages down to. ~michael_tomer
• Browsers that can be scripted in languages other than Javascript. (I know, Native Client is attempting this). ~suranyami
• The “Browser VM” should allow us to have multiple language implementations. An expressive bytecode, not minimized JavaScript. ~twcrone
• a VM one layer below JS (ex, LLVM).. to allow us to start innovating languages that run in the browser. JS is not the end all. ~igrigorik
• JavaScript always, everywhere. Whatever extra security browsers need to release, so devs can rely on JS always being there. ~webandy
• the lack of multiple mature programming language inside the browser environment. ~trek
• Ruby as a scripting language ~elado
• Sass and Coffeescript built into a browser ~anthonyshort

Language Features

• a way to know if a JavaScript function is actually meant to return something even if this return value is ‘undefined’. ~_sebastienp
• would love if all browsers supported noSuchMethod for some elegant script solutions. ~KaptajnKold
• If we could actually use some of the new Javascript features… ~nicobrevin
• Garbage collection. ~jayarjo
• operator overloading in #js would ease peoples’ lives when working on gfx stuff ~philogb
• Actually fixing altering any built in object’s .prototype in general doesn’t do horrible things, notably DOM objects. ~Rory_O
• Fixing Object.prototype erik.eae.net/archives/2005/… ~Rory_O
• Support for Javascript versions > 1.5 in Chrome and Safari. Specifically: I want to use generators and iterators. ~jonemo
• decoupling JS parsing from load ~derSchepp

Media

• Have the ability to pause/mute all media in all other tabs. ex: Mute google music/pandora tab when I hit play on a youtube vid. ~JoeSloth
• a solid audio api especially on mobile browsers would be great. Esp. for gaming :) ~wemakedotcoms
• Easily HTML5 Video and Audio at the moment. ~webfella
• audio and video input and encoding. ~dshaw
• more audio/video codecs built in ~masterkain
• i’ll go with html5 audio and video also… ~rguarilha
• also being able to know how many simultaneous HTML5 Audio objects you support in the current platform would be great. ~Fokker680
• If talking about Chrome, video masking with overflow hidden. ~gerherz
• the state of video delivery in and across the browsers is still quite sad. but not an individual browser issue per se. ~jerememonteau
• Good audio support for mobile browsers. ~andybastable

HTML5 Forms

• universal support for styleable input types (date/time/range/etc) ~franksvalli
• A rock solid native WYSIWYG form element. With so much content dev being done online, this is an area that seems really behind. ~reinink
• file uploads need rethinking. ~sikander

DOM

• a “Create” event launched when a new dom node is inserted ~JohnHackworth
• Quietly fail and move on when calling a method on a non-existent object : doc.getElementById(“does-not-exist”).innerHTML = … ~craigpatik

Keyboard

• Consistent handling of keypress/keydown events across browsers and OSes would be killer. ~pyrolupus

Mouse / Touch

• gesture events like swipes and flicks built-in as DOM events ~manuel
• doing touch without listening to three events for each gesture ~mohsen__
• now that comes from a cat avatar: an element that catches the mouse would be awesome for games or panorama viewer ~Flexi23

Device input

• Media Capture API! 21st century, and we are still limited to the text-only input on the web! ~matas_petrikas
• Access to the FS, to the devices (camera, sensors, readers, scaners…), direct access to the GPU (3D and complex calculations) ~gandazgul
• Device APIs. Accelerometer, camera, contacts, etc. ~filmaj
• Access to device capabilities from a website. gps, gyro,etc. ~ivanmarcin
• it will never happen, but support for more native functionality like file system, camera, etc… on mobile ~bcardarella
• Safe, sandboxed way to communicate with user’s hardware (GPU, filesystem, camera, etc.)—but that’s already on the way. ~valueof
• <input type="voice"> and <input type="webcam"> ~TimoKissing
• oh, also, device access! shouldn’t need flash to get to the camera and mic. ~jerememonteau
• device api, the use cases increases significantly on mobile . ~vivianli
• w3.org/2009/dap/ ~jamespearce
• Device APIs. ~jamespearce
• Mobile, file inputs = camera access ~ljharb

Flash

• Inconsistent keyboard trap issues, often by Flash content. Causes accessibility issues and annoys me no end – when in a YouTube video in Firefox, ctrl+t\ctrl+w no longer work for closing\creating tabs, and focus gets stuck in player ~joechidzik

CSS

• Ah, forgot something veeeery important: @viewport! ~derSchepp
• if CSS could do math. Ex) height: 100% – 20px; ~justindross
• I’d like css files to have a ‘root’ variable where you could set the home directory. ~davidrhoden
• Implementation of CSS Paged Media. To me this seems to be the missing link of modern technology. ~Rene_Kriest
• a way to disable, or set the device orientation. PLEASE. We need that. ~Fokker680
• background image rendering in firefox. I dislike how it needs either a or text to start rendering the image. ~joshsager
• CSS Filters ~derSchepp
• an adaptive image file format. ~derSchepp
• media queries attrs on base/img tags. Will enable downloading smaller images for smaller screens. ~yoavweiss
• a way to manipulate asset request urls with js on the client before they go out (for serving responsive imgs, etc). …which already worked until a couple months ago when browser img prefetching became more aggressive. ~scottjehl
• The one annoying me at the moment is the landscape rotation bug in Mobile Safari: tinyurl.com/5sr7qkm ~Pipsqueaks

Styling

• CSS blendmodes. div{blendmode:’overlay’} but also div{background:’multiply’ rgba(0,0,0,.3)} + for div{color:’add’ #fff} ~mknol
• css blend modes ~waynethebrain
• blending modes. Like multiply/overlay/etc in PS. ~gb
• Full support for @ page w3.org/TR/CSS2/page.h… ~sanbeiji
• I’d fix pixel overflow & underflow in IE Chrome & Safari. ~jon_neal
• this would for me be to not use curvycorners js hacks to get rounded borders to work in IE ~Iclevettdesigns
• multiple background images. ~Iclevettdesigns
• A unified and publicized set of selectors for styling the shadow dom of input/select/etc. elements ~JasonWyatt
• I’d like CSS to have an inherit:none feature, especially helpful when you’re inheriting from styles you have no control over. ~JayDWhiting

Text

• text-stretch. :) ~jonas_lund
• Proper text anti-aliasing on Chrome. Large type looks awful. Note: IE and FF have this already. ~andybastable
• Text Flow or caret(Position/Range)FromPoint. I’ve spent weeks on columns, text flow, and non-contenteditable wysiwyg, etc. ~grayrest
• Give me inset text-shadows in all browsers and proper edge antialiasing in Chrome and I’m all yours. ~matthewmorek
• There is some small bug with text sometimes (become lighter a bit, when canvas is loaded to that page). ~slobodan_
• Kerning and consistent type anti-aliasing across all platforms :) ~endtwist
• DirectWrite in all browsers on all platforms. ~H_FJ

Layout

• absolute centering of images etc in a given div would be one ~yemster
• I want rock solid layout. Like flexbox/ms-grid including vertical alignment. Basically, table-layout without the tables. ~b4nn0n
• Strong finalized layout system. Strong forms support for real apps. HTML CSS JS unreachable for the user. No way to modify pages ~fpiat
• better CSS layouts. I know it’s coming, not fast enough ~sethladd
• A real layout system :) ~natecavanaugh
• it shouldn’t be so difficult to build columns and vertically center things. Seriously why are these still problematic. ~nathan_vaughn
• layout. hands down. ~boblet
• Add sane CSS-based layouts to all browsers. ~jon_neal
• flexbox everywhere ~mislav
• Have css3 column-count and width work in all browsers, but revert to a stack in resolutions below multi-column width. ~J_Grimm_
• position:fixed and overflow:scroll on all desktop and mobile browsers would make my day ~prundin
• Vertical and “middle” float. I want to be able to put elements in the middle of other elements, horizontally and vertically. ~iliadraznin
• My #1 is a simply a better layout system. Flexbox = meh. ~roblifford
• a box model that programatically closer to an AS3 sprite ~darrownet
• display:table in IE6 ~SubtleGradient
• Mobile, position: fixed. ~ljharb

WYSIWYG / Native rich-text editor

• All contenteditable related madness: commands, generated HTML, and selection API ~jpscaletti
• more consistent and improved implementation of contenteditable. That would really improve and slim down web based editors. ~DannySorensen

Animation

• Broader hardware-acceleration coverage for the display layer. The richness of native mobile/flash is driven by unflinching 60fps. ~teej_m
• I want to stop repainting from flickering and screwing with my animations. ~tdreyno
• Bugfix: Hardware-accelerated DOM manipulation using translate3d on Android Browser. ~bniswe
• (smooth) #CSS3 animations for ALL browsers! ~AndrewHenderson
• transition/animate pseudo-elements! ~jacobdubail
• On Android. Hardware Accelerated CSS Transforms. ~edwk
• CSS transitions (they’re just slow and outclassed by javascript in terms of speed) ~thijsjacobs
• Decent HW rendering in Android please ~danmux

2d graphics / Canvas / SVG

• Acceleration/performance on SVG. Also think I found a leak with SVG in Chrome when tabs are hidden (but no repro yet). ~notmatt
• Faster drawing with 2d canvas context. ~monteslu
• There is some small bug with text sometimes (become lighter a bit, when canvas is loaded to that page). ~slobodan_
• Good Canvas support for mobile browsers. ~andybastable
• canvas.drawWindow. Don’t even see why it should be restricted to extensions (except in the case of cross domain content) ~bgrins
• Sony’s Trilithium did this by binding HW accelerated scene graph, ala Core Animation. satine.org/archives/2011/… ~charlietuna

3d graphics / WebGL

• compressed textures for webgl, and everything else people already said. ~sethladd
• WebGL support in IE would change a lot when it comes to browser games. For 3D as well as 2D. ~ippalix
• Good WebGL support for mobile browsers. ~andybastable

Web Storage

• Making localStorage infinite size ~nikolatankovic
• Web storage and offline use is a huge mess, even on latest gecko/webkit ~alexbosworth

History

• full acceptance of the History API & Ajax. It’s all about user experience. ~Scottblew
• Make browsers understand previous states so that Ajax and back-btn & bookmaring can be implemented easier/seamlessly. ~vmasto

File API

• Not easy but (until we’re all cloud based), a rich and safe way to write webapps to handle local files too crbug.com/47416 That would let us write webapps to replace all sorts of things that currently have to be desktop apps ~schmerg
• all browsers need stable and consistent support of the JS File API ~MeltingIce
• integration with the desktop and OS (file API is one of the first things) ~dnagir

File Uploads

• resumable, managed, async browser based file uploads ~tilsammans

Offline / App Cache

• a better app cache API (with improved debugging) stevesouders.com/blog/2011/10/0… ~alex_gibson
• Web storage and offline use is a huge mess, even on latest gecko/webkit ~alexbosworth
• app cache that doesn’t suck. ~miketaylr
• Fix network-connection JS events:we have online/offline for hardware but what about netonline/netoffline for Inet traffic tests? ~adamrmcd
• I’m going to +1 application cache. @SlexAxton @miketaylr & @julio_ody ~benschwarz
• that the offline HTML5 API would give a lot more control over the cache. Not sure that’s what you asked though ~julio_ody
• Firefoxes app cache permission requester ~derSchepp

Communication and Web Sockets

• I’d vote for some way to do P2P connections, or at least some way of opening arbitrary ports in some secure, sandboxed way. ~rakesh314
• Websockets… ~okinsey
• Secure websockets on all browsers will make creating web apps easier. That is a dream right now. ~chrisreister
• Uniform websocket support across all browsers. ~clofresh
• Cross domain xhr (as a new session, without the cookies of the original site) ~elado
• cross domain xhr, but creating a new session and not sending the original cookies. could save jsonp/proxies. ~elado
• universal support of push notifications without the browser being open. ~ChrisLove
• not The Single Bug, but here’s one: being able to verify the content sent was the content delivered. Probably via headers & apis. Useful when deploying for mobile/roaming use or in corporate networks when behind proxies. ~rem
• better support for XHR-2 on mobile. iOS partially supports but barely. in the case of the XHR-2 stuff it replaces the API, with a much less functional API on iOS :( PhoneGap is making the effort, but it needs to act as a polyfill and not a replacement API ~bcardarella
• cross domain xhr, but creating a new session and not sending the original cookies. could save jsonp/proxies. ~elado
• if could ask for my last gift to the three wise men I’d like peer to peer communication, with WebRTC is close to be here ~cbullokles

Desktop / OS Integration

• more OS integrations (like file upload from iOS, access to camera, cross-platform dragdrop files) ~mislav
• fullscreen maybe ~slobodan_
• integration with the desktop and OS (file API is one of the first things) ~dnagir
• On the desktop: Intents (cross app integration). ~edwk

Widgets

• Begin supporting the W3C Widget spec. ~mwbrooks
• I really like the support to w3c widgets included in opera. It helps to package web applications as normal apps ~cbullokles
• Greater steps towards W3C Widgets ~mwbrooks
• better encapsulation similar to Mozillas XUL widgets seems like a big one. ~blrandel

Browser Extensions

• also actual cross-browser extensions APIs and packaging while you’re handing out unicorn lollipops. ~miketaylr

Browser UI (App-land)

• Modifying native context menu. ~JanKuca
• Access to system-level elements. Buttons, contextual menu, etc. Why can my web app look more like a desktop app? ~sternmeyer
• Firefox’s rogue input styling that differs from all other browsers. Inability to style input elements in general in Firefox. ~taitems

Browser UI (User-land)

• I usually close browser tabs with shortcuts, the “x”, is actually a hazard for me. Thankfullly there’s command-shift-T to reopen. ~ckundo
• Showing which of the 30 tabs I have open just started playing that song everyone hates, with some kind of icon/colour change? ~josscrowcroft
• an option to freeze all non-active tabs and browser instances to gain performance and a disruption free browsing experience ~tuskali

Browser features (out of scope)

• a bit late but still, id include in every browser a feature like “safari reader” (not as extension) and make width resizeable ~askoth
• not having web inspector’s CSS panel jump to the top of the declaration every time I double-click a rule to make a live change. ~mklickman
• file:/// in Chrome. But it would never get accepted :p ~me1000
• better bookmarking. Implement thematic and context sensitive trails the way Vannevar Bush envisioned. ~mik3cap
• And a built-in bandwidth throttler / slow-mo mode. ~kpk

Ummmm

• is this a trick question? ~webandy
• a troll fix ~mynameiscolin
• sprinkles! ~jeanniev
• counterweights to balance out the missing goats ~anthonydispezio
• I would like Backbone.js to be built-in. Just kidding. ~julio_ody
• Is this question partially inspired by nczonline.net/blog/2011/10/0…? ~roblifford
• A feature that allows browsers to detect duplicate @wycats tweets. ~jamespearce

(╯°□°）╯︵ ┻━┻

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.

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

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

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

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

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