CSS Hacks, browser updates, and the Holy Grail

CSS Hacks generally work in one of the following ways:

1. Hide CSS that is rendered buggily from the offending browser, using perfectly valid code read by (all) other browsers
2. Feed CSS 'corrections' to a browser that only it needs, exploiting valid, but nonsensical code that all other, standards-compliant browsers will ignore.

In a perfect world, where browsers that correctly parsed valid CSS also correctly rendered 100% of CSS, hacks would be safe.  Hacks are also safe against browsers that are 'dead' (no longer supported or developed).  But dead browsers should eventually die out and disappear, right? Well, they should still be taken into consideration. My simple amateur solution is to hide as much CSS from such browsers as I can (wholesale, using an @import 'shield'). I find it ironic that some 'dead' broswers are more commonly used than new ones, but that's a different matter.

The problem with hacks arises when they backfire. The following conditions could cause hacks to backfire:

1. A browser is updated that correctly renders the CSS, but does NOT parse the code correctly.  This is ok, as the browser is still fed rules that are 'safe', from a design point of view: it's not the full design, but it's a baseline that works.  It worked before, and will continue to do so, unless new rendering bugs have been introduced.  
2. A browser is updated that correctly parses the CSS, but does not fix all the (well-known) rendering problems.  This is problematic and what I would call a 'backfire'.  This is exactly what ppk warned us about back in 2003.

I say all this again because of my frustrations from the following:

• The point of standards is t not have to worry about differences in implementation: a 'standard' should apply to everything that subscribes to it.  This is not the case with CSS, sadly, even 10 years after it's introduction.  
• I want to write CSS code and design layouts that conform to the standards.
• BUT, the single-most popular browser out there remains, unfortunately, Internet Explorer for Windows.  Because it comes conveniently bundled with the most popular operating system for average computer users.  Because most of those users don't know there are better alternatives, and they don't care.  And when they visit a site that looks garbled, they blame the designer, not the browser.  Perhaps they should, at least in part, but it is very frustrating for amateurs who want to put up their own web page, and may even have some neat design ideas, but get frustrated by how difficult it can be to accomplish.

Yes, I am frustrated.  Every time I dip my brain back into this world, I get frustrated by these facts.  I have come to loath Internet Explorer and resent it's simultaneous popularity and bugginess.  I sometimes consider giving up, using a stock design, and not wasting my time worrying about it.  But, I'm stubborn, and a bit of a perfectionist, even when it comes to my hobbies.  "If you can't learn to do something well, learn to enjoy doing it poorly".

All this leads me to my point here.  My usual approach has been to design to standards, use as much clean code as possible (without going mad with testing), and only worry about the most common browsers that I can easily test in: the rest don't get to even see the layout CSS code.  Yes, I use a Mac, because I have yet to find a better alternative that just works (I'm less of a fanatic than I used to be, but I still think it's the best alternative I've seen).  As such, I generally test in Firefox, because I like the de-bugging features it has (DOM tree inspector, better code view, error reporting, etc.).  I also test in Safari, because I actually use that most of the time for browsing, and it's fairly standards compliant, albeit a little idiosyncratic at times.

But eventually, I have to resign myself to test in IEwin (that's Internet Explorer for Windows). *sigh* So, I usually add the 'fixes' to the code to make it work in IEwin, but these are generally corrections that I hide from other browsers using CSS hacks: the star-html hack (and more complex offspring, the 'modified Simplified Box Model hack'), and occasionally the child selector.  The star-html types of hacks follows the second approach I mentioned at the start, while the child selector follows the first.

This used to be safe, until Microsoft started working on IE version 7, and decided to be more standards-compliant.  This is good news.  However, they regretfully decided to fix the parsing behaviour, without fixing the CSS rendering problems.  Now, the hacks may backfire!  gah!  I'm going to take a moment to complain about this decision and respectfully suggest that browser makers follow a few simple rules when updating the browsers:

• Fix the rendering bugs first, then the code-parsing problems.  It's safer to implement something before having multiple ways of triggering it.
• When fixing the code-parsing bugs, add support for CSS declarations before removing support for quirky ones.  The decision to remove IE7's recognition of the star-html selector has caused endless code-rewriting for people who have used this hack.  Adding support for things that weren't recognized before is good and responsible.  Adding support for the child and other selectors allows IE7 to do a bit more: hacks that fall under the first approach above will backfire, but it also opens new possibilities and makes these selectors more broadly useful than a simple browser shield.  This also means the second approach to CSS hacks should be safer (if this rule is followed).  Otherwise, lots of 'corrections' end up rotting in stylesheets and never get to the user agents that need them.  Ideally, removing support for quirky code shoudl be done after fixing the rendering issues first.

Perhaps the best approach after all was to move all IE-related statements to a separate stylesheet and feed it to IE using code in conditional comments.  This makes style-switching a bit more complicated, but rock-solidly reliable for design & walk-away sites.

I admit, I was / am lazy.  I don't have time to test things endlessly, fix, then clean up afterwards.  I'm an amateur, I like doing this in my spare time, and I want simple solutions.  Then again, if it were that easy, lots of professional web designers would be out of work.  But, surely, there must be a place for amateur designers, without having to lose too much sleep or feeling overwhelmed by the miasma of browser incompatibilities.

Perhaps, I should study compatibility tables more often before committing to a certain CSS approach, and only use 'safe' methods, and no hacks.  But that can take a lot of work, and would require changing how I approach CSS coding, and restricting myself to a potentially tiny subset of well-supported methods.  My challenge, and humble request, to the standards-based webdesign gurus, is to spend a little time describing such safe methods, thus pointing out the safe tools for amateurs to play with, without having to face the power tools so early on.  The pros can continue to come up with cool effects and layout tricks, but it sure would be nice to have a stable way to make a 2 or 3 column basic layout.  There are some good columns at A List Apart, which is a start, but there is still much variation, and always the caveats.  It's a start, but

There are a few code-generators out there, but I'm skeptical of them.  Perhaps that's hypocritical, but what I want is something in-between: demonstrations of basic techniques and simple CSS code that works, which I can combine, or add to (not modify, because then it might break).  I wish I could have my cake and eat it.  I want simpler, fewer choices, fewer pitfalls.  Am I asking for too much?

Ideally, a CSS-based layout should only need a few basic, semantic (X)HTML tags.  I don't mind adding semantic divs, but not empty ones or redundant wrapper divs.  A wrapper that contains more than one div might make sense, but that's as far as I'm willing to go.  I don't like layouts that require extra HTML tags for the CSS to play with.  That's leading back towards something analogous to nested tables and resulting tag-soup.  The Holy Grail remains to be able to do everything you need to each box independently, without the need for additional wrapper boxes for the non-standard buggy browsers that force you to restrict the CSS to a tiny subset of the specs.  I've sometimes considered using Javascript to add the DOM elements the CSS relies on, but that's dangerous because then the CSS relies on a piece of JavaScript, whose sole purpose is to support the style.  Not best practices, where content is separate from style and behaviour.