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.

Author’s note: This article was originally posted at Frye / Wiles, and has been re-posted here for consolidation.

Today, we’re talking about color, its use on the web and how it is (in)effectively rendered cross-browser and cross-platform.When using a flat color as a background, such as is the case with the screen shot of salsa2night below, it is important to realize that if it is blending with an image, that some consideration of cross-browser rendering must be taken into account. Windows displays color differently than Mac, IE displays color differently than Firefox, which displays color differently than Safari–even when rendered on the same machine in the same OS.

Suppose that we have the following CSS declaration for an element on our page that contains an image that should blend in with a background color

#page {
background: #30899E url(image.ext) no-repeat;
}

The problem is not the hex value for the color, the discrepancy is in the value of the background color in the image itself. Here, on XP, Firefox is not agreeing with IE 6 about the image color; however, the CSS color of #30899E is being displayed consistently.

One way around this problem is by using IE conditional comments (which are a saving grace all to themselves, but that’s another topic) to include a style declaration or linked file to fix the background color for IE. These are also extremely useful for fixing other CSS, and sometimes Javascript, issues in IE that are inconsistent with other browsers.

<!--[if IE]>
<link rel="stylesheet" type="text/css" media="screen" title="FW" href="/css/ie/layout.css"></link>
<![endif]-->


or

<!--[if IE]>
<style>
#page {
background-color: #258095 !important;
}
</style>
<![endif]-->


This, however, doesn’t necessarily create a new problem, but does not remedy the entire situation in that it does no good for Safari and other browsers. Another, separate issue is that now you have two places to make modifications to every time you update the image instead of just one, but that’s really a different topic. If you’re market only includes IE or Firefox, then, I suppose, you can wrap it up here. However, when that day comes that you need to support more browsers, what then? In general, web sites aim to reach as big of an audience as available, and should, as part of that goal, strive to provide as consistent an aesthetic experience as possible. Getting down to the point: since there are no Safari, nor for that matter, Opera conditional comments, what are we to do? We’ve fixed things for two out of the four big players in the browser market, but now we need a more general solution that doesn’t involve copious amounts CSS hacks and gimmicks.

That general way of handling this color dilemma is by using web safe colors for the flat colors in images that will be also be painted by a CSS background color such as in the following declaration.

#page {
background: #003366 url(/images/my-image.ext) no-repeat;
}


Design suites worth their salt already have web safe color palettes as part of their color picking tools, so differentiating between safe and potential mis-representable colors should be a snap. The crux of the situation here is that these palettes were chosen and generated mathematically by design-challenged programmers (hey, I can admit it), and not by designers. Complaints of an over abundance of highly saturated colors and not enough of a selection of muted colors are common.

Adapting oneself to design within these color constraints is somewhat note-worthy, but not necessary. Enter method three: break it twice.

The general idea here is to have two images: the image that we’ve been dealing with all along, and another, 1×1 px, that is filled with the background color that we want to fill the area with that we had been originally using a CSS hex value for. The basic idea here is to have to div elements, on within the other. The outer div, page-background, will contain the 1×1 px image have it tile (repeat) in the X and Y directions. The inner div, page, will contain the main image as it always has, except that it will have no background color defined with it.

<style>
#page-background {
background: url(/images/my-image-background.ext);
}
#page {
background: url(/images/my-image.ext) no-repeat;
}
</style>
<div id="page-background">
<div id="page"></div>
</div>


Of course, height and width must be set on the page element to fit my-image and whatever content is to be included, but this is the general idea. This works because of one reason: we’re exploiting the inconsistency in the rendering of each image. If each of these images contain the same palette, then they will be rendered the same. Again, instead of using a CSS color value, we’re tiling a very small image that contains that color under the main image so that everything is displayed the same in all browsers.

Each of these methods for addressing the image color issue has their own draw backs: the conditional comments only work in IE and force a division of code that has to be updated in two places; the web safe color palette is limiting factor on design; and the final, break it twice solution has the overhead of an additional image, albeit small, as well as the extra mark-up needed to stylize and include the extra div element, which is, again, small but there nonetheless.

Of all of these, I prefer the use of web safe colors as it is definitely superior as far as implementation is concerned; however, when push comes to shove, using the twice broken or break it twice method will get the job done and can be, theoretically, guaranteed to work in all browsers, forever and ever, amen.