Acceptable CSS hacks/fixes

Question

Is there a list of 'good' clean CSS hacks, which are certain to be future-proof?

For example, zoom:1 is safe, as long as it's only served to IE, and you remember it's there. The very common hack of using child selectors is not safe because IE7 supports them. Using height:1% just feels dirty (but that might just be me).

I know of ie7-js, so IE6 bugs don't worry me much. Also, I'm not looking for a religious debate, just sources.

---

Thanks for the replies - I've selected the one with best sources as answer.

Thanks also for the suggestions to use separate CSS files, or not to worry about it. I entirely agree with you, and for me, those are givens. But when faced with a layout problem, I want a safe fix that will minimise the risk that I'll have to revisit the problem in $IE or $FF + 1. Sorry I didn't make that clearer.

Answer 1

When defining rules, I find it good to allow natural degradation take place, for instance, in CSS3 there is support for RGBA Colour models, but there isn't in CSS2, so I find myself doing:

 background-color: #FF0000; 
 background-color: rgba( 255,0,0, 50% );

So that when the later rule fails on older browsers which don't support it, it will degrade to the previously defined style.

Answer 2

Centricle has a good list of CSS hacks and their compatibilities.

I don't think you'll find a list of hacks that will be future proof, as know one can tell what stupid thing will be implemented in IE next.

Answer 3

Modifying your CSS for browser-specific support is never wrong - as long as you can easily contain it. As you'll notice, standards-compliant browsers, * cough * everything except MSIE, will never break with future releases. New W3C standards also don't break previous standards, they usually deprecate or extend previous standards at the most.

People have mentioned conditional comments which are great for handling IE. But you'll need a bit more for handling all browsers (mobile, gecko, webkit, opera, etc.). Usually you'll parse the incoming request headers to fetch the browser type and version from the User-Agent param. Based on that you can begin loading your CSS files.

I belive the way most of us do it is by:

• First developing for one standards-compliant browser (let's take FF for example)
• Once the CSS is complete you approach providig support for IE (this can be easily done with the conditional comments, as perviously mentioned)
  • First create a CSS file that will fine tune everything for IE6 and any other version below
  • Then create a CSS file that will handle everything for IE7
  • Lastly, create a CSS file that will handle everything for IE versions of IE8 and greater
    • Once IE9 comes out, make sure you set IE8+ handling to IE8 specific, and create a IE9+ CSS file with required fixes
• Finally, create an additional CSS file for webkit fixes
  • If required, you can also create additional files to specifically target Chrome or Safari if required

Concerning browser specific CSS implementations, I usually group all of those in my main css file (you can easily do a search for those and replace them in one document if needed). So if something has to be transparent, I'd set both opacity and filters (MSIE) in the same block. Browsers just ignore implementations they don't support, so your safe. Specific implementations I'd tend to avoid are custom implementations (hey, I like the -moz box above the W3C one, but I just don't want to rely on it).

As it goes with CSS inheritance and overriding, you don't have to redefine all the CSS declarations and definitions in every CSS file. Each consecutively loaded CSS file should only contain the selector and specific definitions required for the fix, and nothing else.

What you end up with in the end is your (huge) main css file and others, containing a few lines each, for specific browser fixes - which sums up to something that's not that very hard to maintain and keep track of. It's a personal preference what browser your base css file will be based off, but usually you'll be targeting a browser that will create the least amount of issues for other browsers (so yes, developing for IE6 would be a very poor decision at that point).

As always, following good practices and being pragmatic and meticulous with selectors and specifics about each class and using frameworks will lead you down the path of goodness with seldom fixes required. Structuring your CSS files is a huge plus unless you want to end up with an unordered meaningless mess.

Answer 4

This is a good place for well-documented and well-tested browser bugs and the hacks allow you to work around them:

http://www.positioniseverything.net/

Answer 5

There's no such thing as a good clean/acceptable [css] hack - always code to Standards, and then use browser+version specific stylesheets for any hacks required to make things work.

For example:
default.css
default.ie6-fix.css
default.ie7-fix.css
default.ff2-fix.css
etc

Then, when new version of a browser are released, copy the previous version's hacks and remove the bits that no longer apply (and add new bits, if necessary).

(Load individual stylesheets using Conditional Comments for IE, and user-agent sniffing for other browsers.)

Answer 6

Underscore-hack for IE6-stuff works quite well, eg.

min-height:50px;
_height:50px;

It doesn't require moving things out of context into new css-files, only IE6 gets them and they're easy to filter out if you should decide to stop supporting IE6. They're also very minimal and won't clutter your CSS that much.