WebKit isn’t a black box. It’s a white box. And not just that, but an open, white box.

So let’s take a moment to understand some things:

Now, especially with the news that Opera has moved to WebKit, we have a lot of WebKit browsers out there, but its pretty hard to know what they share and where they part ways. Below we’ll hopefully shine some light on this. As a result you’ll be able to diagnose browser differences better, report bugs at the right tracker, and understand how to develop against specific browsers more effectively.

Standard Web Browser Components

Let’s lay out a few components of the modern day web browser:

• Parsing (HTML, XML, CSS, JavaScript)
• Layout
• Text and graphics rendering
• Image decoding
• GPU interaction
• Network access
• Hardware acceleration

Which of those are shared in WebKit-based browsers? Pretty much only the first two.

The others are handled by individual WebKit ports. Let’s review what that means…

The WebKit Ports

There are different “ports” of WebKit, but allow me to let Ariya Hidayat, WebKit hacker and eng director at Sencha to explain:

What is the popular reference to WebKit is usually Apple’s own flavor of WebKit which runs on Mac OS X (the first and the original WebKit library). As you can guess, the various interfaces are implemented using different native libraries on Mac OS X, mostly centered around CoreFoundation. For example, if you specify a flat colored button with specific border radius, well WebKit knows where and how to draw that button. However, the final actual responsibility of drawing the button (as pixels on the user’s monitor) falls into CoreGraphics.

As mentioned above, using CG is unique to the Mac port. Chrome on Mac uses Skia here.

With time, WebKit was “ported” into different platform, both desktop and mobile. Such flavor is often called “a WebKit port”. For Safari Windows, Apple themselves also ported WebKit to run on Windows, using the Windows version of its (limited implementation of) CoreFoundation library.

… though Safari for Windows is now dead.

Beside that, there were many other “ports” as well (see the full list). Google has created and continues to maintain its Chromium port. There is also WebKitGtk which is based on Gtk+. Nokia (through Trolltech, which it acquired) maintains the Qt port of WebKit, popular as its QtWebKit module.

Some of the ports of WebKit

• Safari
  • Safari for OS X and Safari for Windows are two different ports
  • WebKit nightly is an edge build of the Mac port that’s used for Safari. More later…
• Mobile Safari
  • Maintained in a private branch, but lately being upstreamed
  • Chrome on iOS (using Apple’s WebView; more on it’s differences later)
• Chrome (Chromium)
  • Chrome on Android (using the Chromium port directly)
  • Chromium also powers Yandex Browser, 360 Browser, Sogou Browser, and soon, Opera.
• Android Browser
  • Used the latest WebKit source at the time
• Plenty more ports: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Different ports can have different focuses. The Mac port’s focus is split between Browser and OS, and introduces Obj-C and C++ bindings to embed the renderer into native applications. Chromium’s focus is purely on the browser. QtWebKit offers its port for applications to use as a runtime or rendering engine within its cross-platform GUI application architecture.

What’s shared in all WebKit browsers

First, let’s review the commonalities shared by all WebKit ports.

1. So first, WebKit parses HTML the same way. Well, except Chromium is the only port so far to enable threaded HTML parsing support.
2. … Okay, but once parsed, the DOM tree is constructed the same. Well, actually Shadow DOM is only turned on for the Chromium port, so DOM construction varies. Same goes for custom elements.
3. … Okay, well WebKit creates a window object and document object for everyone. True, though the properties and constructors it exposes can be conditional on the feature flags enabled.
4. … CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-.
5. … Layout.. positioning? Those are the bread and butter. Same, right? Come on! Sub-pixel layout and saturated layout arithmetic is part of WebKit but differs from port to port.
6. Super.

So, it’s complicated.

Just like how Flickr and Github implement features behind flags, WebKit does the same. This allows ports to enable/disable all sorts of functionality with WebKit’s compile-time Feature Flags. Features can also be exposed as run-time flags either through command line switches (Chromium’s here) or configuration like about:flags.

All right, well let’s try again to codify what’s the same in WebKit land…

What’s common to every WebKit port

• The DOM, window, document
  • more or less
• The CSSOM
• CSS parsing, property/value handling
  • sans vendor prefix handling
• HTML parsing and DOM construction
  • same if we suspended belief in Web Components
• All layout and positioning
  • Flexbox, Floats, block formatting contexts… all shared
• The UI and instrumentation for the Chrome DevTools aka WebKit Inspector.
  • Though since last April, Safari uses it’s own, non-WebKit, closed-source UI for Safari Inspector
• Features like contenteditable, pushState, File API, most SVG, CSS Transform math, Web Audio API, localStorage
  • Though backends vary. Each port may use a different storage layer for localStorage and may use different audio APIs for Web Audio API.
• Plenty of other features & functionality

It gets a little murky in those areas. Let’s try some differences that are much less murky.

Now, what’s not shared in WebKit ports:

• Anything on the GPU
  • 3D Transforms
  • WebGL
  • Video decoding
• 2D drawing to the screen
  • Antialiasing approaches
  • SVG & CSS gradient rendering
• Text rendering & hyphenation
• Network stack (SPDY, prerendering, WebSocket transport)
• A JavaScript engine
  • JavaScriptCore is in the WebKit repo. There are bindings in WebKit for both it and V8
• Rendering of form controls
• <video> & <audio> element behavior (and codec support)
• Image decoding
• Navigating back/forward
  • The navigation parts of pushState()
• SSL features like Strict Transport Security and Public Key Pins

Let’s take one of these: 2D graphics Depending on the port, we’re using completely different libraries to handle drawing to screen:

Or to go a little more micro… a recently landed feature: CSS.supports() was enabled for all ports except win and wincairo, which don’t have css3 conditional features enabled.

Now that we’ve gotten technical.. time to get pedantic. Even the above isn’t correct. It’s actually WebCore that’s shared. WebCore is a layout, rendering, and Document Object Model (DOM) library for HTML and SVG, and is generally what people think of when they say WebKit. In actuality “WebKit” is technically the binding layer between WebCore and the ports, though in casual conversation this distinction is mostly unimportant.

A diagram should help:

Many of the components within WebKit are swappable (shown above in gray).

As an example, WebKit’s JavaScript engine, JavaScriptCore, is a default in WebKit. (It is based originally on KJS (from KDE) back when WebKit started as a fork of KHTML). Meanwhile, the Chromium port swaps in V8 here, and uses unique DOM bindings to map things over.

Fonts and Text rendering is a huge part of platform. There are 2 separate text paths in WebKit: Fast and Complex. Both require platform-specific (port-side) support, but Fast just needs to know how to blit glyphs (which WebKit caches for the platform) and complex actually hands the whole string off to the platform layer and says “draw this, plz”.

“WebKit is like a Sandwich. Though in Chromium’s case it’s more like a taco. A delicious web platform taco.” Dimitri Glazkov, Chrome WebKit hacker. Champion of Web Components and Shadow DOM

Now, let’s widen the lens and look at a few ports and a few subsystems. Below are five ports of WebKit; consider how varied their stacks are, despite sharing much of WebCore.

* A side note on Chrome for IOS. It uses UIWebView, as you likely know. Due to the capabilities of UIWebView that means it can only use the same rendering layer as Mobile Safari, JavaScriptCore (instead of V8) and a single-process model. Still, considerable Chromium-side code is leveraged, such as the network layer, the sync and bookmarks infrastructure, omnibox, metrics and crash reporting. (Also, for what it’s worth, JavaScript is so rarely the bottleneck on mobile that the lack of JITting compiler has minimal impact.)

All right, so where does this leave us?

So, all WebKits are totally different now. I’m scared.

Don’t be! The layoutTest coverage in WebKit is enormous (28,000 layoutTests at last count), not only for existing features but for any found regressions. In fact, whenever you’re exploring some new or esoteric DOM/CSS/HTML5-y feature, the layoutTests often have fantastic minimal demos of the entire web platform.

In addition, the W3C is ramping up its effort for conformance suite testing. This means we can expect both different WebKit ports and all browsers to be testing against the same suite of tests, leading to fewer quirks and a more interoperable web. For all those who have assisted this effort by going to a Test The Web Forward event… thank you!

Opera just moved to WebKit. How does that play out?

Robert Nyman and Rob Hawkes touched on this, too, but I’ll add that one of the significant parts of Opera’s announcement was that Opera adopted Chromium. This means the WebGL, Canvas, HTML5 forms, 2D graphics implementations–all that stuff will be the same on Chrome and Opera now. Same APIs, and same backend implementation. Since Opera is Chromium-based, you can feel confident that your cutting-edge work will be compatible with Chrome and Opera simultaneously.

I should also point out that all Opera browsers will be adopting Chromium. So Opera for Windows, Mac and Linux and Opera Mobile (the fully fledged mobile browser). Even Opera Mini, the thin client, will be swapping out the current server-side rendering farm based on Presto with one based on Chromium.

.. and the WebKit Nightly. What is that?

It’s the mac port of WebKit, running inside of the same binary that Safari uses (though with a few underlying libraries swapped out). Apple mostly calls the shots in it, so its behavior and feature set is congruent with what you’ll find in Safari. In many cases Apple takes a conservative approach when enabling features that other ports may be implementing or experimenting with. Anyway, if you want to go back to middle-school analogies, think of it as… WebKit Nightly is to Safari what Chromium is to Chrome.

Chrome Canary also has the latest WebKit source within a day or so.

Tell me more about WebKit internals.

You got it, bucko.

Further reading:

• WebKit internals technical articles | webkit.org
• WebKit: An Objective View | Robert Nyman & Rob Hawkes
• your webkit port is special (just like every other port) | Ariya Hidayat
• Getting Started With the WebKit Layout Code | Adobe Web Platform Blog
• WebKit Documentation Overview | Arun Patole
• Rendering in WebKit, by Eric Seidel | YouTube
• web performance for the curious | Ilya Grigorik

Hopefully this article described a bit of the internals of WebKit browsers and gave some insight on where the WebKit ends and the ports begin.

Reviewed by Peter Beverloo (Chrome), Eric Seidel (WebKit).
I’ll update with any corrections or modifications.

1. using CSS 2D transforms and translate()
2. using position:absolute and top/left

Chris Coyier was asked why you should use translate. Go read his response which covers well why it’s more logical to move elements for design purposes (with transform) independent of your element layout (with position).

I wanted to answer this with Chrome and get some good evidence on what’s going on. I ended up recording a video on the experience:

It’s a good watch and dives into Chrome DevTools’ Timeline, compositing, paint cost, accelerated layers, and more… but if you want the abbreviated text version, read on:

First thing, Chris made some simple demos to try things out:

This sorta works, but there is such low complexity in this situation that it’s all going to look pretty great. We need something closer to a complex website to properly evaluate the two (thx joshua for the macbook!):

Now we’re starting to get closer, but immediately I get distracted by something.

Distraction: Pixel snapping

If you run the demo above you might notice the top edge of the MacBook looks a little bit better in the top/left one. (And here I am writing a post about why translate is better! Preposterous!) So this is due to the absolute positioned macbook sticks to pixel positions, whereas the translate()‘d one can interpolate at sub-pixel positions.

One of the Chrome GPU engineers, James Robinson, called this the “dubstep effect”, as these pixels appear to be getting pounded by bass. Here’s a closeup of the effect… watch the top white edge of the macbook in each:

On the left, you see stair-stepping down three pixels and back up again. This pixel snapping may result in a less distracting transition in this case, though this wouldn’t be so noticeable if you were moving objects with less of a high-contrast situation.

Back to performance

If you run DevTool’s Timeline Frames mode on these two examples here, they start to tell a very different story:

The top/left has very large time to paint each frame, which results in a choppier transition. All the CSS including some big box shadows, are computed on the CPU and composited against that gradient backdrop every frame. The translate version, on the other hand, gets the laptop element elevated onto it’s own layer on the GPU (called a RenderLayer). Now that it sits on its own layer, any 2D transform, 3D transform, or opacity changes can happen purely on the GPU which will stay extremely fast and still get us quick frame rates.

Watch the video above towards the end to see more on how to diagnose paint costs, see what areas are being repainted, and evaluate what elements are on the GPU.

Demo

Click through below, try adding more and see how the the framerate reacts. Feel free to open up DevTools, too and explore Timeline:

Guidelines for animation

1. Use CSS keyframe animation or CSS transitions, if at all possible. The browser can optimize painting and compositing bigtime here.
2. If needs to be it’s JS-based animation, use requestAnimationFrame. Avoid setTimeout, setInterval.
3. Avoid changing inline styles on every frame (jQuery animate()-style) if you can, declarative animations in CSS can be optimized by the browser way more.
4. Using 2D transforms instead of absolute positioning will typically provide better FPS by way of smaller paint times and smoother animation.
5. Use Timeline Frame’s mode to investigate what is slowing down your behavior
6. “Show Paint Rects” and “Render Composited Layer Borders” are good pro-moves to verify where your element is being rendered.

If you do front-end web development and already use Chrome as your development browser, I encourage you to use Chrome Canary.

A new Chrome Canary build is available daily (we cut at 2am PST and take the best of last 40 revisions, to be specific). Running fresh builds gives you great goodies to look forward:

• Chrome DevTools features
  • $_ (for the Console’s most recently evaluated result)
  • Styled console logs (see The Breakpoint ep #2)
  • JPEG decoding time instrumentation in Timeline
  • Lots more: read Beverloo’s WebKit updates and the Web Inspector commits RSS feed
• Features for the web platform
  • HTML5 Rocks, peter.sh, and @chromiumdev are wise news sources for this. CSS Shaders, holla!
• Large, experimental features (go visit about:flags)
  • Right now, there’s exciting stuff like Web Component’s Shadow DOM, WebRTC’s Peer Connection, and more.

Canary runs side by side

The other reason why Canary is great is because it can run side-by-side with your other Chrome install. In fact this is why the URL for Canary’s download page is “sxs”.

I recommend running Chrome Stable and Canary. That’s how most of the Chrome Developer Relations team does it. You never need to update your browser, you can watch the new stuff coming at you (and file bugs if it breaks) and still see what your users see.

11 Weeks From Canary to 310M Users

Fun fact: when a feature lands in Canary, it’s only a short 11 week trip down to shipping to all 300+ million Chrome users on stable. That is, as long as everything is on schedule and the feature doesn’t need to bake a little longer on dev channel before making its way down. Given that, it’s a smart move as a dev team to watch as features (and sometimes bugs) trickle down to have time to adapt. When a new stable Chrome is ready, all users will have it within just a few days.

Canary is available for Mac and Windows, but sadly not Linux. :( But luckily there are packages that track the dev channel Chromium that’ll keep you up to date on a weekly basis, so you can have a pseudo-canary. If you need a one-off build of the freshest Chromium available, just go to download-chromium.appspot.com; it’ll detect your OS and serve up a build that’s less than a few hours old. Hotchachacha!

Protip: you can set Canary as your default browser : Canary itself doesn’t have a setting to let you do this, as its an edge release. (Read about how Chrome ensures the stability of the Canary build). However… if you open Safari’s preferences, Canary will be listed in the Default web browser choices, so you can choose it if you want all new links to open there.

Another small tip: sometimes your Chrome extensions affect your page inspection behavior is weird ways. Jump into incognito where extensions don’t run to get a clean look.

Live on the edge

Running Canary regularly rocks, but so do edge versions of other browsers:

• Mozilla Nightly updates daily
• Opera Next updates often and you can track progress at the Opera Desktop blog.
• WebKit Nightly is basically Safari nightly (it’s their video, GPU, etc stack, but without other Safari browser features)
• Internet Explorer gives you platform previews, but since running the time-bombed VMs can be a pain, I run them in BrowserStack.

Oh right, call to action:

A few highlights:

• 3:40 Where’d I grow up? What was I into? (Also, the supercool IE4 DHTML event I went to!)
• 14:45 What’s my favorite feature inside the HTML5 Boilerplate?
• 18:34 Will web development even out where we don’t need to fuss over so many fallback scenarios?
• 22:52 Are abstractions okay? Should you always learn what’s going on under the covers first?

I’ve also updated the interview listing on my About page. <3z

I absolutely love developing for the clientside of the web. Delivering the actual interactions and UI that all users feel is an absolutely gratifying experience. However… it’s not a piece of cake to develop for all desktop browsers, mobile browsers, and all the device/OS combinations within.

It’s hard to track down accurate info, but hey we get by with an unruly combination of Mozilla’s MDN, StackOverflow, HTML5 Please, W3C/WHATWG specs, Wikipedia, and a mental inventory of blog posts, tweets and articles strewn over the internet.

Today’s announcement of Web Platform Docs, an initiative that’s been well over a year in the making, is huge. A few reasons why I’m pumped:

• All browser vendors are working together to document the all of the clientside web: DOM, CSS, HTML, SVG, Canvas, HTML5, JS, ES5…
• They’ve already contributed much of their content: all of the MSDN IE reference docs, the Opera Web Standards Curriculum, many HTML5 Rocks articles,
• Full-time technical writers from Google, Microsoft, Adobe and others authoring content around new features in addition to the strong community contributions.
• And obviously, a much more cohesive documentation situation, making it easier for us to develop with all the information we need.
• Mozilla’s MDN content can be contributed!
• The content is still alpha, but we now have a single place to document the web platform.

How can you help?

1. “Upstream” your writing. If you’ve written a widely cited article exploring a feature or documenting cross-browser bugs, gotchas, certainly you can help a educate a vastly wider audience.
2. Contribute browser support data. We thrive on knowing the mobile/desktop compat story. PPK will be publishing his compat tables there, and you can upstream compat facts from other sources freely.
3. Fix bugs! Already a few bugs/annoyances have been unearthed. Please report them but more importantly, we’d love help fixing them! Attach a patch to a bugzilla ticket and we can push it live ASAP.
4. Poke around the WPD: prefixed pages to get a feel for the current content activity.
5. Jump into #webplatform on freenode IRC or join the public-webplatform mailing list.
6. If you have expertise in technical writing or content strategy, we’d love your help!
7. A whole lot more! Read the WPD: Getting Started guide!

This won’t be perfect overnight and will take a while to completely supplant existing distributed documentation sources… but I’m very excited about this first, shared small step. Three cheers to making a better experience for everyone building for the web.

These days, our performance bottlenecks are oftentimes DOM, <canvas> API methods, SVG. Those are our priorities. So then why do we see all browser vendors competing on raw JS when we are hacking our way around to avoid the actual performance pain points? So we wanted to solve that with RoboHornet.

Today, a cross-vendor collection of developers, led by Google, is open-sourcing RoboHornet. As project lead Alex Komoroske put it, “it’s a living, dynamic benchmark that aims to use the collective efforts of the web development community and ultimately get browser vendors to fix real-world performance pain points.” Let’s look at how RoboHornet will hopefully flip the above situation on its head.

1. Web app developers identify and isolate a specific pain point in their app
2. That issue is reduced down to a solid benchmark
3. Propose it to a committee of JavaScript experts from JSPerf, YUI, Google, Facebook, and others
4. Everyone votes for which issues should make it
5. Of the top voted items, as long as the committee thinks they are good, they head into the benchmark
6. The RoboHornet Suite now better represents the web app developer communities biggest priorities for performance
7. Browser vendors compete on their RoboHornet score, optimizing the slow behaviors that developers prioritize
8. Everybody wins. Yay ice cream for everyone!

What’s in there now

The current items that RoboHornet tests captures the major pain points of jQuery, Google Apps, Google Maps, Ember, Handlebars and Cappuccino:

• Adding rows to an existing table
• Adding columns to an existing table
• Descendant selectors at different DOM depths
• Converting a 2D canvas to a data URI
• Clearing a 2D canvas
• Table render speed after innerHTML.
• Scrolling speed using scrollTop
• Resizing columns in a table
• Resizing SVGs
• ES5 getter/setters
• Referencing the arguments array
• Scrolling lots of animated GIFs
• The affect of forcing a reflow by calling offsetHeight
• Replacing a number of DOM nodes using the Range API
• localStorage write performance
• localStorage read performance

You can vote on and review incoming tests in the issue tracker.

RoboHornet represents you

The project is still in alpha and we’d love to get your involvement to better represent everyone. We’re using Benchmark.js internally, as its experience on jsPerf has proven it a trustworthy and reliable benchmark harness.

1. Please take a look at the site
2. Watch the RoboHornet Github project
3. Read how you can be more involved
4. Submit the performance pain points that your apps run up against.

While you’re at it, go check out the full review of RoboHornet at Tom’s Hardware

Early last year, something clicked in my head when I saw this video: Crossing the Chasm: Pitching Security Research to Mainstream Browser Vendors.

You mean.. there are academics… who are doing research on browsers.. in universities? My my! You mean bright minds think about the same things as us and don’t publish them on Octopress? ;)

Turns out it’s quite an active area of research. So, I’ve put together a list of academic papers, talks, and researchers all centered around frontend development and browsers (Please chime in on the comments if you know of more):

Webapps

Gibraltar: Exposing Hardware Devices to Web Pages Using AJAX UC San Diego, Microsoft Research, Univ. of Singapore, 2012

Modeling and Reasoning about DOM Events Brown University, 2012

Don’t Repeat Yourself: Automatically Synthesizing Client-side Validation Code for Web Applications University of Illinois at Chicago, 2012

Performance

Who Killed My Battery: Analyzing Mobile Browser Energy Consumption Stanford, 2012

How far can client-only solutions go for mobile browser speed? ACM Digital Library, 2012

Race Detection for Web Applications Sofia University & ETH Zurich & IBM T.J. Watson Research Center, 2012

Leo Meyerovich - Berkeley Rsearch UC Berkeley, 2009 (Parallel Browser Execution, Security)

James Mickens - Microsoft Research Microsoft, 2004- (Performance, localStorage, Mashups, Speculative Execution

Debugging & Tools

Timelapse - Interactive record/reply with Webkit inspector Univ. of Washington, 2012

Cleanroom: Edit-Time Error Detection with the Uniqueness Heuristic Univ. of Washington, 2010

Firebug Research - Academic papers related to Firebug Various, 2012

Realtime Performance Visualizations using Node.js How to NODE, 2011

How Programmers Debug, Revisited: An Information Foraging Theory Perspective Wentworth, OSU, & IBM TJ Watson Research Center, 2010

Security

Crossing the Chasm: Pitching Security Research to Mainstream Browser Vendors Carnegie Mellon, 2011

Benjamin Livshits - Microsoft Research Microsoft, 2004-2012 (Malware, Privacy, JS Benchmarking, JS Compression, JS Static Analysis, Security)

Dynamics of JavaScript Purdue, 2011

Adam Barth - Research Various, 2007- (XSS, CRSF, Security…)

Data Visualization

Highlights of the Infovis Conference, VisWeek 2011 2011

JavaScript

Gregor Richards - JS Research at Purdue Purdue, 2009-2011

Cleanroom University of British Columbia, 2011-2012

Anders Møller - Research Aarhus University, 2002-

Non-JavaScript Tooling

Whyline for Java Natural Programming, 2009

Stacks Plorer Media Computing Group, 2012

Omniscient debugging with TOD Pleiad, 2007

The Elm Programming Language Elm Lang, 2011-2012 (a type-safe, functional reactive language that compiles to HTML, CSS, and JavaScript)

1. They are excellently skilled in their area of expertise and go out of their way to teach others how to gain these skills
2. They participate in open source projects that fuel the community’s knowledge and productivity
3. They have independent opinions that are derived out of testing, and evidence-based fact finding worthy of learning from

So, here is a list of people we admire:

• Ryan Seddon: @ryanseddon aka the CSS Ninja develops Modernizr, writes polyfills, and explores the edge of DOM APIs. His recent exploration of source maps lays a lot of groundwork for future web debugging potentials.

• Hans Christian Renl: @drublic started contributing extensively to HTML5 Boilerplate and has been actively engaged in other projects we have worked on. He also maintains a blog where he shares his learning experiences and explorations of advanced CSS features.

• Alexis Deveria: @fyrd maintains caniuse.com, and contributes to svg-edit, the open source svg editor. He also created & maintains the canonical timeline of web browsers which has been the basis of other browser history graphs since. He also upstreams all the data from caniuse.com to its API, is used to power sites such as api.html5please.com and html5rocks.com

• Jason Kiss: @jkiss’s notes on accessibility are like a breath of fresh air into the dense field of accessibility. He tests in as many accessibility technology tools as available and bases his opinions on findings from his research. His articles are extremely valuable to web developers who have long had to base how to do the right thing on superstition and fact-free opinions.

• Kit Cambridge: @kitcambridge develops some of the best-in-class javascript libraries and assists many open source projects on Github. Take a look around bestiejs to see his fine work and friendly demeanor.

• Eric Dahlström: @erikdahlstrom is not just the editor of SVG specs, but also helps out often in mailing lists and Stack Overflow with SVG questions. Not only that, he is an unbelievably skilled (obviously!) at hand-coding lightweight SVG, and maintains a repository of SVG images that are worthy of learning from on how to do SVG right.

• Masataka Yakura: @myakura watches HTML/etc. specification changes, browser bug trackers and mailing lists, and reports the best stuff on his G+

• Matt Seeley: @innerhtml is a JS hacker at Netflix, who measures constantly and talks about the science of cross-device hardware accelleration

• Tim Branyen: @tbranyen created Backbone Boilerplate and Backbone Layout Manager to make it easy for everyone to get started with Backbone. He also writes extensively on his blog on dealing with problems of creating web apps.

• Mathieu Henri: @p01 has an in-depth understanding of JavaScript and shares amazing experiments that are possible within less than 1K of JavaScript such as canvas with audio (warning audio) & Speech Synthesizer. He also frequently contributes to @140bytes on what is possible with 140 bytes of JS.

• Roman Cortes: @romancortes is one of few who can explore some interesting innovative uses of CSS. His explanation of a 1kb chrismas tree is a whirlwind of frontend knowledge.

• Peter Beverloo: @beverloo started off a series on his blog documenting what’s new in WebKit/Chromium. He’s since been hired by Google and works on Chrome for Android. His work in distributing edge browser development news has helped thousands of people track the quickly expanding web platform.

• Erik J Moller: @erikjmoller is to WebGL what @dahlstrom is to SVG. His skill and ability to hand-code webGL is unparalleled. He created a 10-part video on learning webGL (webGL 101) that is archived on youtube not to mention is the main contributor to EmberWind an open source webGL game that is highly performant.

• Irene Ros: @ireneros dabbles in info-viz tools and has published several of them on GitHub. She is active in contributing back to open-source projects and also maintaining a few of them including Miso Project and underscore.nest.

• Mike Taylor: @miketaylr is developer relations extraordinare for Opera. He has been a behind-the-scenes force getting a lot of cross-browser compatibility and feature detection complete and distributed.

• Zoe Mickley Gillenwater: @zomigi wrote an excellent book about CSS3 and publishes informative articles on CSS on her website that are a good resource for anyone who is working with CSS3.

• Niklas von Hertzen: @Niklasvh created html2canvas, essentially a rendering engine in JavaScript. He’s also had a number of exciting experiements like a Sudoku Solver in CSS.

• Zoltan Hawryluk: @zoltandulac painstakingly researches making CSS3 features backwards-compatible with IE, in addition to blogging about several discoveries in the process.

Other Unsung Heroes

There are clearly far more people that deserve to have their praises sung. Plenty of people whose names you already know, but also folks like @ZachLeat, @Alex_Gibson, @mbostock, @RobFlaherty, @Raynos2, @bricss and more.

Thank you

We are grateful towards everyone who has helped us along the way to shape the web to be as friendly as possible to web developers, by driving the work on frameworks, libraries, articles and outreach. They do it on their own time, because of their love of and fascination with the web.

All of them are well worth your time to pay attention to and follow and hear their opinions of the web.

Who are yours?

We’ve left out some of the bigger names in this list, so hopefully we can all discover someone new who covers a relevant field extremely well. This is our list, but feel free to leave a comment with anyone you’d put on yours. Or better yet, blog it yourself and link up your list here.

I wanted to take a moment to explain what this IE update policy means for us web developers.

The big change is how IE now interacts with Windows Update: Before you had to opt-in to have “Recommended” updates installed automatically. It’s likely few folks did. Now, IE upgrades are shipping as “Important” and this class of updates are defaulted to install automatically. A user can still opt-out and immediately after the announcement of this feature they also published details on how enterprises can opt-out. But still, this is a good move, it helps.

The policy manifests as:

1. Windows XP holdouts on IE6 or IE7 get the boot up to IE8
2. Windows Vista and 7 users still on IE7 or even on IE8 get shunted up to IE9
3. IE10 only works on Win7+, and while no policy has been published for Win7 users, it’s likely any IE8/IE9 users will be moved up to IE10.

A very smart policy call was that this update policy also includes all of China, which is important because most of their Windows installs are not genuine. Microsoft decided they should get the IE bump anyway, which is great because China has been dominated by IE6 and IE8 for ages.

This update procedure was scheduled to start in Australia and Brazil in January 2012. If we look at what happened in Brazil, we have a good shift of users but it’s flattened out with a nontrivial amount of left behind users: (see the two blue lines in the chart below)

(Source: StatCounter Global Stats - Browser Version (Partially Combined) Market Share)

Australia has a similar swap of users from IE8 to IE9 but IE8 still remains steady above 10% overall share there.

Microsoft is in a tough spot in that they have enterprise customers who have developed their intranet applications in an extremely poor manner and they break outside of old browsers. But we’re going to need some more pushes from them and us, the developer community, to get in a better state. We want to develop for the web platform of now, not the platform of four years ago.

TL;DR: There is now a policy in place, but evidence indicates that it’s not as effective in eradicating these zombie browsers as what we need. Personal opinion: we need to do better.

Hopefully this clarifies a bit about the mechanics of the update procedure. Please do correct me if anything is wrong and I’ll update the post.

(Consider the two blue lines)

Source: StatCounter Global Stats - Browser Version (Partially Combined) Market Share

For a very long time, developers have been told about making websites ‘accessible’. Like it is a faucet that should be turned on or off. Till Victor Tsaran’s demonstration of using a screenreader (which was in 2007 - a very long time since accessibility evangelism began) - very few web developers had any idea of the real immediate impact of implementing accessibility features.

During a Nicholas Zakas & Victor Tsaran talk years ago I finally grokked the easiest rule for a first step towards accessibility. For such a long time, we conflated functionality while JavaScript-disabled with “being accessible”. It took me years to learn that making it keyboard-navigable was the top priority.

Just as a datapoint, The WebAIM survey results (published yesterday) reveal 98.6% of screenreader users have javascript enabled.

What we need

People like Jason Kiss and Steve Faulkner who detail the behavior and support in browsers and screenreaders are providing the developer community with invaluable knowledge, stuff that is far more worthwhile than publishing a yet another list of you-should-do-these-things. (See also my resources list in the semantics post).

Most developers have no idea what effect adding ARIA markup to our documents has on people using screenreaders. We need that. Actual before-and-after video stuff makes this topic real. See zomigi’s recent post: videos of screenreaders using ARIA, for great examples.

Most developers have no idea how to implement ARIA. The W3C Primer that looks like a spec is not at all appropriate for a web developer audience.

Just like it’s valuable to witness an a11y usability session where you see how disabled people use your site, I think it’d be useful for the accessibility community to see how developers build, because thus far there has been a disconnect in communicating effectively. I don’t think we need more on the ground evangelism yet. There is a dearth in online resources at the moment, developers need to know these practical ways of using and having users benefit from accessibility techniques:

• Which features should I use and which should I avoid (which features are actively harmful because of shoddy screen reader/other a11y tech support?)
• What are the top priorities for developers to implement?
• Videos of screenreaders in use (Thanks Zoe!)
• What one thing can I do as a web developer to my sites and apps that dramatically improves the UX for disabled users
• How do some of these features work? What are they for? A demonstration of how each feature makes an impact or gets used by a user would be most helpful (e.g. how do focus rings work?).

Screenreaders & browsers

Also, I’m not quite sure how everyone else feels, but from here it feels like yelling at a fucking brick wall with JAWS and Window Eyes. We just kinda hope and pray their support for things improve. As a pragmatic approach, I tell developers that if it works in NVDA, good enough. We have a mess of browsers we need to support already, dealing with ATs that lag years behind is not at all feasible.

A lot of developers do not understand that accessibility first comes from implementing the platform accessibility API by browsers such that screen readers can take advantage of the rendering. Most operating systems expose an API that allows browsers to map what is rendered on the screen to one of the interfaces that the operating system’s accessibility API exposes.

Unfortunately, there has been no specification, so each browser has been left to do whatever it wants in terms of defining the relationship between a HTML element and the accessibility interface. Hopefully this will change with the HTML to Platform Accessibility API implementation guide and ensure each browser exposes each element consistently to the Platform Accessibility API.

Which shores up a greater concern: Better accessibility starts with the browser (and the platform). Browsers should be able to handle content loaded dynamically rather than expecting developers to do it for them. If content on a page that is displayed is altered, it needs to be noted to the accessibility api transparently instead of having developers bolt on extra markup to do so.

Accessibility should not be opt-in but opt-out.

This post is a elongated version of the comment I left on Karl Grove’s Barriers to improving the accessibility game plan. It was probably the best post on a11y I’ve ever read. I really liked his approach in evolving the a11y strategy and left my thoughts.

Thanks to Divya Manian for her thoughts and words on this post. Thanks to Jason Kiss for reviewing drafts.

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:

1
2
3
4
5

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

1
2

/* 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.

Adjustments for Third Party Content

Any third party widgets add content directly into the page may need extra attention. Any widgets inside an iframe (like Disqus’s new theme) are naturally insulated from the parent page’s layout styles. If you need to make adjustments to the third party content you can apply box-sizing: content-box; to the widget and its descendants. This may not be trivial as form controls in particular are border-box by default, so you’ll also have to account for that.

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. 275 feeds.

Standards development and browser dev news. 56 feeds.

Blogs focusing on building large webapps (new!) 22 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.

Sylvain Galineau, who works on the standards side of IE, indicates the document mode situation painted above is probably unlikely. I admit it seems preposterous. Perhaps I should have left the document mode aspect out of this post entirely. Anyway, Sylvain says: “Bottom line: I think all you have established is that things will probably not turn out that way.” So that’s good! :) Exchange here:

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