- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 23 Feb 2012 12:41:26 -0800
- 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 UTC