- From: Winston <wbe@psr.com>
- Date: Thu, 24 Jul 2014 15:47:05 +0000
- 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! -WBE
Received on Thursday, 24 July 2014 17:05:00 UTC