- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 1 Oct 2012 10:04:45 +0800
- To: W3C Style <www-style@w3.org>
- Message-ID: <CACQ=j+eMG_mntvy6Pp7r4Eu2dRK6n7J+DdB1vO1z9E_9wvr25A@mail.gmail.com>
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
Attachments
- text/html attachment: test.html
Received on Monday, 1 October 2012 02:05:34 UTC