W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

RE: Changes to DOM3 Events Key Identifiers

From: Phillips, Addison <addison@amazon.com>
Date: Fri, 30 Oct 2009 17:11:34 -0400
To: John Cowan <cowan@ccil.org>, Doug Schepers <schepers@w3.org>
CC: Mark Davis �?? <mark@macchiato.com>, "www-dom@w3.org" <www-dom@w3.org>, "www-international@w3.org" <www-international@w3.org>
Message-ID: <C7A5719F1E562149BA9171F58BEE2CA41298694202@EX-IAD6-B.ant.amazon.com>
> Doug Schepers scripsit:
> 
> > 1) DOM3 Events implementations also update their Javascript
> engines to
> > be able to process the additional escape sequence (e.g. one of
> the ones
> > you mention above) in the same way they process the "\u" escape
> > sequence.  This is the better long-term solution, and I'd hope
> ECMA TC39
> > could be persuaded to add this to future ECMAScript specs.
> 
> I doubt it, given that such escapes are usually programmatically
> generated.
> In any case, ECMAScript is firmly committed to a 16-bit character
> model.
> 

ECMAScript's "firm commitment" to a 16-bit character model (i.e. UTF-16) is not the problem. Lack of support for supplementary characters (that is, those above 0xFFFF in Unicode), however, is a very real problem. No UTF-16 process can escape the fact that, even if one applies a short-sighted limit to BMP characters, a character may require more than one code point to encode. As long as it is clear that DOM3 Events key identifiers are a string containing possibly more than one code point (and potentially more than one character), the escaping syntax is just a detail of the language.

Addison
Received on Friday, 30 October 2009 21:12:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT