- From: Jonathan Kew <jfkthame@googlemail.com>
- Date: Thu, 25 Oct 2012 19:17:42 +0100
- To: www-style@w3.org
On 25/10/12 18:26, Tab Atkins Jr. wrote: > On Thu, Oct 25, 2012 at 10:16 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> Looks like WebKit recently checked in a patch [1] that does some sort of >> case-insensitive stuff on variables, via lowercasing them and then comparing >> lowercased versions. >> >> It's not quite clear to me what lowercasing algorithm it's using; at first >> glance it's passing UTF-16 code units one by one to a function that expects >> to get 32-bit codepoints. But maybe that's just me misreading the code. >> >> In any case, whatever it's doing doesn't sound like anything we've discussed >> on this list, since, again if I read the code right, it'll treat I (U+0049) >> and İ (U+0130) as equal. >> >> Can we come to a decision on this before UAs start shipping random gunk like >> that and causing backwards-compat problems? :( >> >> -Boris >> >> [1] http://trac.webkit.org/changeset/131313 > > We're not shipping variables yet, don't worry. I am aware of that > bug, though I didn't dig deep into the review. It was intended to > just add ASCII-case-insensitivity. As noted in the recent thread on "Case sensitivity of user-defined identifiers", it appears that Webkit already does more-than-ASCII-case-insensitivity (probably simple Unicode case-folding) in certain situations (user-defined HTML attributes, as in document.body.setAttribute("â", true); document.body.getAttribute("Â"); was the specific example mentioned) where it might not be expected or standardized. So I think Boris was justified in expressing some concern at what might be on its way... JK
Received on Thursday, 25 October 2012 18:17:02 UTC