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

Re: [css3-syntax] baduri parsing

From: Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
Date: Wed, 03 Oct 2012 14:52:26 +0800
Message-ID: <506BE0AA.8060105@oupeng.com>
To: Glenn Adams <glenn@skynav.com>
CC: W3C Style <www-style@w3.org>
(12/10/01 10:04), Glenn Adams wrote:
> 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.

Right.

(12/10/02 10:43), Glenn Adams wrote:
> Thanks. It would seem that the suggested baduri algorithm in css3-syntax
> may turn one browser green and would turn at least three red. 

So you can as well construct an example that turns all four browsers red:

  data:text/html,<style> body { background: red; url(a"); background:
green; } "</style>

like I said in [1].

(12/10/02 10:43), Glenn Adams wrote:
> Thanks. It would seem that the suggested baduri algorithm in
> css3-syntax may turn one browser green and would turn at least three
> red. Perhaps that suggested algorithm should be rethought?

Maybe. However, this way - making BAD_URI self-contained - has the
advantage that we no longer need to consider this token in the "Consume
a primitive" algorithm and hence a bit of codes can be removed. If all
browsers vendors can agree on this then that's probably not a bad idea,
as I don't think compatibility problem is a big deal here.

(12/10/03 3:36), Tab Atkins Jr. wrote:
>> Thanks. It would seem that the suggested baduri algorithm in
>> css3-syntax may turn one browser green and would turn at least three
>> red. Perhaps that suggested algorithm should be rethought?
>
> Sounds like it.  My windows box is broken at the moment, so I can't do
> decent testing to know how to fix it, but I'll log an issue at least
> and work on it soon.

I'll make a summary of some of the options here:

A. Go back to CSS 2.1: turn bad-url into what BAD_URI used to be, make
"Consume a primitive" treat bad-url like a function token.

B. Make bad-url token observe matching quotes.

(I don't like this because the codes that can be removed from the parser
because of making bad-url self-contaned is no longer more than codes
that needed to be added to the tokenizer.)

C. Keep the current algorithm and see if browsers vendors can agree on that.

D. Simplify bad-url further by removing

  # U+005C REVERSE SOLIDUS
  #
  # If the next input character is a newline or EOF, do nothing and
  # remain in this state.
  #
  # Otherwise, consume an escaped character. Remain in this state.

in "Bad-URL state" so that url(a b\) is a bad-url.

My preference is probably D > A > C > B



Side comment: "URL-double-quote state", "URL-single-quote state",
"URL-end state", "URL-unquoted state" and "Bad-URL state" need to handle
the EOF token.


[1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0883



Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
Received on Wednesday, 3 October 2012 06:53:00 GMT

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