Re: [css3-conditional] feature queries

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,
> 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.

> 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.

> 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.

> 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

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Tuesday, 14 June 2011 02:25:51 UTC