Paul Irish

Making the www great

Chrome Canary for Developers

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
  • Features for the web platform
  • 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:


Oh right, call to action:

2012.11.02: Added CTA thanks to philip_roberts’ suggestion.
2013-03-15: Accurate data on when/how we cut Canary builds.

Interview on Treehouse

The great folks at Treehouse sat down with me for 30 minutes to talk about frontend development, my background, HTML5 Boilerplate and tooling.

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

Why I’m So Excited About Web Platform Docs

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.