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

> On 1/15/03 10:08 AM, "Lars Knoll" <> wrote:
> > My version of flex doesn't seem to handle the comment specification
> > correctly (the end of comments as eg "/***/" are not recognised for some
> > reason), although the expression looks correct to me:
> I may be blaspheming this list, but I'd request that you document it and
> leave it that way. Browser-specific CSS comment hacks have become essential
> in correct cross-browser display of CSS-P while still retaining standards
> compliance.

You can't be serious about this. I'm sorry, but this is not the way to do it. 
khtml has been criticised for it's CSS parser not being standards conform, 
and they were right to do so. I'm going to make the parser as standards 
conform as possible.

These CSS comment hacks are just a bad way of doing some browser detection 
client side. They go completely against what standards are supposed to be for 
and what I believe in. If you follow this line of thought, you'll end up in 
some nightmare that is as bad or worse than the situation we have with HTML 

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 */
and recognise this media type on HTML link elements. 

Everything else is just ugly, makes CS unreadable and my life as someone 
implementing a rendering engine hell. 

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. 

We (khtml) has been in the situation of the underdog for years, and had to 
deal with such stupidities from web designers. We got the bug reports not the 
web designers, because "the site works correctly in IE and Mozilla"!

Adding hacks on top of hacks is something web designers have done for years, 
and our task should be to get rid of these, not add even more. Everything 
else is will just make the web an even worse place for the future.

> In practice, you could comment specific rules and then override them with
> CSS2 selectors like html>body of [attribute="value"] so that,
> theoretically, all future releases of browsers would recognize the CSS2
> selectors and have a correct style sheet.
> Unfortunately, Safari has thrown a new wrench in the mix because it doesn't
> recognize the CSS2 selectors that were supposed to "work for any future
> release of any compliant browser". I've been looking for a new CSS comment
> hack that will work on it. Anybody know of one?

Sorry? Even with the old parser khtml parsed well formed CSS2 selectors.

> Sure, I would love to write no exception code in any of my documents, but
> I'm a web developer in the real world and have to make certain sacrifices.
> The fact of the matter is that even if all browsers recognize every rule
> and display it correctly, things are still going to differ from agent to
> agent. Look at the differences in the current implementations of
> border-style; they are are correct, but they are all different because of
> lack of detail in the specification... Every agent will have 'some'
> differences, and I see CSS comment hacks as a standards compliant way to
> work around this. I'd much rather throw in a few extra CSS rules (with
> comments) than write a bunch of non-standard, non-semantic, unmanageable
> markup.

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. 


Received on Thursday, 16 January 2003 06:19:26 UTC