Re: [css3-conditional] feature queries

On 14/06/2011 12:25 PM, L. David Baron wrote:
> On Wednesday 2011-04-13 22:41 +0200, Bjoern Hoehrmann wrote:
>> It is not clear to me that you mean to prohibit the use of at-rules here
>> (that is the implication of using `ruleset` instead of `statement`). I'd
>> dislike disallowing at-rules inside `@supports` rules (on the other hand
>> of course there are problems with allowing them, like, say, how macros
>> would work if defined inside `@supports`).
>
> I did mean it, but only because that was the existing rule for
> @media.
>
> The module http://dev.w3.org/csswg/css3-conditional/ , however,
> relaxes that restriction both for @media and @supports.
>
>> I dislike that there is no easy way to quickly "comment out" individual
>> tests and the "supports" block as a whole (if you do text editor + re-
>> load authoring, you will typically comment the block out as a whole if
>> you want to see how the "else" works without using a different browser,


Bjoern, have you tested with @keyframes? This works quite well.

@-*-keyframes name {
    0%   { ... }
/* 50%  { ... } */
    100% { ... }
}


>> and you might want to check the effect of including one of the various
>> conditions; you can use, say, `@supports_` and `width_:` as a cheap way
>> to disable things, but that's ugly).
>
> @supports_ and width_ don't seem that ugly.  I'd welcome suggestions
> that would improve things, but I haven't thought of anything.


Perhaps some test in some test suite that shows exactly how CSS comments 
work with nested @rules in all browsers. I know, before such test can be 
tested, browsers have to support nested @rules. I do believe that it 
would be sensible to use vendor prefixes like what we have with @keyframes.

@-webkit-supports { ... }
@-moz-supports { ... }
@-ms-supports { ... }
@-o-supports { ... }


>> Similarily, the requirement to specify a whole declaration means that
>> you may have to do things that are most probably silly, like checking
>> for a property that takes just one integer, and then you have to pick
>> some random value to make the test (or test for `(name: inherit)` or
>> something similar).
>
> I actually think this requirement is good; I think testing for a
> property-value pair rather than just a property is likely to be the
> right level of feature detection.  I could be wrong, though.


After seeing many comments from authors here and in other mailing list 
over many years, the overwhelming consensuses is to query the support of 
just the property.


>> I also dislike the name `supports`; it's confusing to read something
>> like, say, `@supports (width: 1024px) { ... }` which the implementation
>> likely parses fine, but my idea of supporting `width: 1024px` is quite
>> different from "parses fine".
>
> Well, implementations shouldn't parse it if they don't support it,
> but at some point feature detection does rely on trusting
> implementations to get that right.  Existing CSS value fallback
> already does, and it mostly works.


(in asking this question, I not referring to IE7- parsing)

Can you shows examples where it doesn't work?

The last time I saw a browser do something very wrong (breaking 
forwards-compatible parsing) was with the below CSS and Opera 9.5.

    text-shadow: 10px 10px 0 hsla(50, 15%, 15%, 0.5)

Even though Opera 9.5 didn't support hsla(), it would still parse the 
property and value but inherit the color for the text-shadow from an 
ancestor.

Another example is this.

<!doctype html>
<style type="text/css">
p { background: green url()right no-repeat; }
</style>
<p> This paragraph should have a green background.</p>

This time IE7 and IE8 did it right. They dropped the whole declaration 
but due to legacy reasons (ie. Gecko, WebKit and Presto behavior), it is 
now supported by IE9. This should never had been allow since something 
like this,

    keyword()keyword

may had been useful in the future to allow forwards-compatible parsing.


>> You don't say how parse errors are handled, say in
>>
>>    @supports (width: 0) or ($height: 0) { ... }
>>
>> That's okay per the generic syntax but `$height` does not make a proper
>> property name. Does the whole block get ignored or just the condition?
>> Similarily, for extensibility, what about
>>
>>    @supports (width: 0) or selector(:has) { ... }
>>
>> Would this fail as a whole, meaning extending this beyond declarations
>> will be "hard" should the need arise?
>
> I've clarified this to say that it has to parse according to the
> 'declaration' term in the core syntax (CSS 2.1 chapter 4), and
> otherwise the rule is invalid:
> http://dev.w3.org/csswg/css3-conditional/#at-supports
>
> However, $height as a property name is actually *not* valid
> according to the core syntax, given:
>    # declaration : property S* ':' S* value;
>    # property    : IDENT;
>
> -David


Why should this not work?

@supports (width: 0) or selector(:has) { ... }

I thought 'or' meant an alternative. It's not like you used 'nor'.


In example VII in the draft, I see this.

@supports ( box-shadow: 2px 2px 2px black ) or
           ( -moz-box-shadow: 2px 2px 2px black ) or
           ( -webkit-box-shadow: 2px 2px 2px black ) or
           ( -o-box-shadow: 2px 2px 2px black ) {
   .outline {
     color: white;
     box-shadow: 2px 2px 2px black;
     -moz-box-shadow: 2px 2px 2px black;
     -webkit-box-shadow: 2px 2px 2px black;
     -o-box-shadow: 2px 2px 2px black;
   }
}


Could this not simply be this?

@supports ( -*-box-shadow ) or ( box-shadow ) {
   .outline {
     color: white;
     -moz-box-shadow: 2px 2px 2px black;
     -webkit-box-shadow: 2px 2px 2px black;
     -o-box-shadow: 2px 2px 2px black;
     box-shadow: 2px 2px 2px black;
   }
}


Also example VII in the draft has the prefixed and non prefix properties 
in the wrong order for proper cascadence (my example above has the 
correct order).



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Tuesday, 14 June 2011 07:47:28 UTC