When it comes time to cut up Photoshop mocks and get into all of the amazing fun that is XHTML and CSS I always, as a rule, design for FireFox first. I figure if I design for a browser with proper CSS support and a decent understanding of the box model, then I can keep all of the “hacks” needed for IE in a separate style sheet and keep tabs on them. I can rest assured that my website will do well on future browsers because it is coded according to web standards and browsers are only getting better with their standards support. I can dream about a day when IE6 will lose it’s grip on the browser market and I will be able to delete that IE-only style sheet and reminisce about the “old days” when you had to use the !important hack.
I’m currently finishing up a bunch of front-end code for a website that we are pretty sure will mostly be viewed using IE6. We know this for 2 reasons: 1) Over 80% of web users still use IE6 as their primary browser 2) This website is for public libraries and we’re pretty sure the city doesn’t have money for an IT guy to run around updating old browsers. The fact that a site is going to be viewed mainly using IE6 may seem like a given for any websites considering #1 above, so we went ahead with the usual “code for FireFox, hack for IE6″ approach.
This should have been no problem, I’m as good at cross-bowser compatibility as the next guy. But due to a wild client, we were on a super tight deadline. This super complex site full of JQuery wildness needed to be off to the back-end developers in the morning and it was already 8pm!
At around 11pm we got to thinking “maybe we could have saved some time and money by just coding this site the old way from the start”. What we mean by “Code for IE6″ is basically table based layout. Super old code for a super old browser. Were we right to think that? Could we have saved time and money coding for IE6 from the start?
No.
First of all, this site is for public libraries and they would need to be fully accessible to everyone. Table based layouts are not semantic and therefore not accessible. Second of all, if we know people are going to be using older computers with an older browser, we should try to make the site as fast a possible to load. Everyone knows that old table-based layouts take a long time to load. If we did this site the old way we would have ended up with a slow site that wasn’t accessible.
So that’s it. I always hear developer friends talk about coding only for IE6 because the software they are developing is going to be used on an intranet in an organization that uses IE6 exclusively. That’s horrible for a couple of reasons. First, explain to the visually impaired employee down the hall why you coded a site that he can’t use. Second, thanks for solidifying the IE6 stronghold on the market for another few years. Companies can’t upgrade browsers if their intranet depends on an old one.
If you’re too ignorant to keep up with new technology and learn new languages (XHTML/CSS) have fun getting a job in the near future. If you’re coding a site for IE6, do it in FireFox first and hack for IE. That way you won’t have any problems when your organization decides to upgrade to a newer web browser.
Now, who wants to come with me as I try to convince libraries to upgrade their web browsers?