Re: Feature queries

On Wed, Dec 9, 2009 at 1:48 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 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.
>
> The key here is to check against a property+value pair, not a general
> feature class. The UA already makes a support claim for property+value
> pairs when it chooses to parse and cascade them.
>
> My proposal is two syntaxes. The first is an at-rule, which is handy if
> part of the style sheet depends on a major CSS feature such as Tempate
> Layout.
>
>  @supports ( declaration-block ) {
>     ruleset
>  }
>
> e.g.
>
>  @supports ( display: "bc"; ) {
>    body { ... }
>    .sidebar { ... }
>    .main { ... }
>  }
>
> This could potentially support media-query like operators like 'and'
> and 'not'.

I definitely like this, because as you say, it puts the support
declaration at the same level as what's already used.  This makes me
happy.

We will *definitely* need and/or/not operators.  Otherwise we'll have
to do some very annoying/confusing hacking to specify, frex, a
float-based layout by default and then a template-based one in a
@supports block.

(This will end up being at least somewhat necessary anyway due to
legacy clients that don't understand @supports, but let's not make it
last longer than it has to.)

> The second is a !important-like syntax: all declarations with !supported
> must be supported for the style rule to take effect. This could be useful
> for more localized constructs, like changing text color depending on
> text-shadow support.
>
>  tag {
>    background: white;
>    color: gray;
>  }
>
>  tag {
>    color: white;
>    text-shadow: black 0 0 4px !support;
>  }
>
> (This second bit is mostly keyed off my earlier proposal for !required,
> which would also take into account the results of cascading, and tie
> the effect of the no !required rules into the cascading success of the
> !required rules.)

This seems like a much worse idea for backward-compat reasons.  Legacy
clients that don't understand !support will blithely apply the
color:white and just ignore the next line like normal.


Okay, so, the @support rule.  This lets us feature-test for
properties, and for recognized values.  This is great.  I don't yet
see a way to test for selectors, though.  I'd like that included
somehow before this gets made a proper draft.

~TJ

Received on Wednesday, 9 December 2009 18:43:11 UTC