Re: Feature queries

imo, you are talking not about feature detection but about control
of css parser error recovery.

again, the right place for feature detection is MQ.

error recovery (ruleset transaction) needs something like
@onerror dismiss||ignore { ruleset } 
with arbitrary nesting level

On Wed, 9 Dec 2009, Eduard Pascual wrote:

> 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
> example:
> @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
> example:
> @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
> Recommendations".
>
> Regards,
> Eduard Pascual
>
>
>