Anne van Kesteren

Implement CSS 2.1

Tantek Çelik points out the obvious in Pandora’s Box (Model) of CSS Hacks And Other Good Intentions: CSS2(.1) doesn’t say you can implement part of the spec. You’re supposed to implement the whole spec in the first place.

It surprises me though that he does not take this post to its logical conclusion. Namely that using hacks like _height, * html et cetera is ok as well. Why? Because user agents implementing CSS 2.1 completely would ignore such rules in the first place and only use the rules targetted at a CSS 2.1 compliant browser.


  1. Yes, but is it valid?

    Posted by Mark Wubben at

  2. I think * html is ok now that we know it won't be supported in IE7 (standards mode), so it can safely be used to target IE6 and below and it's also valid. The underscore hack isn't valid and is usually not necessary. I've only ever found one case where * html couldn't possibly be used instead, but most of the time it's all I need.

    Posted by Lachlan Hunt at

  3. Tantek suggests that a hack should be both valid and ugly. While I obviously agree with the "ugly" part, I don't see why a hack should be valid (or perhaps only pass muster at the W3C validator?). What better kind of ugly than invalid?

    CSS2.1 has clearly defined error recovery, so what difference does it make, really? Okay, you can't claim that your stylesheet is valid, but if your stylesheet intentionally does strange things that wouldn't immediately be obvious in some agents, isn't that walking the line anyway?

    Maybe it's just been too long since I've had my head buried in this stuff.

    Posted by J. King at

  4. Well, that was actually my point J. Error handling is defined. Implement all of CSS 2.1 and you can cope with all style sheets (in a proper way, blah blah blah). Hacks or no hacks.

    Posted by Anne at

  5. Let us apply Tantek's MUSTS for CSS-targeted hacks on

    <!--[if IE lt 7]>

    ! This is a valid, but not ugly and not old UA targeted hack.

    Posted by leif halvard silli at

  6. Interestingly enough Leif's blockquote causes Safari to act funky: when the page is first loaded (or reloaded through cmd+r) parsing of the body will stop after the paragraph is opened, but it works normally if you go to the address bar and hit enter.

    Posted by Mark Wubben at

  7. @Mark: Yeah, that’s weird behaviour: My Safari copy (1.3.1) displays hacks on and then, leaving out the blockquote and everything else, continues with Mark’s post, indented as subsection of Leif’s, numbered as 1.! (no matter if reloaded or re-entered)

    Anne’s comment section is hotter than acid! :)

    It’s not the blockquote, it’s the comment: Safari doesn’t eliminate the <!, FF does.

    Posted by Florian at

  8. Florian, yeah, you're right. I actually meant the content of the blockquote, but yeah, it's the comment. Oddly enough in NetNewsWire now (uses WebCore) I had to go to another page on the site, and then back through history, and then "re-enter" to display the post. And commenting of course didn't work either (rewriting in Firefox now).

    Anne, wanna make a test case? ;-)

    Posted by Mark Wubben at

  9. Nah, pretty normal: Leif didn’t escape his brackets and has just commented himself out. (Opera and IE5Mac behave similar, they cut off after hacks on, but leave out the nested-ol-Safari-thingy.) Who expects commenters to comment?

    Posted by Florian at

  10. Well, the spec says that these hacks should be ignored, but that doesn't make them compliant, right? As in society, ignoring doesn't mean accepting, it's just some form of politeness.

    Posted by Jens Meiert at

  11. And now I'm getting the nested ol thing as well (after navigate-to-another-page-back-in-history-re-enter). This is too weird. I'll stop now :)

    Posted by Mark Wubben at

  12. Actually no, it is required error handling. Which makes it completely fine to do it. Your style sheet is just not conforming to the letter of the CSS 2.1 specification. But since you included opacity, text-shadow, box-sizing and several other properties it does not matter anyway. The thing is that if browsers support CSS 2.1 fully they must do something specified with _height:1%; dropping the declaration.

    All the Apple people please move to OpenDarwin Bugzilla. I can’t help it that your browser has parsing/display problems.

    Posted by Anne at

  13. Pages shouldn't violate the standards just like UAs shouldn't violate the standards. Invalid hacks are invalid, and that's bad.

    One reason for defining error handling is that in the future we can add new features where the errors are no longer errors, and we can be sure that UAs will handle them all the same way, making it easy to ensure backwards compatibility.

    For example, we might say that "_height: 10em;" means something special, like, "apply this rule except if another one matches as well" or something. And then all the pages that rely on that hack would break in new browsers.

    Posted by Ian Hickson at

  14. Yes, I totally agree with the Invalid hacks are invalid, and that's bad. statement.

    Posted by Robert Wellock at

  15. Ian: That'd mean that * html would be valid, right?

    I remember reading something about how somehow it's still implied that the html-tag is a child of the whole...or something like that.

    Posted by James / AkaXakA at

  16. Thank you for this post Anne. I' feeling confused about being the only one thinking that the star html selector is just as "forward compliant" in this context as the html>body selector.

    Posted by manuel razzari at