Re: [css3-cascade] browser specific CSS

On Mon, Apr 4, 2011 at 6:47 AM, Mikko Rantalainen
<mikko.rantalainen@peda.net> wrote:
> 2011-04-01 11:28 EEST: Christoph Päper:
>> Tab Atkins Jr.:
>>>
>>> The one area where we *do* want to do something, imo, is in making
>>> CSS capable of doing feature-testing.  This has been proposed in
>>> the group before, via an @supports rule.
>>
>> I liked the ‘!required’ solution:
>>
>> foo { bar: plain and simple; /* fallback */ bar: bells and whistles
>> !required; baz: only works well with second bar !required; }
>>
>> This hardly works across rulesets and only provides one level of
>> fallback, but it is good enough for many use cases.
>
> I'd still prefer @required {} which would explicitly define the start
> and the end for the required part and which would allow for multiple
> blocks to be defined (only one block would be considered at a time so a
> style author could try to apply successively more complex blocks in the
> future).
>
> It seems to me that @required was not accepted in September 2005 because
> UAs may still end up applying rules that will be incorrectly
> implemented. See sub-thread starting at
> http://lists.w3.org/Archives/Public/www-style/2005Sep/thread.html#msg88
>
> I tried to argue about that in
> http://lists.w3.org/Archives/Public/www-style/2005Sep/thread.html#msg93
> but I was unsuccessful.
>
> Reading the thread now, I still think that CSS should it. I think that
> the discussion was geared too much towards working around UA bugs
> instead of applying a group of rules at once (kind of transaction of rules).
>
> The basic building block is as follows:
>
> @required
> {
>        p { background: black; color: silver; }
>        em { color: white; }
> }
>
> And if the UA does not support ALL the properties, ALL the selectors and
> ALL the values, then it should ignore the whole block. In practice, all
> current UAs must ignore this block (because those do not support
> @required) and it would be fine.

Note that the better version of this also uses a "!required" value on
properties that must be understood; in your version, it's impossible
to use prefixed properties (even if they're incidental to the effect
you're trying to achieve), as they won't be understood by other
browsers.  Then, the set of rules is applied only if all the !required
properties are understood; non-!required properties are ignored for
this purpose.

~TJ

Received on Monday, 4 April 2011 15:56:04 UTC