Re: Targeting CSS3 only (evil?), either with pseudoclass or an extra syntax for properties.

The problem there Ryan is that there is no easy way to determine when
a user agent should  respond to that kind of blanket grouping. For
instance, there are bugs in all the major browser's CSS
implementations.

Lets imagine a bug in Mozilla's CSS1 implementation: Does the presence
of that bug mean that Mozilla should respond positively to some
@module css1 { } syntax?

CSS3 /is/ huge. We're going to have long enough to wait for any kind
of !required property syntax (of any form) to be implemented broadly
enough to be useful. If that system were to based on having completely
implemented an entire CSS3 module, an honest browser will take even
longer. I would expect a lot of browsers would just process those
blocks as soon as they got close to a full implementation, inevitably
breaking the functionality for some author who used it correctly.

If any kind of implementation sniffing was to be useful (in a useful
timeframe) I think it needs to match the following:

* It needs to be (maybe optionally) completely hidable from
non-supporting agents, as best as possible. As best I understand it,
putting required groups together in a @block would do this.
* It needs to be specific to properties so that authors are able to
embrace the new functionality as soon as it's implemented.
* It should (I think) be applicable to all levels of CSS, so "@css3"
type rules are a bad idea. If a new author were to approach CSS post
CSS3, how are they to know (and why should they care) which level of
CSS a particular property comes from?

I don't think that requiring an entire CSS3 module will provide that
usefulness soon enough. For instance, if the WG actually likes this
idea and was to finalise some syntax, Mozilla and Opera would
inevitably be early adopters, enabling the use of future CSS3
implementation as and when each company got their implementation in.
If we had to wait until a browser supported an entire CSS3 profile
before we could filter on it, well, we'll still be here this time next
year.

... This is hard. Heh.

Received on Wednesday, 6 April 2005 19:13:12 UTC