Re: [mediaqueries] two syntax items

[Sorry for the late reply; our moderation queue was just emptied.]

On Mon, Jun 9, 2014 at 1:22 PM, Winston <wbe@psr.com> wrote:
> In regards to Media Queries Level 4, draft 3 (June 2014):
>
> 1) Is "()" considered an empty "general expression" whose value is false
>    [making "not ()" true], or is it considered a syntax error?

Per the grammar, it's valid and false.  It ends up hitting the
<general-enclosed> production.

> 2) Re: The section 3 example "@media (example, all,), speech"
>
>    The <media-query> syntax has no provision for commas in
>    subexpressions.  OR is achieved by <media-or>, which uses " or ", not
>    comma.  Syntax error handling must already include dealing with
>    unbalanced parentheses, so there is no particular reason why the '('
>    should be allowed to hide commas, complicating finding the end of the
>    current query in a query list.  There might not even be a matching ')'
>    later.  The draft currently says:
>
>    "the above media query lists are turned into  not all, speech"
>
>    but perhaps comma should always be a query list separator, in which
>    case that would be parsed as a list of four queries: "(example" ,
>    "all" , ")", and "speech".  The first and third would be syntax
>    errors, leaving the expression to be "all,speech", which is
>    equivalent to "all".

No, CSS has a general rule of always respecting the "enclosing"
characters of (), [], and {}.  It makes it much easier to extend CSS
in the future.  It would be bad, for example, if we wanted to allow
you to specify a comma-separated value inside of a media condition, or
specify a function with comma-separated arguments, and weren't able to
because we instead used a naive "split on commas" rule.

This general rule is even reflected in the parser, as defined in the
Syntax spec: <http://dev.w3.org/csswg/css-syntax/>.  Any use of ()[]{}
produces a "block" of the appropriate type in the parser output; you
have to introspect into the block to get at the contents.  The
left/open version of the characters never appears directly in the
output for this reason.  The right/close version only shows up when
it's mismatched.

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.

~TJ

~TJ

Received on Wednesday, 23 July 2014 14:41:09 UTC