W3C home > Mailing lists > Public > public-i18n-core@w3.org > January to March 2008

Re: [comments] Selectors-API

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 18 Feb 2008 12:16:39 +0100
Message-ID: <47B96917.1000000@lachy.id.au>
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:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 October 2008 10:18:53 GMT