Re: [css3-syntax] baduri parsing

On Wed, Oct 3, 2012 at 2:52 PM, Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>wrote:

> (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.
>

Well, at least IE, OP, and FF observe the CSS2.1 rules here, and WK's
behavior seems to only accidentally match the newly suggested syntax.


>
> (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
>

My preference is A. There seems no particular advantage of shifting
behavior here, especially given the existing behavioral agreement by most
of the UAs. I'm prepared to fix WK to match this behavior, in which case it
would be unanimous (among this set... I haven't checked Amaya, or others).

Note there has been a bug to fix this on WK for some time [1].

[1] https://bugs.webkit.org/show_bug.cgi?id=39363