W3C home > Mailing lists > Public > www-style@w3.org > January 2005

Re: Marking style properties as "required" + groups of styles

From: Ben Ward <benmward@gmail.com>
Date: Wed, 12 Jan 2005 21:10:23 +0000
Message-ID: <ef5d0f2f05011213101d38b146@mail.gmail.com>
To: www-style@w3.org

> I'm not sure I agree. If this does get implemented we will still run
> into problems, as some browsers will, intentionally or not, mis-report
> their own status. Combine this with a situtation similar to that of
> HTML's button element--where one popular browser has implemented a
> non-standard behavior, rendering the element nearly useless for its
> inteded purpose.

That is true, !required would not allow you to block styles based on
browser bugs, only on unimplemented features. However, I would still
encourage that this is useful enough for implementation (use-case in
message #1: Konquorer 3.1.1 did not support *:hover but did support
">" selectors, preventing their use as a "CSS2 masking hack").

> I agree that some sort of support-based statement binding would  be
> lovely, but I'm wondering if this might be more reliably implemented
> another way.

As far as I can see, the only other way you might implement like this
would be to base it on user agent (since bugs are ua specific).
Specify a unique ID in CSS3 renderers and implement a syntax that
would be ignored in all current (popular) CSS1/2 browsers.
I think such a syntax is a very, very bad idea. In whatever way such
renderer based filtering was implemented, it wouldn't work. If you
specified exact versions of browsers then you'd have to update every
time a new one was released, if you specified general browser names
you'd exclude more recent versions with the CSS error fixed. Not to
mention any future presence of new web browsers.

There's no intuitive way to do that. At least !required is a timeless
syntax that does not depend on the author. No, it doesn't solve any of
the world's browser bugs but it does permit authors to push CSS uasge
forward in browsers that support it, without worrying about which
browsers those are.

The only way I can possibly think about browser filtering being a
'good thing to do' is if we were to accept that the need to hack is
inevitable and therefore provide a syntax for it so we can avoid messy
comment hacks. E.g a "since we have to do it, just do it cleanly"
attitude. Personally, I don't accept that hacking is inevitable and I
don't think  it's right for a standard to define that people should be
allowed to get it wrong.
Received on Wednesday, 12 January 2005 21:10:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:16 UTC