Re: CSS comment hacks (was: small errors in the CSS2.1 grammar)

> On 1/16/03 5:15 AM, "Lars Knoll" <lars@trolltech.com> wrote:
> Your example is flawed because the equivalent of what I was proposing would
> be more like (to continue the JavaScript analogy):
>
> if(isIE) {
>   // do something
> } else if(isNS4) {
>   // do something else
> } else {
>   // do some something DOM-compliant that 'should' work in any browser
> }
>
> But it's still not quite the same. I'll continue.

No. Believe me, there are web designers out there that don't include a generic 
else. I've seen it a few times. Sure, that's broken, but as long as web 
designers see the need for browser specific hacks, (and people advertise 
these), small and new browsers have almost no chance at all of rendering all 
web pages out there (except for faking user agents).

> > Sorry? Even with the old parser khtml parsed well formed CSS2 selectors.
>
> What about this one? It doesn't work in Safari. Not sure about the current
> version you're working on.
>
> [attribute="value"] { property:value; }

You're right. This one doesn't work in the old code, but *[attribute="value"] 
does. It should work just fine in the new parser.

> You're right that 'most' of the CSS2 selectors work though. Modifying the
> above example to this WILL work.
>
> tag[attribute="value"] { property:value; }
>
> As far as I know, both are well formed. There are some other examples of
> non-working CSS2 selectors I've found but I don't remember them offhand.
>
> > CSS comment hacks are by now way standards compliant. Yes, there are
> > differences in implementation, but if you forget about NS4 (where you
> > don't need a comment hack to exclude it from getting CSS rules), you can
> > write CSS that works on all recent browsers.
>
> And why aren't they standards-compliant? I know it's not 'recommended' and
> you're right that it's harder to read if you don't use real comments in
> addition to the comment hacks, but it is completely standards-compliant.

Yes, you can say that the CSS you write is standards compliant, but you rely 
on non standard bugs in the implementations.

> Bear with me. I'll explain.
>
> Say you had a section of CSS like:
>
> #navigation {
>   color:#000;
>   background-color:#ffc;
>   }
> /* Mac IE5 comment hack \*/
> #navigation {
>   color:#000;
>   background-color:#cff;
>   }
> /* end Mac IE5 comment hack */
>
> Now, ignoring the comments, both rules are of the same importance according
> to the rules of specificity. Correct? So since the 'medium' is defined
> last, it takes precedence and will display on all browsers that read the
> second rule; according to standards.
>
> Just because one browser doesn't read that rule doesn't mean that the CSS
> is no longer standards-compliant. It still validates as two rules and two
> comments. Now assuming that MacIE6 came out and fixed the reason you would
> need the comment hack it would also be 'assumed' that they would fix the
> CSS parser and would therefore no longer read or need the hack.
> 'Assuming'... Of course it's an imperfect world. ;)

This connection is IMO wrong. Just because they fix one bug in their 
implementation doesn't imply they fix the other one. They could fix the bug 
in the parser without fixing the bug in the rendering engine that brought you 
to using the hack or the other way round.

Lars

Received on Friday, 17 January 2003 02:05:19 UTC