- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 02 Feb 2009 17:40:05 -0800
- To: Andrew Cunningham <andrewc@vicnet.net.au>
- CC: "Phillips, Addison" <addison@amazon.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Mark Davis <mark.davis@icu-project.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>, "www-style@w3.org" <www-style@w3.org>
Andrew Cunningham wrote: > > > fantasai wrote: > >> >> Phillips, Addison wrote: >>> ... Both are semantically equivalent and normalize to U+00E9. I can send >>> either to the server in my request and get the appropriate (normalized) >>> value in return. Conversely, I should be able to select: >>> >>> <p>è</p> >>> >>> ... using either form. I might be returned the original (non-normalized) >>> sequence in the result. The point is that processes that are >>> normalization >>> sensitive must behave as if the data were normalized. Why is that a >>> contradiction? >> >> I think Boris's point is that we have a message from Andrew Cunningham >> http://lists.w3.org/Archives/Public/www-style/2009Feb/0033.html >> saying that form input data must not be normalized. This is incompatible >> with the idea that the browser can internally adopt NFC. > my thoughts have been changing as i reflect on each post. > > I still feel normalisation of selectors is important, but have doubts > about a browser normalising everything. I think the distinction is > between content and markup. Selectors blurs the distinction between content and markup. You can select on tag names, classes, IDs, attribute values, and, in various proposed selectors, even against element content. Here's another wrench to throw into the cogwork: what if I serve up text where each combining character is wrapped in a <span>? Also, because NFC is not closed under concatenation, adopting NFC also complicates things like .textContent, document.write, and any API-passing and comparison of strings that have been concatenated in JavaScript. ~fantasai
Received on Tuesday, 3 February 2009 01:41:00 UTC