Develop for Chrome First

wrote this on in , . 42 reactions

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!

Swing and a Miss
You're Design Thinking Too Much
Design pot
Design or Get Off the Pot

It has 8 comments.

Armando Rosario (ZURB) says

Many thanks Jonathan. We have finally clawed our way out of IE6 support, and was definitely curious if you even did IE7 anymore. I agree that its driven by business requirements, but we've found IE6 was just costing us - and the client - more money.

Greg (ZURB) says

Developing for Chrome first is an interesting strategy, since they still don't hold too much of the market share. I can respect looking into the future, but you can't overlook the present along the way.

The developer tools that Firefox offers make it my browser of choice, checking in with the others as I go along. It's no surprise that IE is consistently the odd-ball out, and usually takes a bit of extra work. However, I find that with clean code and a bit of creativity with your designs, you can usually get IE to display nicely as well.

Sam (ZURB) says

I would add to this that developing for chrome first allows you to develop for 2 other very active platform almost without hassle : Safari and iOS-Safari. FF and IE (each from 7 and up) are platforms on their own. They may all react differently on various subjects (CSS, JS, DOM, you name it), while webkit based browsers are as of now very similar once you compare their way of handling your code.

But what about handheld browsers ? What is your strategy regarding opera-mobile, fennec, dolphin, etc. ? Create a specific standalone version of the site or the "gracefull degradation" takes care of it from start ?

CW (ZURB) says


Thomas (ZURB) says

Any tips on selling this process to management? In my work environment, there are few managers with IT backgrounds, they just want it done quickly.

Jonathan (ZURB) says

@Sam Good point about the benefits of using Chrome when it comes to Safari and iOS (and in most cases Android browsers as well, which also use WebKit). While they aren't all quite in step they are, as you say, very close. For handheld browsers like Opera Mobile or Fennec, building for WebKit gets you most of the way there - we'd use our browser targeting to correct any small issues or, if we're talking about a different UI entirely or a vastly different engine, we'd use media queries to apply another stylesheet.

@Thomas The beauty of building for Chrome is that it gets things done quickly! By starting with one modern browser you can prototype faster and get something clickable in front of management that much sooner. Building for the future for ideological reasons could be a tough sell to a manager, but getting something working in front of them is a big win almost every time.

Nicky (ZURB) says

Why isn't making a website more easy, so many browser with all their problems. We still have to develop at the first place for IE7, here in Belgium Chrome has only a marketshare of 6-7%. I hope it will change.

Mike Taylor (ZURB) says

And yet your experiments like only contain (webkit, moz) vendor prefixed CSS. A little shortsighted, don't you think?