W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [CSS21][Core grammar] Significant whitespace

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 23 Feb 2012 12:41:26 -0800
Message-ID: <CAAWBYDCALR=usAP+Tbm1NX3vQgeP1V8fDaD5mQ+P-8spt0nNYQ@mail.gmail.com>
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: "www-style@w3.org" <www-style@w3.org>
On Thu, Feb 23, 2012 at 11:18 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Le 23/02/2012 17:28, Tab Atkins Jr. a écrit :
>> On Mon, Feb 20, 2012 at 5:35 PM, Simon Sapin<simon.sapin@kozea.fr>  wrote:
>>> [...]
>>>
>>> What about white space inside the value for a declaration? The 'value'
>>> field
>>> for any property that I can find never lists white space. But is there a
>>> design principle that I can rely on saying that white space in any
>>> property
>>> value will never be significant like it is in selectors? (Other than for
>>> separating tokens.)
>>>
>>> If there is no such principle, white space needs to be handled while
>>> parsing
>>> the value for each individual property.
>>
>>
>> White-space inside of strings is obviously significant.
>
>
> Yes. They parse as a single STRING token, opaque to the core parser. My
> question was about S tokens that appear in the grammar, like in:
>
> value       : [ any | block | ATKEYWORD S* ]+;
>
> (I’m looking at http://www.w3.org/TR/CSS21/syndata.html#tokenization
> Is it correct that css3-syntax should be ignored?)

Yes, you should absolutely ignore css3-syntax.

>> Otherwise,
>> the only value of whitespace is for token-separation.
>>
>>> For example, there has been suggestions of accessing individual items in
>>> "lists" like font-family or transforms.
>>> If a value like "font-family[4]" becomes legal, will it be the same as
>>> "font-family [4]" or will white space become significant?
>>
>>
>> This would be a Core Grammar change, so don't worry about it.  A
>> future-proof parser is one that correctly implements the
>> error-handling rules, so encountering something like this in the
>> future will just mean ignoring everything up until the next ; or }.
>
>
> This is invalid for a property name but not for a value. I guess this
> specific example doesn’t work, but I can imagine new properties that takes
> values with a kind of indexing: something[index]

In the grammar, [foo] is a single instance of the 'any' production,
which has optional whitespace around it.  So, "something[index]" is
required to be parsed the same as "something [index]".

~TJ
Received on Thursday, 23 February 2012 20:42:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:51 GMT