“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 >.
Matt G
“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 >.