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

Re: [mediaqueries] two syntax items

From: Winston <wbe@psr.com>
Date: Thu, 24 Jul 2014 15:47:05 +0000
Message-Id: <201407241547.s6OFl5Fb012343@psr.com> (sfid-20140724_154711_850210_76B9A66D)
To: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style list <www-style@w3.org>
>>    <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.

Ah, you're right, I was, and clearing that up fixes my understanding of
the other stuff.

> ... do you mean literally an empty string, or just "nothing between
> the parentheses"?

The latter.

> 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?

My misunderstanding.  :)  Sorry about that.

Re: whether () should be true, false, or a syntax error

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

Agreed.  I was making a "principle of least surprise" argument for "()"
being true and "not()" false, but since neither should be occurring and
it's now clear that doing that would require splitting general-enclosed
into "(whitespace*)" as true and "(other)" as false (since substantive
general-enclosed needs to remain false), I think I'll drop it.  The way
it is is good enough.

TJ: Thanks for taking time to answer my questions and clarify things!
Received on Thursday, 24 July 2014 17:05:00 UTC

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