W3C home > Mailing lists > Public > www-style@w3.org > April 2012

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 16 Apr 2012 07:40:00 -0700
Message-ID: <CAAWBYDBeeqbz73ncZ-ZfPj9GjooGUUELoKxA1SjA=zEQF-oP=w@mail.gmail.com>
To: Simon Sapin <simon.sapin@kozea.fr>
Cc: www-style list <www-style@w3.org>
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().

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC