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:
> 
> The most I could maybe be conviced to do is add some standards conform way of
> enabling rules only for khtml. Something along the lines of
> 
> @media khtml-specific {
> /* insert khtml specific rules here */
> }

You're right. That's an infintely better solution.

> Even here I think this is a bad idea. In javascript we've seen similar
> problems happen (this is from a real web page):
> 
> if ( isNS ) {
> // do something
> } else if ( isIE ) {
> // different way of doing the same thing
> }
> 
> Now guess what happened with konqueror (where isIE and isNS where both false).
> The site broke completely even though konqueror would have been able to
> correctly interpret both the NS and IE javascript sniplet. Using some sort of
> mechanism like the above one would make the same happen for CSS. Smaller
> browsers some web designer don't test for will break because they get
> unstyled contents.

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.

> 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 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.

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. ;)

Either way, ignoring the parser bugs, the rules of specificity ensure a
standards-compliant rendering on standards-compliant browsers. What other
browsers read is beneficial to me as a practical developer. I don't use
many, but I'd much rather put a few extra lines in my CSS that add a bunch
of non-semantic HTML. It's more important that the data be ultra clean.

Later,
James

PS. I used the MacIE5 hack merely as an example. I could have used some
other hack on a different browser and I'm making no claims as the the
'superiority' of one browser or parser versus another.

Received on Thursday, 16 January 2003 17:24:06 UTC