Re: [css3-syntax] "bad" tokens (was: Reviving the spec, starting with the parser)

On Mon, Apr 16, 2012 at 5:29 AM, Simon Sapin <simon.sapin@kozea.fr> wrote:
> Hi,
>
> CSS21 defines BAD_STRING, BAD_URI and BAD_COMMENT tokens in terms of regular
> expressions, but they are not mentioned anywhere else. All I could do was
> reverse-engineer the regular expression and guess how these tokens could
> happen, what was their purpose, and what to do with them.
>
> This draft got rid of BAD_STRING and BAD_COMMENT (which is good), but
> BAD_URI remains (renamed).

Hmm, I had thought that BAD_STRING and BAD_COMMENT weren't necessary -
BAD_STRING only triggered when it ran into an EOF or unescaped EOL,
and BAD_COMMENT only triggered when it ran into an EOF.  These cases
are all explicitly handled by the tokenizer now.

However, it looks like BAD_STRING is treated as a syntax error when
it's encountered due to an unescaped EOL.  I'll need to handle that
and emit a bad-string token, then.

> I suppose this will be in the part of the spec that is not written yet, but
> what should a parser do with a bad-url token?

Yeah, it's the part that's not yet written.  The effect will be to
immediately enter the appropriate error state (consuming to the next ;
or }), as no property can ever accept an invalid url().

~TJ

Received on Monday, 16 April 2012 14:40:57 UTC