Paul Irish

Making the www great

Developers We Admire.

One of the good things about having the eyeballs of many people is that you now have the ability to throw other people into the limelight that completely deserve to be in it. Divya Manian and I have been, for a while now, putting together a list of people in the front-end development community who, in our opinion, could use more broad acknowledgment and attention. They’re also inspiring because…

  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, 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 to its API, is used to power sites such as and

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

2012.08.27: Heartwarming: @zoltandulac’s writeup of the inspirational frontend developer Walter Zorn 2012.08.29: Gray Ghost Visuals wrote about his heroes

The Skinny on IE’s Update Policy

Every month, WebKit, Firefox and Opera are shipping incredible features; IE10 is also going to settle up and even out those HTML5 Test scores (plus some features they may debut, like Grid Layout!). But while these features are becoming available in some browsers, most of us can’t use them because we have a sizable audience who have been left behind on old browsers. A while ago I made a big fuss about IE’s lack of solid upgrade path and how it meant we’d end up with 10 major versions of IE in the wild. But luckily, things took a turn for the better when Microsoft announced a new autoupdate policy for IE.

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.

2012.08.07: Added TLDR. 2012.07.02: To see this update policy in better context it’s probably useful to Read this Developer’s Guide to browser adoption rates and check the charts from Ars Technica below.

2012.09.21: Months later, the net effect of the update campaign is complete. It pushed a whole bunch of users up to IE9 but IE8 usage remains solid. :( WinXP is a big problem here, obviously. We have to explore other ways to move these users off a zombie browser…

(Consider the two blue lines)

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

Accessibility and Developers

Jacob Thornton has an inspiring slide deck on accessibility that brings to fore some of the concerns that web developers have with implementing features around accessibility.

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.

A series of stairs and a ramps interleaving between them

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.

June 1: Added link to freshly published WebAIM survey results 2012. I encourage you to read the whole thing, as it’s a fascinating view into an audience we have challenges understanding.

2013.06.06: This has been translated into Czech: [Dostupnost a Vývojáři](