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

[css3-syntax] baduri parsing

From: Glenn Adams <glenn@skynav.com>
Date: Mon, 1 Oct 2012 10:04:45 +0800
Message-ID: <CACQ=j+eMG_mntvy6Pp7r4Eu2dRK6n7J+DdB1vO1z9E_9wvr25A@mail.gmail.com>
To: W3C Style <www-style@w3.org>
The algorithm for bad-url state in CSS3 Syntax [1] does not appear to
respect the CSS2.1 tokenization rules in [2]. In particular, [1] will match
url(foo"bar), while [2] matches only url(foo. These different choices
result in different error recovery behavior based on the rules in [3].

For example (see also attached file), given the following:

p { background-color: green }
p { background: url(foo"bar) }
p { background-color: red }

The CSS2.1 tokenization [2] would produce the following results for the
above (ignoring W for simplicity):

IDENT(p)
{
IDENT(background-color)
:
IDENT(green)
}
IDENT(p)
{
IDENT(background)
:
BADURI(url(foo)
BADSTRING("bar) })
IDENT(p)
{
IDENT(background-color)
:
IDENT(red)
}

While CSS3 Syntax [1] would produce:

IDENT(p)
{
IDENT(background-color)
:
IDENT(green)
}
IDENT(p)
{
IDENT(background)
:
BADURI(url(foo"bar))
}
IDENT(p)
{
IDENT(background-color)
:
IDENT(red)
}

In the first CSS2.1 case above, the last apparent ruleset is ignored
because it is consumed while recovering from the Malformed Statement. In
the CSS3 Syntax case, the last apparent ruleset is not ignored since the
second ruleset is terminated at the '}' after BADURI.

I notice that, at present, Safari shows red, while FF and Opera show green.
However, I believe Safari shows red for other reasons since it doesn't
follow the CSS3 Syntax bad url rule (skip to ')', but instead interprets
the bad URI as a FUNCTION followed by an error non-terminal which ends up
having a similar effect.

See also thread at [4].

[1] http://dev.w3.org/csswg/css3-syntax/#bad-url-state
[2] http://www.w3.org/TR/CSS2/syndata.html#tokenization
[3] http://www.w3.org/TR/CSS2/syndata.html#parsing-errors
[4] http://lists.w3.org/Archives/Public/www-style/2012Aug/0806.html


Received on Monday, 1 October 2012 02:05:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT