Re: feature queries

* L. David Baron wrote:
>I also wonder whether the idea that listing multiple declarations is
>implicitly "and" is clear; I think it could be confused with or.

>I want to avoid allowing more than one of 'not', 'and', and 'or' at
>the same nesting level (i.e., parentheses are required to prevent
>things like "a and b or c" or "not a and b")
>
>I do, however, want to allow authors to mix 'and', 'or', and 'not'
>terms as needed.  I think the inability to do that in media queries
>has been painful for authors.

I agree with the above.

>So in other words, I'd propose the grammar for a new rule
>('supports-rule' in the grammar below) which would be allowed
>wherever @media rules are allowed:
>
>supports-rule: '@supports' condition '{' S* ruleset* '}' S*

Well, some thoughts:

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

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

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?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Wednesday, 13 April 2011 20:41:55 UTC