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

Re: Feature queries

From: Eduard Pascual <herenvardo@gmail.com>
Date: Wed, 9 Dec 2009 20:23:12 +0100
Message-ID: <6ea53250912091123o2363cf10p2161239195549057@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, Simon Fraser <smfr@me.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style <www-style@w3.org>
On Wed, Dec 9, 2009 at 7:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Dec 9, 2009 at 1:48 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
>> 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.

I just came up with an alternative to !support that would work better
with legacy clients: instead of marking the rules that *must* be
supported for the block to be applied, mark the rules that require
such support if they are going to be applied, like this:
tag {
    color: white; !if-supported
    text-shadow: black 0 0 4px;
(note: the choice for "if-supported" is entirely arbitrary and most
probably could be replaced by something better)
This way, on a client that doesn't support the "!if-supported" check
at all, the rule won't be applied. This leads to another issue: if a
client actually supports all the features, but not the "!if-supported"
clause, it would apply the shadow but not the text color: ugly.

The next step would be to mark both the rules for which support is
required (!support) and those that depend on such support
(!if-supported), which leads to very bloated code.
Well, all this non-sense is aimed to lead somewhere: what about an
at-rule like "@full-support"? The block contained within it would only
be applied if the client supports all the features involved. For
@full-support {
    tag {
        color: white;
        text-shadow: black 0 0 4px;
The block would only be applied if the client supports: the
"@full-support" at-rule, the element selector (I hope all clients
support this nowadays, but someone can put weirder selectors inside
the @full-support block), the "color" property with value "white", and
the "text-shadow" property with value "black 0 0 4px". If support for
any of these fails, the entire @full-support block should be ignored.

And, finally, since the syntax for this @full-support idea is quite
close to that of the @support proposal, we could just use @support
with a special keyword (or even an operator) instead of a block. For
@support(all) {
    tag {
        color: white;
        text-shadow: black 0 0 4px;
"@support(full)", "@support(everything)", and "@support(*)" are some
options worth consideration. The last one has the advantage that it
can never conflict with an actual property name (because "*" can't be
a property name), but it may arise issues if in the future we try to
expand this to explicitly check for selectors (although in such case
the syntax would become insane anyway).

Anyway, that's just an idea, and a summary of the train of thoughts
that led to it.

On Wed, Dec 9, 2009 at 7:50 PM, Simon Fraser <smfr@me.com> wrote:
> So I'd suggest caution when specifying some kind of media-query-like syntax for
> querying support based on property name.
That's an easy one: define "supported property" in the spec as
something like "parsed and processed according to the relevant CSS

Eduard Pascual
Received on Wednesday, 9 December 2009 19:24:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:31 UTC