Re: [CSS21][Core grammar] Significant whitespace

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