views:

815

answers:

13

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.

+4  A: 

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/

Andrew Hare
+1  A: 

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.

svinto
The underscore prefix is not valid CSS, so not in any way safe. Use the "* html" hack for IE6.
bobince
the min- or max- values should be added first, then override with the _height or _width values... this will allow you to set a min/max, then hardcode a value that best handles IE6's lack of min/max.
scunliffe
+10  A: 

For the majority of IE bugs I think you're best of using conditional comments around a link to a browser specific stylesheet. It tends to keep things pretty neat and it's quite self documenting.

slashnick
+4  A: 

I've used Peter-Paul Koch's "QuirksMode" website a lot for issues involving CSS and cross-browser compatibility. He tends to frown on browser-specific methods, but he does have a page on CSS Hacks.

Jason S
Yes, I use his site religiously, because it's better to avoid problems in the first place. I like his take on CSS Hacks especially (strangely I've never read it before).
Mark
+2  A: 

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.)

Peter Boughton
(And although this isn't really a direct answer to what was asked, I'd still say it's a valid answer)
Peter Boughton
I agree; this is an acceptable answer as the question's premise invalidly assumes that acceptable hacks exist.
jacobangel
But you're relying on browser sniffing to do that.
Nosredna
There are reliable ways to detect browsers, especially using IE Conditionals. If you need extra style sheets for a ton of non IE browsers you are doing it wrong...
jacobangel
The problem I have with this is that it leads to a proliferation of layout-shifting fixes, making debugging and testing harder. It's also obvious that just writing valid CSS is not enough on its own. Still, totally agree it's a valid answer.
Mark
A: 

My Best choices:
Either updated commercial software like dreamweaver.

or

Sticking to only 2 divs inside any given div. Limiting use of padding and margins.

Never had any layout problems like that.

mvrak
+1  A: 

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.

kRON
Standards-compliant browsers can break in future releases, when there are bugs or other regressions, especially in little-used features. I've run into this a lot and really wish all browsers supported conditional comments.
Mr. Shiny and New
I've limited myself solely to CSS parsing. You shouldn't notice a difference in rendering on a release version of FF X when compared to a release version of FF Y, in regards to CSS. As far as I know, W3C have never introduced any CSS regressions, although I could be wrong.
kRON
+3  A: 

Nicole Sullivan (AKA Stubbornella) who works for the Yahoo Performance team suggested in The 7 Habits for Exceptional Perf that you should use the CSS underscore hack to patch up IE6 bugs because:

  • Hacks should be few and far between.
  • If you will only have 5-6 hacks (which is already plenty) then it would not make sense placing those in an external file and thereby separating it from its context.
  • An extra file would lead to performance penalties (Yahoo Best Practices, Rule 1).

It should however be noted that this is not valid CSS.

Andy
+1 validity is a secondary concern when the consequences are trivial - fwiw, I believe decontexting and increasing requests is non-trivial
annakata
A: 

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.

Kent Fredric
A: 

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.

Mark Davidson
It was actually the Centricle table that inspired me. Every one of those techniques is a timebomb, relying on the fact that *an unrelated* parsing bug allows you to make directed changes.
Mark
A: 

I prefer the global conditional comment technique described by Hiroki Chalfant;

I find it helpful to keep my IE-targeted rules side-by-side with my standards-targeted rules in a single valid stylesheet.

David Alpert
Nice, and quite self documenting. However, it's not always nice or even practical to let bugs dictate your page layout, and I don't like the recommendation of using > to target other browsers.
Mark
i don't let bugs dictate my layout; i design for standards and use conditional comments to feed IE-version-specific overrides where IE falls down on compliance. e.g. #someElement {someRule} ... #ie6 #someElement {someRule-overridden-for-ie-6}
David Alpert
Sorry, I meant that I don't like the fact that IE will have a different document tree.
Mark
A: 

This article will tell you how to use hacks for ie6, ie7, firefox, chrome, safari and opera... Web browser hacks

Webdevelopertut
A: 

This article is a good summary of CSS hacks: http://www.webdevout.net/css-hacks

Paul D. Waite