Re: [mediaqueries] two syntax items

On Wed, Jul 23, 2014 at 11:57 AM, Winston <wbe@psr.com> wrote:
> 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.

Sorry, this is a little unclear - do you mean literally an empty
string, or just "nothing between the parentheses"?  It's sometimes
hard to tell whether quotes are meant to be delimiters for a code
string or part of the code itself. ^_^

In any case, both an empty string and nothing are valid, as they both
match <any-value>*.

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

What do you mean "even if there was no open paren"?  It's possible
that you're misinterpreting <function-token>, which is understandable,
since it's a slightly funky detail of CSS's tokenization.
<function-token> is the "beginning" of a function, composed of the
name and open paren.

> It also [as of June 3] means
>    that "" is not a valid <general-enclosed> (and thus that "()" is a
>    syntax error).

Correct that neither an empty string nor nothing at all are valid
<general-enclosed> values - as the name suggests, they must be
enclosed, by parentheses in this case.  However, `()` is absolutely
valid.  What makes you think otherwise?

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

() is false not because it's empty, per se, but because it's a syntax
error that we allow for future-compatibility reasons.  Newcomers
shouldn't use it at all.

>    Of course, the other, even simpler alternative, is simply to declare
>    "(whitespace*)" a syntax error, since it doesn't really provide much
>    value.  The previous idea of having it be true was just if you wanted
>    to keep "()" as syntactically valid.

While it's possible to do so, I don't see much reason to make it
actually a syntax error, given the general MQ theme of attempting to
recover from errors.

~TJ

Received on Wednesday, 23 July 2014 21:06:23 UTC