- From: Phillips, Addison <addison@lab126.com>
- Date: Mon, 9 May 2011 13:52:04 -0700
- To: fantasai <fantasai.lists@inkedblade.net>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
(personal response) > On 05/09/2011 12:53 AM, Koji Ishii wrote: > > I’ve got some more feedback. It looks like this issue is hard to get > > into conclusion in a week or so for me. > > I don't think that applying NFC or NFD normalization is appropriate for text > content. I believe the last round of discussions around normalization seemed to > make that very clear, to me at least. I agree that automatically normalizing pages and stylesheets as part of processing them is not appropriate. Normalizing identifiers is potentially a different issue: they aren't visible to users and defining proper matching behavior that meets user expectations (i.e. that may be consistent with Unicode normalization) seems potentially useful. Please note that my summary's "recommend that users save documents in NFC" is consistent with current recommendations of the I18N WG and others. For most languages, using NFC is actually the "default" behavior and in the main it is the right approach the normalization problem for non-normalized content. Any discussion of normalization, though, needs to take the various details into account and present them clearly for users. > > I think the question before the i18nWG right now is the one I posted last month: > http://lists.w3.org/Archives/Public/www-style/2011Apr/0196.html > I agree. However, I wanted to cover the other options listed in my summary. The problem is that the different approaches to late normalization all have potential to either confuse users or be complex to implement in a robust manner (or both). I'm not sure I agree with your analysis of NFC, but full-file normalization is a non-starter. We may still recommend parse or compare-time normalization (the former looks iffy, since it's pretty close to normalization of the file itself and its impact would be difficult to isolate). For me, I guess the issue comes down to: if nothing else in the HTML/CSS/JS edifice does normalization, are we really hurting anyone by making CSS Selectors consistent with that? Doing nothing (with a health warning for users who use affected languages) has the least impact on developers, is apparently "robust enough", and is consistent. Putting normalization into, say, ID comparison probably isn't the performance problem some allege and probably isn't as complex as some have alleged. But it does require the all CSS and JS implementations to embed a normalizer and handle the issue. And it is at variance with current practice. Addison
Received on Monday, 9 May 2011 20:52:37 UTC