- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 23 Feb 2012 08:28:48 -0800
- To: Simon Sapin <simon.sapin@kozea.fr>
- Cc: "www-style@w3.org" <www-style@w3.org>
On Mon, Feb 20, 2012 at 5:35 PM, Simon Sapin <simon.sapin@kozea.fr> wrote: > Hi, > > I am in the process of writing a "future proof" parser for CSS. The idea is > to separate the core grammar from stuff defined in CSS 2.1 or various CSS 3 > modules, so that it is easy to add syntax from such modules. > > White space can appear at a lot of places in the core grammar, and some of > it is significant. For example, the selector 'a [href]' has a descendant > combinator and is different from 'a[href]'. > > However, most white space is *not* significant and can be safely removed > while parsing the core gramma. For example between statements or between > declarations. > > 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. 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 }. That said, if we do list-indexing via property name, I suspect it will be easiest to sell with a syntax like 'font-family-4' so it still matches the property name grammar. ~TJ
Received on Thursday, 23 February 2012 16:29:38 UTC