Re: [css3-syntax] Null bytes and U+0000

(12/10/23 11:02), Boris Zbarsky wrote:
>> * Firefox appears to convert it into a \0, and then act normally.
>
> That's ... odd.  I would expect \ followed by an actual null, assuming
> the null gets down to the CSS parser, to just keep the null as a
> character in the tokenization, the same way that \w would work.  Link
> to the testcase you were using here?

(12/10/24 6:23), Boris Zbarsky wrote:
>> I've reproduced a slightly better testcase as
>> http://www.xanthir.com/etc/css-null-testing/escaped-null-in-selector.html
>>
>> Here's a repro of what I get out of the CSSOM in FF:
>>
>> p { background-color: red; color: white; }
>> .one { background-color: green; }
>> .two { background-color: green; }
>> \0 .three { background-color: green; }
>> .four { background-color: green; }
> 
> Ah, you're seeing a bug in the serializer there, looks like. 

Just in case you want to be assured that escaped NULL works fine in FF,
at least in the selector. Here is a test case:


data:text/html,<style></style><span>TEST</span><script>document.querySelector('style').textContent
= "%23\\\u0000 { color: green; }"; document.querySelector('span').id =
"\u0000";</script>

(12/10/24 7:14), Tab Atkins Jr. wrote:
> 2. Hex-escaped NULLs (\0) actually return U+FFFD, same as a hex-escape
> for a character beyond the maximum allowed codepoint.

I think this is better, yes. It's matching HTML's &#0; , not
ECMASCript's \u0000, and that sounds right to be but I can't give
concrete reasons.

I think you might want to address escaped surrogate[1] too. Either spec
one or another, or mark it as an issue or undefined.



[1] http://lists.w3.org/Archives/Public/www-style/2012Jan/thread#msg536


Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

Received on Wednesday, 24 October 2012 01:18:03 UTC