Re: [css3-cascade] browser specific CSS

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.

I understand the problematic parts:

(1) Existing UAs need other styles - this should be fine because the
    @required says that either all of these must apply or none at
    all. As such, the style author MUST be prepared for the fact that
    none apply. There should be no problem with existing UAs.
    This would in fact be a plus because it would prevent style
    authors from wrapping the whole stylesheet with @required block
    and believe they did a great job.

(2) What does it mean for an UA to "support" all properties, selectors
    and values? I think that this should be left to the UA vendors.
    To make @required usable, all that is needed is that UA vendors
    do not lie on purpose; It would be fine to "support" property
    "position" with value "absolute" but not with "fixed". There's
    nothing in the @required construct that necessitates that if
    UA supports one value for a property, it must support all.
    Obviously, every now and then there would be some problem
    in some implementation of some value of some property in
    some UA but in that case the UA had bug that would cause all
    the SAME problems even without the @required feature. In
    the WORST case the @required feature would not help.

I see @required as a method for applying a collection of rules that need
to apply as a whole. I think it's totally usable for that even if UA
vendors make a mistake or two every now and then.

However, I do not think that @required feature can be used to
effectively work around browser bugs. I'd prefer workarounds to browser
bugs to be applied selectively on each buggy version. If I could decide,
I'd add

@workaround "FULL UA STRING/2.3 (with; all; the; stuff) whatever 1.2",
"FULL UA STRING/3.0 (with; all; the; stuff) whatever 1.2"
{
   selector { property: value; }
   selector2 { property: value; }
}

That is, the only way to target a huge list of buggy UAs would be to
include a huge list of full UA strings. I prefer this method not because
it would be easiest for the authors but because it would definitely
cause least amount of issues in the future. This could be used to
workaround the FATAL bugs that some UAs may grow.

-- 
Mikko

Received on Monday, 4 April 2011 13:47:34 UTC