Develop for Chrome First

Creating a new site for desktop users? Develop in Chrome. Here's why.

We were asked recently by Armando Rosario about how we approach development, given the fractured nature of feature support in the browser market. To understand how we approach development and what our practices are, let's see where we stand compared to years past.

10 years ago was the rise of Internet Explorer; crushing Netscape Navigator, precursor to Firefox (which wouldn't show up in any real sense for another 3 years) and holding greater than 85% market share until just five years ago. It wasn't until 2008, just 3 years ago, that Internet Explorer even dropped below 75% and made room for some new competitors like Firefox, Safari and now Chrome.

While stats are varied by source the median puts IE at 46% - not surprising, but unfortunate, given how terrible development for the myriad IE versions can be. Firefox still holds its consistent 2nd place at around 30% but Chrome is eating everyone's lunch: up to 16% from just 6% a year ago. Safari at 6% and Opera at 2% round out our desktop browser share going into this decade. So what do we do with this info?

How We Develop, in a Nutshell

We build for Chrome. It doesn't have the highest market share (IE, of course) and it doesn't have the best development tools (Firefox / Firebug) but it has the best engine, and the best buzz, and the brightest future. We build for Chrome, and then we build for everything else.

We build for Chrome …We build for Chrome, and then we build for everything else.

That doesn't mean we don't build for other browsers - as wonderful as life would be if we only had to tackle one browser, the needs of our clients come first and generally, our clients need support for IE 7 and up, including Firefox, and including both Windows and Mac.

How We Develop, in Detail

Our development process at ZURB can be wrapped up in 4 key elements:

Clean, semantic code

Good data vs. display abstraction

Progressive enhancement

Browser targeted code

Clean, semantic code isn't just a buzzword - we pride ourselves on writing readable front-end code that actually represents the proper way to format data, including using new HTML5 markup elements like <nav> and <section> which with some very simple support are easily backwards-compatible.

Abstracting data and display means we apply the same consideration and care to separating HTML and CSS - no inline styles, no hackery to make something lay out correctly.

Progressive enhancement (or the other way of seeing it, graceful degradation) means that while we ensure a solid, usable presentation in all browsers, not all browsers will look exactly the same. We and (in almost all cases) our clients understand that using new properties like border-radius, box-shadow, generated gradients and more allows us to develop faster, with more control and less QA or troubleshooting. It saves our clients money and saves us development time on our own products - all while building out future-proof, usable design.

Finally, browser targeting means that when we need to correct for a browser we can do so quickly and easily. We parse the user agent string (which tells a server what kind of browser the user is in) and use that to apply a class to the body with the name and version of the browser. Let's say we need to implement a small correct for IE7 - we start our declaration with body.ie7, and then specify the needed overrides. It's not a catch-all, but it does help us pin down the last 5% in QA.

Business Goals Come First

The browser market is in the most competitive state it's ever been in, and that's a two-edged sword. Competition means that all browser makers are working hard to create a better browser - even Microsoft, with IE9 poised to be the best they've ever made and a genuine competitor to modern browsers. It also means that support for different features is fractured, and implementation of details differs, and a consistent experience is difficult.

Take our advice: build for the future. Every cool thing that's going to happen online will happen in the future, and if you build for it, you're ready. However, dona''t let that damage your business goals - if your business needs to support IE7, support it. Do it in a smart, scalable way and don't worry if IE7 users won't see rounded corners on their buttons; in our experience (and we have more than a little) they won't notice or care.

See things a different way? We'd love to hear how you approach development cross-browser, and we're always willing to try new things. Let us know in the comments!