additions… #42

…web design…

browser targeting CSS hacks…

I validate the stylesheets behind this site from time to time, to make sure I haven't left any mistakes in there. Since I'm modifying styles quite often, the chance of introducing a potentially fatal error through a typo or missing curly brace or something, is always present. The “human bug” strikes when least expected, you know.

Although the source-code (html) behind this document is in accordance with the declared doctype, a validity check of my stylesheets will reveal the most horrendous mix of parse errors and generally non-valid code. The number is drastically reduced when validity is checked at CSS3 level, but it's still a high number of errors.

Apart from the occasional vendor-specific extensions I have used when there are no other options, and a few cases where the CSS validator gets it positively wrong, there should be no errors in the regular stylesheets. All errors should be found in stylesheets I use to test browsers' progress in CSS support and compliance, as that's where I put all the questionable and/or non-valid stuff.

an entire site as test-bed…

Two separate test-stylesheets are “hooked up” to nearly all pages on this site. One is permanently @imported into the regular stylesheets, while the other is linked in on most pages individually. The entire site thereby becomes a test-bed for browsers' CSS support, with the results presented in clear view.

These test-styles don't interfere with the regular page-layout or introduce browser-specific modifications to it. So, from the regular visitor's point of view they do “absolutely nothing”. Yet, anyone who knows what to look for will immediately see clear signs of specific-browser targeting, and they will see whether the outcome makes sense or not.

These two stylesheets contain some of my latest findings for each browser's CSS support, as it grows from version to version. They also contain the latest about how I can target the various versions of each browser-engine – if such targeting ever becomes necessary.

For the interested: here are the two test-stylesheets…

…but be warned: these test-hacks are not for serious use. If web coders use them to modify layout on regular sites, and are unable to keep them updated as new browser versions arrive, they'll soon be in deep trouble.

Now that I'm through with the obligatory warning not to use CSS hacks on “live” browsers, it's time to see what these test-stylesheets actually do to this page.

what to look for…

Unless you have a very strange high-light/low contrast setting of your screens, you should see a faint logo resembling a watermark in the page-background along the right side of this text-area. That logo should hint at the browser you're using – or rather the main browser running on that particular rendering engine.

For some older browsers there won't be a watermark, simply because they don't support the fixed background positioning necessary to apply one. This goes for IE6 and older, and the lack of a watermark means I've gotten it right.

No big deal if I've gotten it wrong though, as a watermark should be nearly invisible anyway. I think I've managed to make them all faint and unobtrusive enough if one does show up. I like undisturbed surfaces on web pages.

Near the top of the right column you should see the “CSS Sledgehammer” image. Ideally you should see a cat chasing your browser under that hammer. For some browsers I'll only get the rendering engine right, with or without indication of version.

Some of the version indications I use are a bit cryptic, as figuring out exact engine version for an obscure browser is less important than to determine how far behind the lead browser running on that engine it's lagging. Getting the version-lag somewhat right is good enough in 99.9% of the cases, so I often just interpolate between major engine versions and ignore the finer details.

vendor specific CSS extensions…

To return to the horrendous CSS in those test-stylesheets: there are some vendor specific CSS extensions in them, which of course are reported as errors. No surprise there, and such extensions are responsible for a large number of the reported errors.

Vendor specific CSS extensions are pretty efficient “tools” when one needs to separate one browser-engine from all the others and perform extensive tests on it. Some of these extensions actually prevent the CSS validator from checking what's inside certain style-blocks, and the report might have looked even worse if it could.

To find these vendor specific CSS extensions I've dug into quite a few browser default stylesheets, in those browsers that have them nicely lined up in folders when they're downloaded onto my machines. Some browser stylesheets are also made available by others.

Strangely enough: although vendor specific CSS extensions obviously should only work in one rendering engine, some may pass in other rendering engines too. Thus, thorough testing up and down various engine versions is necessary to avoid “accidents”, before they're used in regular stylesheets where all browsers can have a go at them.

CSS selectors…

There are also some pretty goofy and to some degree nonsensical selector chains in there. These are the results of the real CSS support tests, where engine-versions and variants are tracked over time.

Most selectors are valid and used in valid ways, or their valid/non-valid use is undefined or underdefined on one or more CSS levels. Others are by definition non-valid from CSS3 all the way back to CSS1, but found to work in particular browsers.

Some valid CSS selectors and rules are reported as non-valid by the CSS validator, simply because the validator isn't on level with the relevant CSS specifications yet. For instance: media queries have not reached the status of “recommended” yet, despite the fact that several browsers have supported parts of media queries for years.

In such cases I have to keep a sharp eye on the specifications, and make sure I keep my own styles in line with them. Meanwhile I just have to ignore the CSS validator's error reports, and wait for it to catch up with the relevant specifications, and me.

tracking progress…

Our progress as web developers is closely linked to the progress in web standards support across browser-land, so we better know what level each of the browsers is at at any given time. Otherwise we obviously can't make use of whatever progress there is, and may end up lagging behind and be limited to using old and outdated methods and spread equally outdated information to others.

The spread of bad information is actually worse than having ones own creations crippled by bad code. Sloppy code on one site is one thing, but actively spreading it as “solutions” to other sites is of course much, much, worse.

There's so much outdated, incomplete and/or plain wrong information on anything floating around on the web, so one better perform ones own in-depth testing when it comes to actual CSS support and other aspects of browsers' support for web standards. Trusting others to provide accurate and complete information may not be the smartest approach for a somewhat bright web developer, and is also totally unnecessary since we all mostly have access to the same browsers and can perform our own tests on them.

One should only hack dead browsers for real, but it is important to keep track of progress in those browsers that are very much alive – constantly worked on, and where new versions with new features and improved support for web standards are released somewhat frequently.

While in the process of performing our own tests across browser-land, we can borrow bits and pieces of information and code from others as long as we run them through complete tests to make sure they got it right. Sometimes they do, and building on their work may save us some time


I never adapt anything untested, and I always perform my own, thorough, tests before releasing anything. Even then my tests may of course be inadequate in some cases, simply because I too only test for the parts I need at the time. Thus, all of my information and code is released as is, and should be put through further tests before adaptation.

As mentioned elsewhere: the only browsers I'm hacking for real are IE/win and IE/Mac, as those dead browsers simply wouldn't be able to render much of anything without a lot of help. IE7 and older are given their very own, hidden, stylesheets, so most of the hacks used to fix them won't show up in the CSS validator.

sincerely  georg; sign

Hageland 06.dec.2008
08.dec.2008 - regular revision.
31.dec.2008 - added “not to use CSS hacks” link.
10.may.2012 - updated csshammer and page-bgnd CSS for Opera 11/12+.
27.feb.2013 - updated csshammer and page-bgnd CSS for IE10.
last rev: 27.feb.2012


One should only hack dead browsers, but it is important to test the progress of the living.
— Georg

addition to:

…2008 - 2013