- 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>
> 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:13 UTC