W3C home > Mailing lists > Public > www-style@w3.org > December 2009

Re: Feature queries

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 9 Dec 2009 12:42:36 -0600
Message-ID: <dd0fbad0912091042w3a9e2436m6b6c3f10a914bce@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: www-style <www-style@w3.org>
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

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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:41 UTC