Re: Feature queries

On Dec 10, 2009, at 1:33 AM, Bert Bos wrote:

> Daniel Glazman wrote:
>> Le 09/12/09 08:48, fantasai a écrit :
>>> bz asked me to post a proposal on feature queries: syntax for allowing
>>> authors to apply CSS rules based on whether a particular CSS feature
>>> is supported.
>> 
>> [...]
>> So I'm entirely in favor of it.
> 
> And I'm entirely against. :-)

I'm all for it. I think it would be very popular with authors. Isn't something like this a common request?

> 1) No nesting! Unless we first provide an alternative style sheet
> language that is easier to use, we cannot turn CSS into a programming
> language. CSS is essential for the semantic Web; reducing CSS usage
> without providing an alternative means abandoning the semantic Web.

I'm not a fan of @end-if or @else, but making this like @media (or part of @media) wouldn't be making CSS into more of a programming language. It wouldn't be any less accessible to authors than it is now. In fact, I think more authors would adopt more new properties (e.g. template layout) faster if they had something like this. How does that reduce CSS usage? I don't think it would at all.

I don't think @else is needed, because it can just be everything outside of the braces. @else-if _could_ be a shorthand of a query with a "not" that repeated the things already queried for, but isn't strictly necessary as long as there is "not".

I don't think we strongly need @supports nested inside other @supports, but I don't think that we lose much if we allow that, and others might find that useful.

> 2) We aren't worth our name as standards organization if we can't make a
> standard that is actually implemented. We're not doing designers a favor
> by recommending that UAs implement a little bit here and another bit there.

We don't live in an idealized world. New features will continue to be added as needs present themselves and as it becomes practical to do so, and they will be implemented unevenly at first. Is it really controversial to say so?

I've heard claims that IE8 implements ALL of CSS2.1, if you have the right doctype (I don't really believe it), but they only have very, very spotty support of any CSS3 (not even opacity!). The other big 3 mostly support the same properties (not perfectly), plus much from CSS3, including in html 3.2. There are a LOT of html 3.2 pages that can use css3, and something like this could help them a lot too. There are also a lot of legacy browsers in use (will we EVER be able to drop IE6 off the radar?) in which we should be able to provide a semi-decent presentation too without resorting to too many hacks.

The @supports idea is a very useful thing for authors who do not want to wait until every piece of the standard has universal support (a day that will never come, even though it is useful to do what we can to strive towards it). It doesn't mean that CSS is irrelevant as a standard. 


> I know we're having a lot of difficulty publishing the snapshot of
> interoperable CSS that we promised two years ago, but I'm not fatalist
> enough to declare that therefore lack of interoperability is the new
> interoperability.

It is the old interoperability, and we (authors, at least) still have to acknowledge and deal with that. I'm fatalistic to say that it will never be perfect, and that there will always be a need to want to have fallback for those without the latest version of their renderer. Indeed, by encouraging use of new properties with an eye at backwards compatibility and graceful degradation, we gain better and more field experience with newly implemented or experimental features, because they can be applied to Web pages more easily.