Re: [css21] grammar issue ("url(", security)

Anne van Kesteren wrote:

>I think personally I'd be very much in favor of introducing LITERAL_IDENT  
>or something in that direction that does not allow escapes and that we use  
>that instead of allowing escapes all over the language.

My idea to resolve this and other syntax issues is to not provide a
grammar at all. (I have suggested that in the past several times.)

Why is something described as

"The grammar below defines the syntax of CSS 2.1. It is in some sense,
however, a superset of CSS 2.1 as this specification imposes additional
semantic constraints not expressed in this grammar."

useful at all to an implementor? If it's not CSS 2.1, then why bother to
have it?

Instead, I'd suggest defining a processing model, which consists of the
following steps:

1. The source is tokenized according to the tokenizer defined in <http://
www.w3.org/TR/CSS21/syndata.html#tokenization>.
2. All escapes are resolved and replaced by their respective character. [1]
3. Normalize the stylesheet to lower-case. [2]
4. The resulting token stream is parsed according to the rules and
definitions described in prose in chapter 4.

[1] This does away with the need to consider escapes in any further part
of the spec.

[2] You then can rely on a single notation in the CSS specification.
This is equivalent to "All CSS style sheets are case-insensitive".

Furthermore, we then could define that e.g. SAC builds on the result of
step 4, therefore having clearly specified that escapes are no longer
part of the data delivered via that API, similarly like e.g. SAX parsers
do not deliver the character references in the source, but their
resolved value(s).


-kris

Received on Tuesday, 25 December 2007 20:46:02 UTC