W3C home > Mailing lists > Public > www-style@w3.org > March 2015

Re: [mediaqueries] @media screen and (foo) or (baz)

From: Florian Rivoal <florian@rivoal.net>
Date: Mon, 23 Mar 2015 20:54:21 +0100
Cc: www-style list <www-style@w3.org>
Message-Id: <4C691D12-EA09-475B-AC18-AD600623734C@rivoal.net>
To: Simon Sapin <simon.sapin@exyr.org>

> On 23 Mar 2015, at 17:08, Simon Sapin <simon.sapin@exyr.org> wrote:
> MQ Level 4 extends the syntax to allow arbitrary nesting of "not", "and", and "or" boolean operators. It avoids the question of whether `A or B and C` should be interpreted as `A or (B and C)` or `(A or B) and C` by requiring the parentheses:
> Extract of the grammar:
>> <media-condition> = <media-not> | <media-and> | <media-or> | <media-in-parens>
>> <media-not> = not <media-in-parens>
>> <media-and> = <media-in-parens> [ and <media-in-parens> ]+
>> <media-or> = <media-in-parens> [ or <media-in-parens> ]+
>> <media-in-parens> = ( <media-condition> ) | <media-feature> | <general-enclosed>
> However, there is one case left that may seem ambiguous. The <media-query> grammar:
>> <media-query> = <media-condition>
>>             | [ not | only ]? <media-type> [ and <media-condition> ]?
> accepts `<media-type> and <media-or>`, e.g. `screen and (foo) or (bar)`.
> The grammar makes it unambiguously the same as `screen and ((foo) or (bar))`, but that’s not obvious without referring to the spec.
> Should the grammar be restricted to require parenthenses in this case as well?

Since the intention is for media types to be phased out, you should not run into this case too often. And when the media type is omitted, I wouldn't want to have mandatory parentheses, nor would I want them when the media type is followed by a media condition made of a single media feature (and that wouldn't be backwards compatible anyway).

If you think it is worth special casing the grammar for dealing with the limited case that remains once you've removed that, I am not really opposed to it.

- Florian
Received on Monday, 23 March 2015 19:54:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:52 UTC