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.
Yes, but is it valid?
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.
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.
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.
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.
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.
@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.
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? ;-)
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?
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.
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 :)
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.
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.
Yes, I totally agree with the Invalid hacks are invalid, and that's bad.
statement.
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.
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.