- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Mon, 18 Feb 2008 12:16:39 +0100
- To: Addison Phillips <addison@yahoo-inc.com>
- CC: public-webapi@w3.org, public-i18n-core@w3.org
Addison Phillips wrote: > 3. Add Unicode normalization as a requirement. > > The I18N WG notes that comparison of namespace prefixes, in order to be > reliable, require Unicode Normalization Form C. For more information, > see CharModNorm [2]. This specification cannot require the NSResolver object to perform Unicode Normalisation. The NSResolver object is defined as a black box in that only the input and expected output is defined. The internal processing, where string comparisons would be performed, is left entirely up to the implementer. This is because, as previously explained, the resolver is expected to be implemented by application developers (especially JavaScript developers), not user agents, and it would be unrealistic to expect such developers to adhere to the requirement. Therefore, the only other possible alternative would be to require the user agent to perform normalisation of the selector before invoking and passing the normalised prefix to the resolver. However, the rules for the processing of selectors is delegated to the Selectors specification, which, AFAICT, does not require normalisation to occur. In practice, browsers do not perform normalisation of selectors in CSS either and comparison is performed using non-normalised strings. If this specification were to require normalisation of selectors itself, it would create an incompatibility between selectors as used in CSS, and as used in these APIs. Such incompatibility is not acceptable. For normalisation to occur, it would require the CSS WG to address the issue in the Selectors specification, and for browser vendors to implement it for both CSS and these APIs, and any other affected languages. It would also require implementers of the NSResolver objects to expect prefixes to be passed in normalised form, which would potentially increase the complexity of NSResolver implementations, where prefixes containing affected characters are used. No change has been made to the specification in regards to this issue. Please let me know if you are not satisfied with this response. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Monday, 18 February 2008 11:16:57 UTC