- From: Simon Sapin <simon.sapin@kozea.fr>
- Date: Thu, 23 Feb 2012 20:18:59 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: "www-style@w3.org" <www-style@w3.org>
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?) > 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] Another example: this is valid "background: url(foo) repeat #fff" but is this? "background: url(foo)repeat#fff" Last one: "!important" is 2 tokens: DELIM then IDENT. "! important" would be 3: DELIM, S then IDENT. I think only the former is valid in CSS 2.1 for priority, so the core parser (which does not know about !important) can not remove the S token. Regards, -- Simon Sapin
Received on Thursday, 23 February 2012 19:19:28 UTC