Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Browser Dependencies

August 20, 2003

In Designing with Web Standards, Jeffrey Zeldman advocates designing for the best browser you have on hand and then testing in the lesser ones, contrary to old-school methods of web design.

The theory, I believe, is that you are then building your site in closest possible conformance to the official W3C specs.

Until recently for example, I’d build sites in IE6/Win, and then ‘hack’ them to work in Mozilla. This only lead to problems down the line, since the original rendering relied on a buggy rendering engine (IE6) and created dependencies on it that better browsers won’t handle the way you’d expect them to. I noticed more than once that if I had to hack my CSS to make it work in Mozilla, Mac browsers would do very unpredictable things to the resulting code.

So now I develop in Firebird, and test later in IE. Is it better? I can’t say for sure yet. I’ve developed one site this way: this one. But I’ve never seen it in Safari, and no one using Safari has reported errors. That has to count for something. What has your experience been with this method of testing?

Reader Comments

Sonia says:
August 20, 01h

“The most interesting part of that process is step 1.”

I tooootally agree.

It’s been a blast trying to really nail the markup of new sites we’re working on. Trying to get the most CSS bang from the least amount of tags, just for fun more than anything else (does that make me a 12 Dave?)

August 20, 01h

I build and test in IE6 to begin with, sometimes even (shock, horror!) using IE-only code to play about with things at first. Luckily my pages them seem to usually render almost perfectly in other more standards-compliant browsers.

The real problem comes when I load up IE5 or 5.5 (which have extremely different rendering engines, and should be treated as separate versions) - they usually eat up the vast majority of my time. I can cope with IE6, just not the awful bugs of 5.x.

August 20, 01h

For me, it’s all about the javascript.

I began writing serious javascript in late 2001, when Mozilla was .9. Even though Mozilla had many flaws back then, the javascript console was its killer app.

I quickly found that javascript written in Moz ran 99% perfect in IE, but javascript written in IE would usually fail in Moz. So I did the sensible thing and developed for Mozilla first.

After firebird came along, I quit using IE completely.

Keith says:
August 20, 01h

I realized sometime last summer, after many painfully unlearned lessons, that even though the majority of my users on most projects come in via IE 5+ (WIN) it’s much more time effectient in the long run to develop for Mozilla based browsers first and then tweak to fit IE.

The fact of the matter is you’ll simply save yourself time that way as it’s easier to hack for IE. Especially when working with CSS based sites.

Dave, if you remember way back when we were working on my Zen Garden entry, at the time I didn’t have access to a PC or IE and I was able to get a pretty good idea of what I needed to change, tweak, etc. without having to see it in that browser.

Mozilla applies the “rules” much better than IE, building for it enforces good coding habits, insures much less chance of error and since it has much better support for standards it sets you up to not have to re-do any of your sites down the road.

Code for IE and you might be kicking yourself later if not sooner.

p says:
August 20, 02h

i test in ie6 first, but if something doesn’t look how it should look, i load up firebird too. once i’ve got the groundwork of a layout down though, then i test in all new-ish pc and mac browsers.

August 20, 02h

It looks like writing clientside code for MOZ (firebird at the moment) is the way to go, I’ve been doing it that way for two years now, mainly for the same reason Lloyd does. That Javascript console is really handy. When working on my own site I use Safari seeing as this will become the Mac browser of choice. I thought I’d get a head start and it hasn’t thrown me any curve balls yet.
Funny enough the most problems I have is with Opera 5 & 6 (Mac & PC). It has gaps in handling the DOM and CSS2. I use the MOSe approach mentioned on this site not so long ago and so I need to take care that I don’t trip over older version of Opera. Opera 7 is absolutely fantastic, and has always worked first time, no matter what I threw at it.
BTW. I’m using javascript to fix the boxmodel in IE 5 and 5.5. And let doctype switchimg fix it for IE6. So far so good. It works with no fuss, plug and play. Load up and forget your boxmodel woes. But the jury is still out until I’ve used it for another couple of months.

Sam says:
August 20, 03h

The fact nobody has reported a problem with Safari can only really be A Good Thing if you know people with Safari have actualy seen it. Mind you if you haven;t had a Safari viewer up to this point then I guess you don;t have to worry too much :-)

MikeyC says:
August 20, 03h

“But Iíve never seen it in Safari, and no one using Safari has reported errors”

Dave, I’m sure you are already aware of Browser Cam: but in case you’re not give the free trial a shot. I tried it recently: and found it rather handy.

Sunny says:
August 20, 03h

I always keep open Firebird and IE6. If it works in Firebird, I work under the impression that it will be fine in Safari. I do check on IE5 for Mac (at my college).

BTW, Dave, have you seen mezzoblue in IE5 for Mac?

Dave S. says:
August 20, 04h

Sunny - sigh. Yes, I have. Kinda gross, isn’t it?

Zeldman mentioned a fix for it - removing white space in my source code. That’s pretty damn extreme for my tastes; I think I’m going to let it slide.

Were this a commercial site, I’d re-consider though.

Dan R. says:
August 20, 04h

I’m still in the habit of developing with IE5/Mac, on OS 9. Whenever I use OS X, Safari or Firebird are my browsers of choice, but I still can’t get myself to switch over to OS X full-time, so IE5 it is.

I find that IE5/Mac displays CSS exactly the way it’s supposed to, with very few exceptions. I’ve actually found many instances where something works properly in IE5/Mac without any massaging, mostly works in IE6/Win, and has quirks in Mozilla-based browsers, and then I have to apply hacks to make IE5/5.5/6 work, and do weird things with CSS to make Mozilla work.

When Mozilla browsers are happy, Safari seems to be happy, which is a blessing.

I suppose I’ll soon be developing with Safari/Mozilla as my test browsers, and then tweaking for IE6/everything else.

August 20, 04h

With the risk of sounding facetious building a site for a specific browser whether it’s commercial or not isn’t really an issue. You build a site for your users, visitors, or dare I say it, customers. And in a sense most of us are customers. We benefit from your insight and that of others, in this case for free. Many designers use IE 5 because they use a mac, and use it in classic mode (photoshop on OSX still stinks, it’s way to sticky). I know it’s still silly of them not to switch to OS X and use Safari or Mozilla but there you have it.

But this is, more or less, a personal site with your views and idea’s. So if ‘customers’ want to benefit from this cutting edge website they’d better well upgrade and get in the game. No need to get it running with yesterdays browsers. This site does look good in IE 5 for PC though. ;)

Jai says:
August 20, 06h

Dave… Just removing whitespace would fix this? Try this MT-Plugin:

That does a pretty good job…

This way, if you don’t like the results, you can just remove a few tags and it’ll all be back to normal.

Sunny says:
August 20, 07h

Dave - I will prolly let it slide too. IE5 mac is not worth worrying abt really. I think (although I am NOT a mac user) that their are superior options for Mac users such as Safari, iCab, Camino.

Can anyone tell me if the speed claims of Safari are for real? Its really astounding!

John says:
August 20, 07h

Having just updated to Firebird v.0.61 I now use it as my preferred development and cruising browser.
I was stunned by its rendering accuracy over even v.0.6
It would not forgive mistakes or sloppy coding at all.


Osiris says:
August 20, 10h

I was wondering why the emphasis on Mac? I understand that it is the main dev platform for many, but how many people visiting your page will be using Macs as opposed Win/IE? I understand that cross-platform compatibiity is important, but is it really worth the time to make it look perfect for the odd user?

Just for interests sake.

Ethan says:
August 20, 10h

I wholeheartedly recommend building in FB first, then hacking the CSS as needed for the “slower kids” on the browser bus. It’s not altogether different from application design (or hell, anything else requiring a bit of testing before go-live); start with the most scalable, sound foundation possible, then build in exceptions for cases as you come across ‘em.

But that’s just me…get your varying mileage on, I guess.

August 20, 10h

Define for me ‘best bowser,’ please. Is it the one most people use, or the one that best conforms to standards, or some other guidepost? Should one develop to work on one browser first before hacking for others?

BTW, I have had no issues with browsing this site using Safari.

Dave S. says:
August 20, 10h

We all know ‘best’ doesn’t necessarily mean ‘most popular’ (VHS/Beta, yadda yadda), so I guess in this case I mean specifically the most solid, standard-compliant rendering engine. Safari is good; Opera 7 is good; Mozilla/Firebird is good. I think you can be reasonably assured if you’re using either of those as your goalpost then you’re doing okay. Safari might be questionable since its v1.0 release was a little rushed, but it’s still pretty darn solid. (thanks for confirming)

Conan says:
August 20, 10h

Ah, so you have become enlightened. Welcome to the fold, illuminated one! For your path has become clearer, and the road easier for your choice of destiny. Behold! For now the chains of needless burden that hung from you have been cast-off, and broken asunder! Would that others hearken to your words, and follow your example.

Stephen says:
August 20, 10h

The best story I can give is my last site design I coded primarily for Mozilla, then went back and cleaned up a bit for IE. Nothing too hard, just re-arrange a few tags and stuff.

Well about a week later I got my hands on Opera. At first I felt alienated by it’s completely different interface and “odd” options, but then I launched my page. Not a singal rendering bug was found. I simply flipped out when I saw this and became a die-hard standards fanatic…

Arikawa says:
August 20, 10h

I normally tackle IE/Win last, since the display problems I encounter there rarely show up elsewhere. For me, it certainly makes more sense than the other way around.

So it’s Safari/Camino/IE5.2, then off to Mozilla/Opera and finally IE6.

The only problem I have with your site in Safari is the Zen Garden and Blue Spark buttons at top which are misaligned. But I think you might have mentioned this in an earlier post.

Jai says:
August 20, 11h

I’ve been taking a stab at designing for Mozilla lately, then looking at IE/6 myself. There are some weird and quirky ways that IE/6 seems to render certain pixel defined CSS paddings/margins. But like most people have said above, it’s nothing that a few minor tweaks couldn’t fix. Of course, when I built this kinda thing for IE/6 and then took it to other browsers things got much more difficult to fix. Zeldman is a smart man, no matter what his critics may say about him. I think he truely understands the rendering engines and I’d trust his judgement on the “design for ‘best’ browser first” concept. Heck, it seems to work pretty well.

August 20, 11h

I do exactly what you describe here. It’s worked fine so far. I generally don’t bother with other browsers because I assume that non-IE browsers support standards properly. I’m guessing from the feedback you’ve got here that my assumption is correct. :)

August 20, 11h

Absolutely agree. I was just about to write on the same issue. I’ve found the fastest and trouble-less way is Mozilla.

And it allows you to use amazing bookmarklets, as Edit styles, that makes the main layout incredibly fast.

Then it’s all down the road fixing box model and hacking remaining bugs.

August 20, 11h

For me personal site I don’t care that much about IE, since it doesn’t understand properties I use for formatting code ( white-space:pre; ). I do test in IE, the first layout I made ( you can’t call it design, but someone is working on that :)) didn’t work in IE completely.

You can’t style the root element for example, which gave some problems. So I worked around that one with a fresh try, ‘cause I get some readers who are using IE.

For business sites I use the same technique as the Zen Gardener here ;).

gaston says:
August 20, 11h

I think Zeldman’s ‘start with the best’ is better. I’m currenty using Firebird and IE6 open both at the same time while writing the page. I sort of see what’s not looking good in both at the same time.

Then I usually have to ask a friend to check stuff in their macs.

But anyway, if you use the design for best browser first, you shouldn’t be having that many problems with most ‘good’ browsers. On the other hand starting with Netscape 4 and then checking for Firebird, Safari, Opera 7 etc… would be hell.

Sonia says:
August 20, 11h

“The theory, I believe, is that you are then building your site in closest possible conformance to the official W3C specs.”

Am I missing something? Why not just code to specs, that is, write valid code?

I guess if you are writing a valid xhtml/css site, no tables, you generally do write valid code, but have to hack your css to make the misbehaving IE siblings sit up at the table…

And (pardon my rookieness/ignorance!) Moz and Opera and IE handle the padding and margin on some elements differently as well, so would it not be best to have all three open at once?

August 20, 11h

I develop in Opera 7 (faster than Mozilla, easier to switch between different debug stylesheets) then take a look in Mozilla and handle the bugs in IE Win at least.
Starting with IE is like felling a tree with a nailfile… :)

Dave S. says:
August 20, 11h

Sonia - obviously that’s the point. But valid code doesn’t always translate to cross-browser compatibility, otherwise browser testing would be unnecessary.

Thomas - coming out of the old-school mindset, most people still tend to test in the lowest common denominator. That’s what worked back then, it’s how you had to do it. So this is a matter of changing habits, and that’s a tough one to crack. IE is, for most purposes, the lowest common denominator. Figuring out that you shouldn’t code for it natively takes a leap of faith at first…

gaston says:
August 20, 11h

Totally agree with sonia there… why don’t you have a couple of browsers open at the same time?

seems like the logical thing to do.

Sonia says:
August 20, 11h

Get it, thanks!

I didn’t come from old school, and Jeffrey’s book hasn’t made it to Spain yet

Matthew Farrand says:
August 20, 11h

This is so true.

I was involved in designing an intranet project recently and for the first iteration of the design I used IE5.0 as the base browser, as the only browsers I needed to support were IE 5+ for Windows. I found myself tearing my hair out trying to work round the bugs and incompatibilities in IE 5 and 6.

Between the first and second iterations of the design I had read Zeldman so I decided to test in Mozilla 1.4 first and then tweak the design for IE/Win. This took a lot less time as I could separate my mistakes from rendering bugs much more easily.

So in my experience even if your brief only encompasses IE/Win, basing a design around standards and testing it in a browser with good standards support saves time.

gaston says:
August 20, 11h

Not from the old school either here.

August 20, 11h

That’s how I do it - Firebird then IE then Opera then Safari then Mac IE5.2 then OmniWeb then *shudder* iCab and NN4 just for fun. I dragged an old iMac out of a dumpster for Mac browser testing. I’ve found this significantly reduces the amount of crap I had to deal with when I was designing for IE first.

creative8500 says:
August 20, 12h

When I learned about W3C recommendations and specifications I downloaded Mozilla, because IE6 didn’t support the correct box-model. Now I make my documents W3C-compatible, so they’ll work in Mozilla. After that I check the pages in other browsers to see if they don’t look too different there.
I’d rather make my code W3C-compatible than cross-browser-pixel-perfect. That’s why I will never use ‘-moz-‘-CSS-properties.

haze says:
August 20, 12h

what? are you saying IE isnt the best browser? LOL

August 20, 12h

In general, I am in favor of this top-to-bottom method.

In parctice, I often find myself doing a bit of an “outside-in” thing. Since my University job forces me to make sites look reasonable in Netscape 4.7x, I have a general design process that looks something like this:

1. Mark up content in XHTML. Test in Lynx to esure proper flow and such.
2. Link to a basic stylesheet that Netscape 4 will see.
3. Write styles for basic (NN4) stylesheet. Typically, this is fonts, colors, and not much else.
4. @import an advanced stylesheet, for modern browsers.
5. Write styles for advanced stylesheet, taking full advantage of as much CSS as possible, not really caring whether it works in “mid-level” browser such as IE5 or IR6. At this point, I’m just getting it to look perfect in Safari/Mozilla/Other near-perfect browser.
6. Revert to a mid-levvel browser (usually IE5 and IE6) and tweak styles to staisfy them.

So, you could say that I first get the text-based browser (Lynx) and the relic (netscape 4) out of the way, and then go top-down from there – usually starting with Safari (as it’s my primary browser).

As an aside, it’s my experience that Safari and Mozilla render almost identically 99% of the time.

Dave S. says:
August 20, 12h

Jeff - that’s more or less my process, although I bump your step three down to the last, if even at all.

The most interesting part of that process is step 1. It’s still amazing to see how nicely separated your content and presentation can be these days.

ColinR says:
August 21, 01h

I develop mostly on Mac and use Camino as my working browser and Mozilla to check form elements. Never had a problem with Safari. However, I can’t let Mac IE slide because the majority of people that I work with use it. If and when I work on a PC I use Firebird.

Either way, Win IE is the final test and I am yet to suffer any major problems, except that maybe I only have IE5 and no copy of 6 to test with so I just have to cross my fingers.

August 21, 01h

Being a Linux monkey, my development path has been forced upon me! IE is always the last to be tested. I start off in Opera as it is bloomin’ quick. testing in Moz Firebird rarely results in needing any changes. It’s just IE which makes my life a nightmare, putting in random bugs in odd places for reasons I’ve understood…

Owen says:
August 21, 04h

Generally, working from the top down, as it were, has proved a real time- and stress-saver for me. I used to develop almost exclusively with IE6, then test and tweak and hack for other browsers. Since the advent of Firebird I’ve adopted it as my development (and personal) browser of preference, relegating IE6 to the inbred cousin status it deserves.

I find browser testing one of the most frustrating and annoying duties of working as a Web designer. All those browsers, all those operating systems: there are way too many variables to consider for it to be anything other than a necessary evil.

At work I’m able to test Opera7, NN7, NN6, NN4.79, IE5 and Lynx (ah, the simple beauty of Lynx!) all on Windows, but have to run home to test on MacOS 9.1 and my badly installed Linux partition.

My regret is not being able to test in Safari and Camino, as my souped up 4400 (yes, I know…) just can’t run OS X.

Can anyone recommend a pared down browser testing suite, a minimum of browser/OS combinations that will cover the majority of user preferences (aside from the ubiquity of IE/Win)? As others have mentioned above, is it really possible to assume that my design in Browser X on Platform A will look the same in Browser Y on Platform B?

One day, all this will be unnecessary…

Owen says:
August 21, 04h

Further to the above: what I meant by lasy question was is it OK to assume that (for some browsers, e.g. modern, Gecko-based ones) a design will be the same across platforms? Can I test in FB/Win and assume NN7/Mac and Moz1.4/Linux will look the same?

Owen says:
August 21, 04h

Further to the above: what I meant by that last question was is it OK to assume that (for some browsers, e.g. modern, Gecko-based ones) a design will be the same across platforms? Can I test in FB/Win and assume NN7/Mac and Moz1.4/Linux will look the same?

August 21, 06h

Speaking of browser testing: a developer friend of mine, who happens to be a Windows user, swears by the Mac for one thing: browser testing.

He’s got a Mac OS X machine that he’s installed Virtual PC and X11 on. He’s about to test is any Windows browser, all Mac browsers (OS 9 or X), Unix browsers (such as Konqureror), plus Unix text browsers (such as Lynx). That is pretty much the only thing this guy uses his Mac for.

I understand a shiny new G5, just for browser test, probably isn’t in the budget for many of us…I just think it’s cool. :)


August 21, 06h


It’s my experience that you can reasonably expect any Mozilla-based browser on any platform to render the same – at least to the point of 99% accuracy. I regularly use Netscape 7 on Mac, Windows, and Unix (AIX, mostly)…and they all display pages the same way.

I’ve found that Safari renders pages VERY similarly to Mozilla. In almost every case, these two are identical, but I have seen some differences.

Although I don’t use Konq often, I think it’s reasonable to assume that it will render very much the same as Safari, since they are both based on the KHTML engine.

Hope this helps,


Dave S. says:
August 21, 07h

Re: Gecko browsers

99% of the time, they do render the same. The only time I’ve run into trouble on this is with NN7, since it’s based on a slightly older version than Mozilla’s currently at.

So bugs that have since been fixed show up from time to time.

Both show up in NN7.

Tim says:
August 21, 12h


I develop/implement (though not design - I leave that to the art studio…) on Linux, which out of necessity forces me to use something Gecko-based (or Konqueror), as IE doesn’t exist under *nix.

So, the working methods you describe pretty much happen by default ;)

Jack says:
August 22, 08h

Looks great in Safari!!

August 22, 08h

I code with Mozilla, Opera 7, and IE6 all open at the same time, which also (mostly) covers NN7. If I’m feeling decadent, I’ll open NN7 too.

I’m still in the “ask a friend to check the mac browsers” stage of my web design life. The G5 is looking pretty nice, though…

Kris says:
August 23, 07h

1). While building, I preview and test in Safari, keeping an eye on Camino and Firebird where ever I feel something kreeping up.
2). Testing on older versions of Mozilla and Netscape 6+. Testing on Opera 5 and up. Testing IE/Mac5.0/.1/.2.
3). Testing and fixing up MSIE5/Win and up.

After a while you get a feeling for what is possible and what is not, what is a potential problem and what to do to prevent it or hack around it if it persists. To distinguish between fault in the spec (rare), fault by me (sometimes) and fault in the browser (often) is what the game is about.

One of my colleagues built his site using CSS-P, and was quite happy with it until he saw the results of his efforts in a browser other than IE/Win. His initial reaction was “our browsers are broken!”. Later he learned that it was IE he had been catering for, that he implemented a lot of CSS wrongly and that it would be better next time to preview in a browser that gives a better image of what the site is ‘supposed’ to look like and then adjust for IE/Win where needed.

Take that from the guy you mention in one line with Todd and Doug. :)

August 24, 05h

I completley agree with this approach. For years I’ve thought that getting people designing on a Mac and then testing on a PC was a pretty sure-fire way of making sure that you kept things as open as possible - but the increase of new compliant browsers has made that even more true - designing in a web standards / compliant way, using Mozilla-based browsers like Camino or Firebird for in-design testing is definitely my preferred approach. Let’s keep fixing sites for the buggy browsers until then end (hello IE6), not make it the centre of our craft…