Cross-browser insanity!

I’ve been working on couple web-projects for last couple of months, doing more intense web-development than for some time (my work takes me sometimes to the system side, even to hardware, and then back again to the application level).  This time I’ve had the pleasure to work on a design that has to work on all grade A browsers, and also support the evil IE6 as something like 20-30% of the demographics of the users of the site still use that browser. Most of such users are likely locked in by a standard corporate desktop or another.

I have been developing the site for FireFox 3.x and IE7, switching back and forth while using the excellent Stylizer (of which a new version was just released, btw) to make sure the layout works in both. Then creating exceptions for IE6 and Safari as needed. The new fun thing is IE8. Not only is IE8’s “IE7 compatibility mode” not 100% IE7, but the way the browser renders pages also depends on what operating system it’s run on. IE8 in IE7 compatibility mode on Vista looks different than IE8 in IE7 compatibility mode on Windows XP! So, in essence, IE8 introduced four (or more!) new browsers to compensate for!

There is a reason for why Google’s home-page has so simple design: it’s the only way to ensure the page looks the same and doesn’t melt down regardless of what browser on whatever platform is used to view it!

We have long since passed a point where it’s reasonable for an individual web-developer to write a more complex site that reliably looks more or less the same regardless of the browser, or a platform. Different strategies must be adopted to overcome the problem. For one, I’ll be using a back-end browser/platform detection script for all future projects. It’ll make it fairly straightforward and reliable to serve corrective stylesheets that override the defaults in “global.css” for the browsers/platforms that need correcting. Attempting to correct for IE8’s different modes, or Safari’s different versions in JavaScript is enough to drive anyone mad. Perhaps the only good thing about IE8’s arrival is that it will finally force IE6 into obsolescence (I rather take IE8’s shaky modes than IE6!)

I’m also increasingly leaning toward Flex RIAs for most any purpose. With Flex/Flash apps the user either sees the application or doesn’t — and the design will always look the same, regardless of the browser or the platform used to view it.

On the web it’s obviously impossible to enforce regulations for how the browsers should or should not function, but from a developer’s point of view it would be great if the browsers would need to be certified to meet fairly tough W3C compliance standards and anyone using a non-certified browsers would be SOL (and moreover, nobody would scorn at—or be surprised about—the lack of a site’s support for the non-certified browsers).

Workflow discoveries

It’s interesting how, every now and then, I come across some really obvious improvement to my workflow, even though that “fix” has been sitting – literally – under my nose all along. Here’s an example: today I was researching a better way to organize lengthy CSS files in an attempt to decide whether I should mix, in the list, classes and IDs, or separate them categorically as some classes are “localized” to a repeating structure on the page and work alongside a specific ID/IDs.  To this end I was reading through comments for a stop design blog post  “CSS organization tip 1: Flags” and finally reached comment #49 written by “Ridge” about three years ago: »Ah, the joy of a keyboard with a number pad. “/” and “*” are right next to one another. Quick two-finger ‘da-dum’ on the keys, and we’re away…»

Blink.  I’ve always found cumbersome to hit shift-7 shift-‘ (I use Finnish/Swedish layout keyboard) to produce “/*”, and then few moments later the same in reverse to close the comment tag.  And all along – now at least for couple of years – I’ve used a keyboard with a slash and asterisk sitting next to each other atop the number pad.  Ah, so obvious!

As for the CSS organization, I think I’ve decided to create three groups: tag definitions (‘body’, ‘p’, ‘div’, etc.), generic classes (used over and over again around the page/site), and IDs mixed with definitions for classes (e.g. “.someLocallyUsedClass”) and tags (e.g. “.someLocallyUsedClass a”) that only appear in association with the ID such as wrapper content. In the past I’ve divided classes and IDs categorically, only to have to jump around in the CSS file when editing a specific area of the page that utilizes, besides some IDs, one or more local tags or classes.