W3C home > Mailing lists > Public > www-style@w3.org > April 2008

Re: functional notation syntax

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sun, 06 Apr 2008 21:15:35 -0700
Message-ID: <47F99FE7.8090304@terrainformatica.com>
To: Andrei Polushin <polushin@gmail.com>
CC: www-style@w3.org

Andrei Polushin wrote:
> 
> Anne van Kesteren wrote:
>> Andrei Polushin <polushin@gmail.com> wrote:
>>> Was there such a discussion, or a formal decision on this, or not yet?
>>>
>>> I would prefer to re-allow whitespace between the CSS function name
>>> and the opening '(', i.e. to split the FUNCTION token. It might sound
>>> too radical, but what was the reason to disallow it in past?
>>> Otherwise, and as a consequence, now it's hard to allow an optional
>>> whitespace in such a non-functional context.
>>
>> We have only discussed this in the context of media queries. I don't 
>> think changing this aspect of CSS is planned.
> 
> OK, in context of media queries - what were the opinions of that 
> discussion?
> 
> The specification should /clearly/ describe how the following is parsed:
> 
>   @media screen and(color) { /* ... */ }
> 
> Possible alternatives are:
> 
> 1. It is an error, because "and(" is a FUNCTION token, not allowed in 
> grammar of media_query_list. Specification should explain this somehow, 
> provide an example, then describe the workaround for writing this 
> correctly (i.e. it inserting a space before the opening '(').
> 
> 2. It is not an error, because each FUNCTION token is locally split into 
> IDENT and '(' tokens in context of parsing the media_query_list 
> production. Specification should explicitly state this, if it prescribes 
> such behavior.
> 
> In either case, there is no need to change the global CSS syntax rules. 
> Hopefully that's a matter of local decision, to be made by media-queries 
> specification.
> 

Sigh.

whitespace in CSS already have multiple meanings in CSS. It is not just 
a separator but a combinator in selector context and is operator - value 
list elements glue (known there as 'empty').

So I think it will not harm anyone if in MQ whitespace will play a role 
of just a tokens delimiter. MQ is going to be used not only in CSS
so syntax should be as less peculiar as possible. So I vote for your #2.

Sigh №2.

And that minus sign ... What about excluding '-' from name tokens in MQs?

-- 
Andrew Fedoniouk.

http://terrainformatica.com
Received on Monday, 7 April 2008 04:16:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:04 GMT