- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 29 Aug 2012 10:17:09 -0700
- To: "Kang-Hao (Kenny) Lu" <kanghaol@oupeng.com>
- Cc: "L. David Baron" <dbaron@dbaron.org>, WWW Style <www-style@w3.org>
On Wed, Aug 29, 2012 at 8:58 AM, Kang-Hao (Kenny) Lu <kanghaol@oupeng.com> wrote: > (12/08/29 23:19), Tab Atkins Jr. wrote: >>> I can't reproduce your result in dom viewer with my test case[1] (in >>> both Chrome 21 and 23). Can you save it and share the URL so I can learn >>> what's going on too? >>> >>> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1724 >> >> Okay, our parsing is officially retarded. >> >> Insert a newline immediately before the </style>. You'll get green. > > Ah, it means that WebKit doesn't implement BAD_STRING. See, for example, > this test case[2], where > > "; background: green; } > > is tokenized into > > DELIM(;) IDENT(background) > > in WebKit instead of > > BAD_STRING("; background: green; }) > > as required by both CSS 2.1 and the current css3-syntax. No, it just means our parsing is retarded, and is relying on some weird detail. Again, it's the presence or absence of a newline that causes this. You can put the newline literally *anywhere* after the " (well, anywhere whitespace is allowed), and you get the effect. > It also means that, when encountering a case like url(a "), WebKit goes > into the string parsing path instead of treating " as a non-) character > like what css3-syntax requires. > > Therefore, I disagree with the claim that the current BAD_URI token is > implemented by WebKit. Having said that, I think what css3-syntax says > is not be a bad idea performace-wise and I might favor it eventually. > It's just not matching any implementation as far as I can tell. Yeah, our parsing is clearly just all kinds of screwed up here. ~TJ
Received on Wednesday, 29 August 2012 17:18:16 UTC