anyone know richard york who wrote a book on style sheet. where is he now ?

Exactly what I was thinking. I think that everyone should be using conditional comments to target IE and the remainder of CSS hacks should be for browsers such as IE 5 Mac.

One more thing: the second sentence of the third paragraph should begin with “In particular”.

-Chase

The thing with conditional comments is this:

Absolutely fine if the document is served as text/html. Although you will have to keep track of additional css-files.

If the document is served as XML, the conditional comments produce parser errors (Yes. It’s still a proprietary technique from MS).

And imho a hack is not a hack. Using the standard implementation of CSS to feed different styles to different browsers is perfectly good (e.g. the child selector).

The ’* html’-hack in fact is a nonsense rule. Correctly interpreted it can’t apply to any element.

And for anyone who is interested in CSS-hacks/-filters should read this article: Pandora’s Box (Model) of CSS Hacks And Other Good Intentions [by Tantek Celik]

So we have changed:

To:

In both cases IE7 will get { margin-top:0; } (it won’t parse * html, but it will understand child selector).

Do I miss something or there’s no difference?

@Nick: “Real” browsers. I’ll be laughing about that one for a long time.

The point of targeting browsers is really only a question of targeting bugs in their engines.. while it’s hopefully true that “someday all browsers will be standards-based”, the occasional bug must slip through.. sometimes these bugs ruin a design, and must be worked-around as there is no alternative method that provides correct results.

The bottom line is that the child selector hack this article advocates is still a hack; it’s perfectly valid, but so is the star-html hack. Use whichever causes you the least frustration at the time, and will prevent a maintenance nightmare. One of my peers only uses the child selector hack, and I recently noticed that by using the star-html instead his stylesheet was less than half of it’s original size.

I still remain unconvinced that one of these two hacks is better then the other in a general sense. Even if IE7 is released and fixes these bugs, we’ll still have to support IE5 and IE6 for quite some time. In this context the star-html hack would no longer “violate” Tantek’s second rule. Just understand how each hack works and use it appropriately.. try to keep your CSS size down, and use the right tool for the job.

Excellent, that certainly beats the other two hands down. But how does it compair with using conditional comments?

I was wondering the same thing myself: what about conditional comments?

Not to beat a dead horse but I have the same question what about the conditional comments? Will be interesting to see if it does indeed future proof it for ie7.

I thought about conditional comments when I started reading this, but knowing the three simple rules in CSS hacks is good enough for me.

You don’t need conditional comments to write a good hack.

A hack is a hack, chances are that IE7 will have it’s share of bugs, and then our little hacks will do us no good.

Conditional comments are the way of the future. I try to use it on evry big site. Would never sell a webpage page with hacks. During testing I use hacks ofcource.

What future UAs does the Star hack target? I’m sure the IE7 team specifically said they’re removing it. Therefore I see it as valid as the child selector “work-around”.

The IE team said conditional elements as the best way of targetting that browser, why not use them? We can easily target any version we want?

I don’t think removing or changing these hacks will affect how IE7 handles, IF the browser supports what they say it will.

If they fix the CSS support so it’s more like Firefox or Safari, then remove the hacks, then 1) it won’t get the hack rules 2) it’ll correctly apply the correct rules. And everyone is happy.

Saying that, though, is a big IF. Conditional elements are “officially” supported by IE, so why not use them. My ownly arguement is that it requires extra MARKUP…

The star hack is an interpretation error.

The child selector is a feature of CSS.

Conditional comments requires extra markup too.

Your sollution violates Tantek’s third rule. It should be ugly. It just isn’t, although you could argue that it ain’t a hack.

I’m not convinced this is the right way to do things. The method you suggest will not only target IE but also Netscape 4 and ICab 2 and any future browser that doesn’t fully implement the CSS spec. (which is very likely as we seen in the past)

the ’* html’ hack is way more future proof and only targets IE.

IE7 won’t ‘support’ it and I wouldn’t call IE6 a ‘current browser’ like you do.

I’ll just continue using my * html :-)

hmmm…how does the star hack violate the second rule? discuss…

The underscore hack is valid. The validator is broken. The underscore hack is brilliant for one very important reason: it keeps your hacks simple and grouped with the property being replaced. Therefore, it’s easier to go back in the future and remove or change them if needed.

Child selectors are great, but they’re backwards from what we actually need: styles that only apply to IE for Windows, because it’s the one that’s broken. Creating new selectors somewhere after the original is hard to maintain because the hacks are no longer grouped by what’s being overridden.

Other than that, awesome article!

“hmmm…how does the star hack violate the second rule? discuss…”

According to Tantek it does, because IE6 is a current UA. I personally think it’s a valid hack because it’s targetting a pretty obtuse interpretation problem found only in IE6-, where the pattern of selectors is made valid by IE’s understanding that there is a mystery parent element of html in the DOM.

If there was a reasonable expectation that this wrong interpretation will be implemented into a new browser then it would definately be a bad idea for a hack. Considering that at the moment it’s an IE only thing, and that the fix in IE7 means the * html slectors won’t match and therefor won’t be rendered, I don’t see a problem.

However, conditional comments are the way to go. Why put hacks in a clean master stylesheet when they can be seperated out and place in stylesheets that can target specific versions of IE? And they can be used in XML/XSL without parsing errors, you just need to CDATA and a couple of encoded characters for < and >.

Patrick, I’ve asked on several sites what the deal with * html is. I see it as a hack which is guaranteed to target IE5.x and 6.x only, so I write clean code and use it as an override to correct bugs found in only those browsers.

And Matt, to answer your question, it means maintaining multiple stylesheets. I find it much easier to have one stylesheet where the IE corrections are right with my original style declarations (using * html).

“According to Tantek it does, because IE6 is a current UA”

If the * hack violates the 2nd rule because IE 6 is current, by the time IE 7 comes around (and we have to worry) will IE 6 be counted as outdated and the * hack cease to violate the 2nd rule?

@Johan:

Conditional comments work perfectly even when serving application/xml. Since they are valid comments they shouldn’t produce any parsing errors (look at my homepage – I am using conditional comments).

@all:

But there’s another problem with conditional comments: It’s not possible to combine them (at least not in a clever way).

So if I want to hide any CSS from IE < 5, serve one specific CSS to IE >= 5 and IE < 7 and another specific CSS to IE >= 7 I run into big problems… But maybe someone knows a solution to this.

Greetings.

This article advocates using “html >” to target most non-IE browsers, instead of ”* html” to target IE 6-. It’s no worse, but is it any better? I’ll need a better reason than “because tantek says so” to banish * html from my code.

It’s simple. It works. Why change it?

PS: “Why not use coditional comments?” Because I’d have to clutter up every page of my site with them, rather than keeping all my if-this-browser-do-this code in one place.

Hacking. Unhacking. Forking code. Wow, I came here for a way to impress my friends but no one can decide the best way to do it. I’m all for not having to use hacks. At the same time I would rather not fork my css either. I can just imagine…

This stylesheet for this browser and this one for that and so and so on. Forking might be easier on a small site and hacks could be good for larger. Its up to the browser developers. Everythings gonna change next year anyways, then we will all be having this same discussion. See you all soon and thank you Kimberley for a great idea and stirring things up a bit. :’)

If you’re going to fork your code (I just love that expression, thanks) do so only in general/global terms. Layout properties, for instance. I use conditional comments to load an IE specific stylesheet that sets height and width, since these behave in the same way as their min-equivalents in browsers that implement CSS correctly.

@Chris Hunt: I’m not sure I follow your P.S. objection to conditional comments (CCs).

I use a standard stylesheet which works for real browsers, and a second stylesheet containing IE-specific fixes. The IE-fixup stylesheet is hauled in using a link element inside a CC, to save real browsers the trouble of downloading it.

The CC adds exactly 32 characters (including whitespace) to each page, which is hardly “cluttering”, given that the link element necessary to bring in the fixup stylesheet is already 48 characters plus the length of the value of the href attribute. And all my fixes remain in one place.

I’ve never ‘hacked’ css, only ever used the child selectors to override IE attributes with Firefox ones.

eg

#header{margin:3px 0 5px 10px;}

html>body #header{margin-top:5px;}

1st is IE, 2nd Firefox.

If IE7 supports child selectors, it looks like I’m in > trouble.

I feel the star-html hack and child selector hacks are both legitimate: one hides CSS from IE, the other hides it from pretty much all browsers but IE. Typically, you want the choice that reduces the amount of CSS you are “over riding”, and requires the least maintenance.

The risk here is that IE7 introduces problems but no way to “hack” around them. If the star-html hack is fixed and most selectors are implemented, we’ll probably need horrible, inaccurate hacks or conditional comments.

If CSS blocks had their own conditional comments, I’d use them. But having to introduce more markup is tedious, introducing a level of separation for what is often one or two hacks on an entire page. Instead of reducing maintenance requirements I’ve found c.comments increase them, especially on small sites.

This is why I wish the W3C would create a standard extension to media queries to let us just target specific versions of engines.

What about IE epecific dynamic properties in CSS?

I have some ideas how to use it to serve IE specific style: just use proper standard CSS and apply all IE-spec stuff in expression() —only IE will see it. But I still need to explore this technique…

What is the point of targeting all browsers with hacks? It leeds us into problems in future. Keeping with standards and pushing browse makers to support standards is the only right way ahead. Tommorow all browsers will be standards based and our current css will bother them.

Thanks so much for sharing. It works great and is far cleaner than the other two methods.

The Holly Hack solves a multitude of IE’s more annoying bugs. Does anyone see a problem with putting the following in ALL your CSS as the first item:

I think this works, although I’ve never tried it.