Browser testing CSS and JavaScript

After reading Andy Clarke’s article CSS: Browser testing order I’ve been thinking a bit about my own approach to testing CSS and JavaScript during development. My testing order, why I test in the browsers I do, and why I do it in that particular order. I’ve never taken the time to document my testing process, so this was a good opportunity to get it done.

First of all, at NetRelations we rarely mention specific browsers to clients. Doing that seems like a thing of the past to me. Instead we mention the standards browsers need to understand in order to handle full functionality and design, and explain that the content will be accessible regardless of which browser the visitor uses. The only time we do mention specifics is when a client asks for a detailed list of supported browsers, and that has happend only once or twice in the last several years.

When you look back a few years browser market share was always very important in every project. To me it felt like everybody (well, mostly project managers and Microsoft-oriented developers) was looking for reasons to exclude this browser or that browser, this group of users or that group of users. Sure, there are plenty of shops that still have that mindset, but it feels really backwards.

Ok, enough of that, here is my personal browser testing order. It has turned out to work well for me, but it won’t work for you unless you’re a Mac user:

1. Firefox, Mac OS X

Firefox is not my favourite browser for “casual” browsing, but when developing a website, especially if I’m doing JavaScript work, nothing beats it.

2. Safari, Mac OS X

Safari, being my browser of choice for non-development stuff, is next. It’s always running anyway, so it only takes me a couple of seconds to check that everything is still ok, which it almost always is.

3. The rest of the good Mac browsers

Time for the big browser launch. When something major (a full page template or a particularly tricky part of a design) is done I give it a quick check in the latest version of every browser that runs natively on Mac OS X. Currently that means Camino, Flock, iCab, Netscape, OmniWeb, Opera, SeaMonkey, Shiira, WebKit Nightly, and any other newcomers. I load the page, increase/decrease text size, resize the browser window, that kind of thing.

At this stage it is very rare for any problems to occur in browsers other than iCab and Internet Explorer. iCab is usually pretty much OK, with perhaps just a couple of cosmetic glitches.

4. The bad Mac browser

Before leaving the Mac OS X environment I take a quick look in Internet Explorer, where things can be a real mess. If the layout is too broken (i.e. the site becomes hard to read or use) I spend a few minutes trying to make it behave. When those few minutes are up I have either found a reasonable fix for the problem, or will change my @import rule to use single instead of double quotes to hide the CSS from IE/Mac. Unless the client has specifically mentioned full CSS support for IE/Mac as a requirement, of course, but that has happened exactly once in the last couple of years. After all, we are talking about an unsupported browser that is no longer available for download.

5. Linux browsers

I also like to keep an eye on what things look like for people using other Operating Systems than Windows and Mac OS, so I have both Ubuntu and Kubuntu Linux installed. I check Firefox in Ubuntu and Konqueror in Kubuntu. I have only experienced problems in Konqueror, but they tend to be solvable.

6. Internet Explorer 6, Windows XP

When it’s time to take a look in this browser I always start feeling a little anxious, so I don’t like launching IE/Win half an hour before it’s time to go home or on a Friday afternoon. IE 6 is the number one nerve wrecker and ulcer inducer, and this is always where any really serious CSS problems occur. Luckily I have run into a large enough number of IE bugs to know that there is almost always some kind of workaround, and its JavaScript quirks are well known and possible to work around. But as my co-workers can tell you, IE 6 is very good at sending me into computer rage mode.

7. Internet Explorer 7, Windows XP

In most cases IE 7 cooperates fairly well compared to its older versions, but it has enough bugs, weird behaviour, and general lack of support for CSS to be a serious development speed bump.

8. Internet Explorer 5.*, Windows XP

Once IE 6 and 7 have been beaten into submission, IE 5.5 tends to be OK enough as well. IE 5.0 is usually a bit less cooperative. But this check is really just to make sure the site is accessible and usable. I do not spend time making these old and unsupported browsers display exactly the same design or provide the same functionality (again, unless specifically requested, which hasn’t happened in years) as modern browsers.

9. Opera Mobile

A sanity check in Opera Mobile or, if I don’t have a mobile phone with a usable browser handy, in the Small screen view of Opera for Desktop.

10. Lynx

Checking your work in a text-only browser that has no JavaScript support is a good way of making sure that your HTML structure is logical and that your content is semantically marked up. I usually save this for last for no particular reason. It is extremely rare to run into any issues at this point since I have already made sure that my markup works without CSS and JavaScript.

One of many correct orders

I’m sure there are many more approaches to browser testing, and one order isn’t necessarily better than any other. What’s most important is to check in the most capable browsers first, and only after that start applying fixes for Internet Explorer.

By the way. As you may have noticed, the only Windows browser I check in is Internet Explorer. I have occasionally launched Firefox and Opera on XP just to make sure everything is OK, and I have never seen any rendering differences whatsoever (apart from the difference in text rendering between XP and OS X), so I haven’t seen the need. If anyone is aware of any specific differences between platforms in those browsers, please speak up.

Now then, is your testing process different from mine, and if it is, how and why?

Posted on February 26, 2007 in Browsers, CSS


  1. How about mobile browsers such as opera mini?

    Is Lynx sufficient for that?

  2. February 26, 2007 by Roger Johansson (Author comment)

    Hugh: I knew I had forgotten something. I normally check in Opera Mobile before checking in Lynx. Checking in a text-only browser is good, but not sufficient for determining whether the site is actually reasonably usable within the constraints of a much smaller screen.

  3. February 26, 2007 by Jeremy

    god, i hate IE for Mac. i do figure if i can get it to look good in there, it can look good anywhere.

  4. My testing is very similar to the process you have. Now, I strive to make every site fully accessible at the core - but one browser I sometimes leave out is IE on a Mac. I have done this on 2 current sites I worked on with a friend. This was due to 2 reasons:

    1. Doing user research over a 3 month timespan showed no visitors from that browser.
    2. Microsoft and Apple have abandoned support/build of that browser. I feel like it is targeting NS4 for certain things.

    Do you find you have many people still using IE on the Mac?

  5. February 26, 2007 by Roger Johansson (Author comment)


    Do you find you have many people still using IE on the Mac?

    No, thankfully.

  6. The last Mac version of Internet Explorer (5.2.3) was released in June 2003, almost four years ago. Internet Explorer wasn’t bundled with OS X 10.4 (Tiger), which was released on April 29, 2005. Microsoft stopped supporting the Mac version of Internet Explorer on December 31, 2005, and took it off their Macintosh downloads site on January 31, 2006.

  7. Occasionally opera renders some margins a bit different from firefox, so I always check in opera too. Since i don’t have a mac, I use swift for webkit rendering.

    my order:

    firefox > opera+small screen mode > swift (webkit for windows) > ie7 > ie6

    And that’s all I check in really.

  8. I start in what I regard as the top - Opera, and work my way downwards. Usually I cross-test in the major win and Mac browsers simultaneously, to see that they all behave well at different stages of development.

    I haven’t updated my browser-support list for a long time, but the list is correct apart from the fact that I’m using later versions (where available) now.

  9. February 26, 2007 by Jeff Edsell

    What, no Netscape 4?

    Okay, I’m kidding. NN4 was the bane of my existence for years, as a major client (a bank) insisted its employees use ONLY that. So to some extent I had to build two versions of everything, one for the client and one for the rest of the world.

  10. Regarding 10) Lynx: you can do the same in Firefox, by going to View > Page Style > No Style


  11. I tend to test on all browsers as I go along. I find it’s much easier to fix things there and then, than spend an hour wondering which bit of my CSS is causing IE to fall over backward.

    If I leave cross browser testing till after I’m done with one browser, it’s much harder to nail what’s going wrong - especially with floats. Was it that the container width is getting calculated wrong, or the margin on the floated elements within it, or a bug with list padding, or something else? Too many possible causes for one symptom (a busted layout). By testing as I make each change, I know exactly what it is that’s causing a broken layout, and I can fix it as soon as it happens, rather than waiting for a symptom later down the line that could be due to any number of causes.

  12. On commercial projects I use the same process you describe except for the Explorer version order: first a fresh stylesheet for IE7, which most of the time fixes some problems for IE6 too, and than down the version ladder.

  13. “when developing a website, especially if I’m doing JavaScript work, nothing beats it [Firefox]”

    Amen. Web developer toolbar and DOM inspector, invaluable. I don’t think any other browsers tools do as good a job.

    I’m fairly surprised you test in as many browsers as you do. My approach is:

    1. Code to the standards.
    2. Work around non-standards behaviour in widely-used browsers.

    I feel that if Gecko (Firefox et al), Presto (Opera) and WebKit (Safari) agree on how my code should be displayed, I’ve completed step 1.

    I then check Trident (Internet Explorer), and break out the conditional comments and swear words, in order to complete phase 2, as I don’t think there are any other browsers one could consider widely-used.

    I thus assume that any bugs in minority browsers will be due to incorrect rendering on their part, and as such I’ll only bother looking if someone complains.

    Of course, I run the risk of annoying site users/customers using minority browsers. But I think the extra effort required on my part to check in as many browsers as you do would outweigh the benefit of not annoying those guys.

  14. February 26, 2007 by Roger Johansson (Author comment)

    Regarding 10) Lynx: you can do the same in Firefox, by going to View > Page Style > No Style

    No, that is far from the same actually. The same content will be there, but the default rendering of HTML elements differs a lot.


    I’m fairly surprised you test in as many browsers as you do.

    Most of them only take a few seconds, and I check in them to keep my OCD at bay.

  15. February 26, 2007 by Cezary Okupski

    As Lucida Grande is wider than Tahoma I was frequently running into problems with fixed-size labels, menu elements and suchlike when developing first on Windows, then testing on Mac.

    Opera for Mac has also poor implementation of Aqua controls, so for example input[type=’submit’]{padding:0} will make your buttons illegible. Try it. I know a generic hack for Opera, but to distinguish Opera for Mac I sadly rely on JavaScript. :( I have just started wondering how form controls look like on mobiles… What operating system is this Opera for?

    On the other hand I don’t even pretend that I develop for IE < 6, excluding evil with conditional comment. ;)

    1. In most occasions I do some build-test-build-test-… cycles with Fx/Win (equipped with Web Developer Toolbar, Firebug etc.)
    2. When the styling is done, I turn my sight to IE6/Win (and IE7/Win) and start a near-infinite loop of developing and testing again.
    3. If the IE6 headache ever stops I have a quick look at Opera/Win which, mostly, behaves beautifully. All Windows users are satisfied at this point

    4. For my own good sleep, I reboot my machine and test Fx/linux, Opera/linux, Konqueror, Amaya (for the sake of completeness), elinks

    5. At this stage I start testing IE5-7/linux. (I really should omit this step) These browsers are a real pain in my … contractor

    Now if only I had the money to buy an Apple…

  16. If you’re using Parallels or VMWare for your Windows testing, it’s easy to set up a virtual machine with a trial version of a screen reader like Jaws installed. The 40 minute trial mode is adequate for checking the basic accessibility of a site when accessed with the Jaws/IE combination.

    Obviously this is not sufficient for a proper accessibility assessment, which would require testing with ordinary users of screen readers and other assistive technologies. But it’s a useful and instructive experience.

  17. I have a similar approach to Matt Wilcox: make a start only checking in Firefox (Windows) but soon move into checking in FF, Opera, IE6 & 7 as I go along. When I’m happy with those I then go to IE5.5 and 5.01 before checking Mozilla, Netscape, Safari, Camino and Konqueror.

  18. On my MacBook I test using Firefox (Main browser), Safari and every once in a while, Opera.

    Then on Windows I check with Firefox, IE 6 and IE 7.

    I don’t really see much benefit in testing the more obscure browsers. Most people use IE, Firefox, Opera or Safari. Anything else takes too much time and usually doesn’t render a horrible mess, if it works fine in the common browsers.

    Although now that you mentioned Lynx for Java-script and HTML structure, I may add that to my list.

  19. I do lynx a lot earlier, second after Firefox, and here’s why:

    I want to make sure that any javascript I use, when ignored by a browser, will not affect the usability of a site at all.

    Not to plug myself, but check out with javascript on and then off. When it’s on, the javascript style selector works and is fine. When javascript is off, the javascript style selector disappears entirely. Not only that, but any reference to it in the body text (like the one on this page also disappears.

    I think that’s a good example of my main javascript-universality principle. It should work great when javascript is on, but if the user has javascript off for whatever reason, the user shouldn’t even be able to tell that it was ever there in the first place.

  20. I do my development in Linux so I start off with Firefox and Konqueror.

    I then switch to Windows and pick up the pieces with IE6/IE7/IE55 followed by a look in Opera/Netscape and finally I check Safari on Mac.

    I think I need to start checking in Lynx and Opera Mobile though.

    Thanks for the article - very interesting!

  21. February 26, 2007 by Struan

    I’ve a similar approach to Roger but not as thorough on the other mac browsers. I do check IE6 quite early on however as it is a known trouble maker and therefore best to catch the errors before too much CSS has been written.

    What I have a bigger problem with is usually colour since i do most prep on my powerbook.

    As an aside most of guys are lucky being able to test. I tried to set up a browser testing environment at work using VMs but the IT unit think that IE 7 and mac browsers don’t have big enough market share so i have to take the code home with me.

  22. I try to use an iterative development cycle. I write and test the basic presentation and layout in Firefox first, then test in IE7 and fix any bugs. I then write mores styles and test again. Every now and then, I test in Opera and Safari just to see how it’s going, though they usually have very few bugs, if any. I sometimes test in OmniWeb and iCab, though they are usually fine also.

    When the design is getting close to finished, I take a look at IE6 and see what needs to be fixed. Most things are usually fine, especially if it’s just a typical layout like every other site, but there’s sometimes just a few little things.

    I don’t bother testing in Lynx. I just ensure that the site works fine without styles, scripts and images, and I know Lynx won’t have any trouble.

    I sometimes test in Konqueror, but since it’s KHTML rendering engine is really good and have never had any serious problems with it, I don’t always bother.

    1. Opera for windows, my primary browser, and therefore it’s easy just to load the html-file in a tab.

    2. Firefox for windows, usually when stuff works fine in Opera, it works in FF, and if it’s a problem, I’ll go over the code - since Opera and FF is pretty much alike.

    3. IE for windows, in my latest projects my IE-testing has gone good, only minor double margin-errors. After a while you know what CSS usually breaks up IE, and I often check IE if I add something like that.

  23. I do the initial build in Opera, then check in Firefox and IE6/IE7 as things progress (all PC). When the page is coming together I’ll then test Mac browsers if they’re available (this means I borrow my fiancee’s macbook pro :)).

    I generally don’t test in Lynx, but I disable CSS/scripts/plugins/etc in Opera and make sure it all still works. That said, I avoid js/plugins pretty thoroughly so it isn’t usually an issue.

  24. February 27, 2007 by DigitaLink

    I start with FF/linux, then usually go to IE6/win(VM), then I’ll check Opera/linux, then Konqueror/linux. Generally I find the fewest problems with FF/anything, Konqueror is usually okay, Opera is normally fine (although apparently won’t do %-based image scaling … ems work fine though). Past that, I’ll run it by IE7/win at the office, since I don’t have IE7 at home at all. IE7 has fewer problems than IE6 to be sure, but it’s still FAR from good.

    I’d never really thought about using lynx before tonight though … it gives an interesting new look at the web to be sure!!

  25. Do you folks have to much time, wasting it testing for IE/Mac and IE5.x/Win. I mean how many users do still use them? They are deprecated by Microsoft for years. Is it one user of thousand or one of ten-thousand?

    Using lynx for testing a web-sites’ structure, some kinds of accessibility and search-engine readability is very useful.

  26. February 27, 2007 by ErikHK

    Why do you have both Kubuntu and Ubuntu installed? Why not have only Kubuntu installed and test both browsers in that? Do you want to have default settings or what?

  27. Roger, have you seen the new Device Central application that is part of the Adobe Photoshop CS3 beta at all?

    I’m curious to know how you think that would fit into your browser testing process?

    Also, I’m curious about people’s mobile browser testing processes generally, is this an issue for people?

  28. From a ‘pragmatic developer’ perspective, most of these comments surprise me. Like it or not, the majority of browser usage sources still show Gecko-based + KHTML-based + Opera browsers coming in at under 30% of total, & where I work IEx on PC still accounts for the vast majority.

    I tend to test my code in IE6/7 (PC) & Firefox (PC & Mac) concurrently, then work on some of the more obscure, older browsers.

    I must admit that I spend a larger amount of time than I should working on CSS for browsers that hardly anyone uses (IE5.x, older Opera versions), but I code for a large university website & you’d be surprised by some of our browser usage stats!

  29. I tend to aim for FF/Win first, fix any problems with IE7, then any problems with Safari and IE6, then anything else, if I’ve got time.

    The usage stats on the sites I’ve done recently vary between 60% and 90% towards IE (tending slowly towards IE7, but still quite a lot of IE6 users), with most of the rest being FF/Win. Less than 5% accounts for all the rest, hence the priority order: I need IE6 and 7 to work, and FF/Win. If Safari doesn’t work, the design guys here complain at me, so that has to work as well, and anything else is really just a bonus.

    I’ve also started looking at how sites work when scaled to tiny screens (mobiles), but it isn’t high priority at the moment.

  30. I’ve always found it easiest to program for IE6 and Firefox. 99% of issues in all other browers will be eliminated if you can tame the two of them together.

  31. I think the approach to building and testing is usually dictated by the environment you work in and the type of site being built.

    Government and local authority sites often require the support of browsers and versions that we, as developers, would prefer to see consigned to the history books. Whereas, commercial sites often offer a greater degree of latitude when it comes to browser support.

    Personally I check in the browsers that popularity in our server logs dictate, So, on Windows it’s; IE6, IE7, FF1.5, FF2, O9 and on OS X it’s S2, FF1.5 and FF2.

    My personal preference for a development browser is Opera, for all of the reasons mentioned by others, and also because I have been using it’s development features long before Firefox arrived. If it ain’t broke…

    I also test as I build. Once the basic layout is implemented and tested everything else is usually just a matter of “tweaking” with no real surprises in store.

    Ultimately (IMHO), there’s no substitution for experience when it comes building a standards based CSS site.

  32. I test in both FF Mac and PC and have found some differences between them. The differences often had to do with spacing, rounding calculations, or links. Also FF has been pretty good about later versions fixing bugs from previous versions.

  33. I usually try to test every major step in the (x)html/css/javascript -phase of any project at the same time in following browsers:

    Firefox, Safari, Opera, IE6 (via parallels) and IE7 if I get an adequate pc to take full advantage of it ;-)

    but I’d be really interested in how you guys, especially you Roger, manage it to test in IE6 & IE7, do you have several pcs and macs staying around in your offices or???

    For the most of the time while testing in IE7 I borrow the notebook of my mum and connect it to my home-network and everything works fine, except the fact, that i need TWO machines to do ONE job…haha

    so, how do you handle that situation?

  34. I generally try to test in Firefox and IE concurrently. This way when IE breaks the design, which is inevitable, I’ll have a general idea of what I did to cause it. I get close to pulling my hair out trying to squash a show-stopping bug, having no idea what the cause is.

    But I’m also impatient with IE, so FF gets the most action. Opera always plays nice so I don’t have to worry about it, and I rarely have problems with IE7 either.

  35. Checking sites in Lynx is good, but using it as semantic code sanity check is disingenuous, since Lynx doesn’t understand anything over HTML 4, so it’s not going to recognise many semantic tags even if they’re jumping up and down waving flags.

  36. February 28, 2007 by Paul Lieberman

    I also do my development on a Mac and use Firefox for all my debugging. However I find I avoid a lot of extra work if I test with IE6 first rather then later. Everything looks better on a Mac. Best to see what the rest of the world will see before you get to far along. Paul

  37. Camino, Flock, Netscape, OmniWeb, SeaMonkey, Shiira, WebKit Nightly

    Why do you check in every browser that based basically on the same engine (Mozilla, Web Kit)?

    My current full testing process (I have Mac and PC to test):

    Opera 9 > Firefox 2 > Safari 2 > IE 7 > IE 6 > Firefox 1.5 > Latest Web Kit > Latest Firefox 3 > iCab 3 > Opera 8 > Firefox 1

    Quicker testing process (when I’m pretty shure that everything is fine):

    Opera > Firefox > Safari > IE

  38. February 28, 2007 by Roger Johansson (Author comment)


    Do you folks have to much time, wasting it testing for IE/Mac and IE5.x/Win. I mean how many users do still use them? They are deprecated by Microsoft for years. Is it one user of thousand or one of ten-thousand?

    How many people use browser X or browser Y is pretty much irrelevant to me. I spend the few minutes it takes per site I build to make sure there are no serious usability or accessibility problems in old browsers. That’s it.


    Why do you have both Kubuntu and Ubuntu installed?

    Because I installed Ubuntu first, then realised I needed Kubuntu to run Konqueror.


    Roger, have you seen the new Device Central application that is part of the Adobe Photoshop CS3 beta at all?

    Nope, never heard of it.


    but I’d be really interested in how you guys, especially you Roger, manage it to test in IE6 & IE7, do you have several pcs and macs staying around in your offices or???

    I use Parallels to run multiple Windows XP installs on my Mac.


    Lynx doesn’t understand anything over HTML 4, so it’s not going to recognise many semantic tags even if they’re jumping up and down waving flags.

    Which browser does understand more semantics than is in HTML 4?


    Why do you check in every browser that based basically on the same engine (Mozilla, Web Kit)?

    Because they do differ slightly, and I like being thorough.

  39. March 1, 2007 by Jerry Jeff

    It seems strange to test in (general) from lesser popular browsers to most popular. I want to know if a site is broken for 80+% internet users ASAP.

  40. March 1, 2007 by Roger Johansson (Author comment)


    It seems strange to test in (general) from lesser popular browsers to most popular.

    Browser testing order is not about browser statistics, it’s about testing in the order of best CSS support to worst. Fixing the inevitable IE problems when you’ve written your CSS as it is supposed to be written is much easier than relying on IE’s bugs and bastardised interpretation of the specs and then try to apply fixes for real browsers.

  41. March 1, 2007 by jbot


    Sorry, I HTML 3.2.

    My point was that it wouldn’t understand tags like label ones, since these didn’t come out till later. It doesn’t even understand tables, so you’ve got another semantic limitation, although there are alternatives such as using lists.

  42. If anyone is aware of any specific differences between platforms in those browsers, please speak up.

    I think CSS automatic numbering doesn’t work on OS X.

    I found out about it when I finally found a way to make auto-numbering work on Firefox XP. but when a friend of mine tested it on OS X using Firefox, Opera, Camino and Safari, nothing happened. he said it might be a platform specific issue.

    here’s the test page. do u mind cheking it out?

  43. March 1, 2007 by Roger Johansson (Author comment)

    jbot: Yes, you’re right about there being some limitations to the semantics that can be displayed with Lynx. My version (2.8.6dev.11) does support tables though.

    Rizky: That example works fine in Camino 1.0.3, Firefox, Opera 9.10, and WebKit Nightly, all on Mac OS X. It does not work in the current version of Safari.

  44. Interesting methodologies. Far more extensive than mine, but then again web site design isn’t my main focus.

    A couple of comments though, you shouldn’t have needed to install Kubuntu to get Konqueror, just install the relevant parts of KDE on the Ubuntu install.

    Similarly, you could use one of the stand alone installs of IE6/5.5/5 on the XP virtual machine and you would only need one VM.

  45. March 6, 2007 by Roger Johansson (Author comment)

    I installed Kubuntu because I was curious and because I didn’t have time to figure out that I could have installed Konqueror on Ubuntu :-).

    I don’t trust standalone versions of Internet Explorer, especially when it comes to conditional comments, so instead of trying to hack around that it was much quicker for me to just duplicate a VM. I have room on my HD, so why not.

  46. I use Fangs, a text based screen reader emulator for Firefox/Mac/Win:

    Fangs will output your page as text that emulates mostly the way a screen reader will be reading your page. It’s not exact, as repeated tests of JAWS and Fangs will show you, but it has some advantages.

    The text output can be copied and emailed to others to show them what their page will look like when AT users are reading it. There is a serious “Aha!” factor here. It’s great for explaining things in a way that JAWS can’t.

  47. Since w3C, webdesign s not just something visual..

    But we are loosing time, with all those navs, and the bunch of differences -.-;

    Dont forget Netscape ?! Imo netscape is the quickiest with javascript

  48. Good article. I use to check a couple of those browsers myself, but then again, I only do web design as a hobby. :p

    IE can be really frustrating sometimes. When for instance it comes to margin and padding on boxes etc. and sizes in *em, IE becomes a demon spawn from deepest hell.

  49. CSS is about as much ment to create interactivity on a page as Javascript is to style it. Each has it’s purpose and ofcourse you need to use both if u want interactivity and styleing done on your page.

  50. March 9, 2007 by jc.julien

    “If anyone is aware of any specific differences between platforms in those browsers, please speak up.”

    There’s an issue about menus unfolding over a flash annimation. Works in Firefox on Windows but doesn’t in Firefox Linux and Mac.

    Documented here by Veerle:

  51. I do the initial be built in in Opera then check in Firefox and IE6/IE7 as things (all PC). Firefox to like because of ensemble useful plagins for webmasters

  52. Interesting how developers coalesce around the same working mode. Reading through your order of steps, I started to wonder how so many different developers all pretty much end up doing things the same way… without ever having discussed this issue amongst themselves.

    …I always start feeling a little anxious, so I don’t like launching IE/Win half an hour before it’s time to go home or on a Friday afternoon. IE 6 is the number one nerve wrecker and ulcer inducer…

    Exactly. Isn’t it funny how your heart starts beating faster in anticipation of how IE5/6/7 starts messing with your standards-compliant code? Those few seconds when IE boots up, and you mentally prepare yourself for some unforeseen havoc….

  53. I like to build for the optimal experience first (which I consider Firefox), but the very next step is see how the masses will see it (IE6/IE7), once those 3 are managed, just about everything else typically falls into place.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.