Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.
When we talk about topics such about CSS, JavaScript, and sometimes even certain image formats (png24, I’m looking at you), and how they render in a client’s browser, we always, or should always also consider cross-browser behavior. This behavior entails many things: CSS rendering, the availability of CSS specific attributes, whether or not the DOM interface will be the same, general JavaScript behavior - the list goes on and on. And, since most discussions about CSS and JavaScript (at least the ones that I am having) also concern this variable nature, I’m coining (maybe I’m the first) a new term to put all of this into a handy little phrase, “Cross-Browser Consistency,” or, in typical programmer fashion, simply, “XBC.”
Let’s take a brief moment to establish a more exact meaning for this phrase. As you may well be aware, the industry commonly talks about cross-browser support, so we’ll differentiate between support and consistency, as well as defining what cross-browser really means, and some other tidbits as to boot.
As we all know, the plethora of browsers out there leave some websites in a world of hurt as soon as you access them via an unintended environment. Between Firefox, Safari, Opera, and all the recent incarnations of Internet Explorer, there are a myriad of issues between the different browsers and their rendering results. Usually the discussion is focused on aesthetics and, more specifically, how the CSS may render; however, we should broaden the scope of aesthetics to look at the resolution and operating system too as they all have a hand in the end result. And don’t forget JavaScript! That’s always pushed off to its own thread of discussion, but I think its important that we consider it here. So, when talk about Cross-Browser Consistency, or XBC, we’ll need to be cognizant of two main areas: aesthetics and functionality.
Aesthetics
Browser aesthetics is not simply limited to how HTML and CSS are rendered, the concerns of which have already been discussed at length in various articles and wont be rehashed here. The important issue to realize is that the screen resolution and operating system that a given browser may be running in should also and always be considered as part of aesthetics.
Resolution and scalability
What happens when your site, designed for 1024×786 resolution is squeezed down into 800×600? Or, what about when someone has an even larger resolution, which is more and more common nowadays, like my dual 1680×1050 resolution? I’ll tell you that I’ve seen some funny, very unintended things. And, while these small and large resolutions may be at the extremes of the spectrum, they still entail a portion of your user base. These issues can be handled by designing “out of the box,” which is also known as using a “fluid layout.” We’ll discuss those some other time.
Have you ever considered what would happen if someone had a specific font size enforced via their browser? In some cases, the world would very well explode; however, if we implement our designs in a way that promotes flexible dimensions rather than fixed widths, heights, alignments and so on, we can account for a reasonable amount of font size variance in either direction. Our office standard is such that we allow for at least two font size increases (in Firefox, the hotkey is ctrl/command and +). For example, Yahoo’s home page scales incredibly well.
Operating system
In my experience, browser image scaling and font rendering (particularly for larger text) are the two main operating system-dependent issues that I’ve run into.
When I view a website, and they’ve used CSS or (gasp!) HTML attributes to resize an image, I am almost 110% sure that everything will look good enough for jazz in Mac OS X. However, load that same site in Windows XP or prior, and you’re bound to encounter the unexpected (unless you expected rough edges and other nasties). The difference comes from the two companies’ conflicting philosophies. They both think they’re right, but from a design perspective, I tend to lean toward the more visually appealing of the two, which happens in this case to be OS X.
When it comes to fonts, long story short: it’s better explained by someone else. Joel Spolsky provides an excellent read on the differences between Windows and OS X. One more thing to consider is that in XP (and possibly earlier versions), right out of the box clear type is disabled, and call it a hunch but most users would never know where, how or why to turn it on. Yet, at the risk of being kicked out of the Apple club, I have to say that Vista’s font rendering with ClearType is more readable than OS X. Please don’t shoot me.
Functionality
Libraries
If you’ve done much JavaScript at all, you’ve probably run into a handful of issues with some method existing in one browser and not in another. The first thing to realize is that unless you control the end-user’s client, browser-specific, proprietary methods should never be used. I always opt for the usage of distributed libraries, such as Prototype, jQuery, et cetera to prevent these issues as much as I can. However, it is also the case that the same method will be implemented in two different browsers yet behave differently (e.g.: innerHTML doesn’t on table and related elements in IE, et al), so it is always important to do some testing and research when necessary.
OMG noscript
Essentially, are you prepared to provide the same or similar functionality from the server-side as you have already provided via JavaScript? It is important, at least in non-elitist work, to exclude as little of a potential audience as possible. This means that we, as developers, must make certain allotments for users that don’t have or have disabled JavaScript. Typically, it is my stance that these users either aren’t accustomed to or expecting the bells and whistles of your fantastic JavaScript du jour, so providing similar, perhaps more basic functionality via the server-side language of your choice is acceptable and suggested.
XSLT
Yet another issue to consider is client-side XML/XSL transformations, or more to the point: does the browser support it and will it behave as expected. Normally, I would opt for the XSL transformations to be done on the server as this ensures that the markup you expected to be there . . . is there. Depending upon your server-side language, this has the added benefit of being able to import a namespace of functions from that language to be used in the XSLT as well. A bonus in my book for sure.
Tying it all together
So it didn’t turn out as brief as I intended, but we’ve covered a good bit of information. Cross-Browser Consistency ensures that a site’s presentation and behavior are the same. I’m going to actually be brief now and sumeverything up. Lists are always fun, so lets use one of those.
Cross-Browser Consistency refers to the following:
-
Aesthetics
- CSS support, rendering, and available attributes.
- Resolution, fluid layout, and scalability.
- Operating system rendering of fonts and browser-resized images.
-
Functionality
- Distributed, common libraries are preferred over browser-specific or proprietary libraries and methods.
- Always provide an alternative server-side means of functionality for behaviors implemented in JavaScript.
- XSLT is typically wiser to implement on the server to ensure broader support.
Subscribe by RSS