W3C home > Mailing lists > Public > www-style@w3.org > July 2014

Re: [mediaqueries] two syntax items

From: Winston Edmond <wbe@psr.com>
Date: Wed, 23 Jul 2014 16:15:08 +0000
Message-Id: <201407231615.s6NGF5OG007963@psr.com> (sfid-20140723_161514_260257_4142DB2C)
To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
On Mon, Jun 9, 2014 at 1:22 PM, I asked:
>> 1) Is "()" considered an empty "general expression" whose value is false
>>    [making "not ()" true], or is it considered a syntax error?

to which "Tab Atkins Jr." <jackalmage@gmail.com> kindly replied:
> Per the grammar, it's valid and false.  It ends up hitting the
> <general-enclosed> production.

OK.  I think it'd be worth adding something to that effect in the spec,
perhaps by adding "@media not () is turned into true" to the list of
examples in section 3.

Speaking of section 3 of "http://dev.w3.org/csswg/mediaqueries4/"
(3 June 2014 draft), there appears to be a "typo" in this example:


    @media (example, all,), speech { /* only applicable to speech devices */ }
    @media &test, screen           { /* only applicable to screen devices */ }

    Both of the above media query lists are turned into not all, speech
    during parsing, which has the same truth value as just speech.


The "typo": not "both", since the second is "not all, screen" (or change
screen => speech in line 2).

>> 2) Re: The section 3 example "@media (example, all,), speech"

[I asked if "split queries on comma" made sense given that the current
subexpression syntax doesn't allow commas.  TJ explained why not and
added this fine example:]

> For example, given this markup:
> @media (example, speech {
>   foo { color: red; }
> }
> The opening paren swallows *the rest of the document* into its block,
> and then there's a syntax error because @media blocks need a {}-block
> at their end.

 ... and presumably also a syntax error in the media query expression
itself because the matching ')' is absent.  Wow.  That'd make a good
example, too.  :)

Thanks for the reply,
Received on Thursday, 24 July 2014 10:18:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC