Re: [mediaqueries] two syntax items

1) I originally 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.

I responded:
>> 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.

and TJ replied:
> Do you really think that's useful?  Implementors should just be
> implementing the grammar, in which case that sort of thing is handled
> automatically, and we only add examples of invalid syntax for authors
> when it's a little tricky and authors might actually hit that case.  I
> don't think this is something any author would do normally.

Yes, I do think this one's useful.  The problem is that the definition
of <general-enclosed> (which is somewhat broken, but I'll get to that
next) suggests that "" (the empty string) does not qualify.  After
reading both level 4 draft and level 3, I was unable to determine
whether there was intent for "" to be treated as a valid
<general-enclosed> expression, prompting my original email.  I contend
the spec needs to say, either via the rule or via an example.


2) On to the definition of <general-enclosed> itself...  This definition
   in the June 3 version of the Level 4 Draft:

   ----------

   <general-enclosed> = [ <function-token> | ( ] <any-value>* )

   ----------

   looks broken.  I read it as "[...] <any-value>* )" (requiring a close
   paren even if there was no open paren).  It also [as of June 3] means
   that "" is not a valid <general-enclosed> (and thus that "()" is a
   syntax error).


3) At high level, while I understand why "()" has been defined to return
   false, that's contrary to what a newcomer might expect.  One might
   think "()" -- an expression in which no restrictions appear -- ought to
   evaluate to the same value as "" (i.e., true), just as the absence of
   an expression in "@media {...}" does, and that not() would be false,
   and that "( <general-enclosed> )" would be the other way around (as it
   is officially) only if there's non-whitespace content.  That could be
   accomplished by changing the first part of <media-in-parens> to
   something like:

   <media-in-parens> = ( [ whitespace* | <media-condition> ] ) |  ...
   
   and leaving <general-enclosed> as not including "".  Of couse, then
   the spec would need to add that "(whitespace*)" evaluates to true,
   and the example I suggested back in topic #1 above would have to be
   reversed.  :)

   Not a bug, just an observation.  :-)

 -WBE

Received on Thursday, 24 July 2014 10:19:21 UTC