- From: Mark Davis ☕ <mark@macchiato.com>
- Date: Fri, 30 Oct 2009 09:22:52 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: www-dom@w3.org, www-international@w3.org
- Message-ID: <30b660a20910300922h7ec2a8s8d0d08321ed6a873@mail.gmail.com>
I want to point out that Unicode code points can go up to hex 10FFFF. The standard for \u is exactly 4 digits, so that one can intermix with characters and know where it terminates. There are a couple of schemes that are used to extend this to up to 6 digits, and still know where to terminate. \UXXXXXXXX - C++, ICU \UXXXXXX - C# \u{xxxxxx} - Ruby There needs to be some mechanism for extending to 6 digits. It would be best to use one of the above rather than a new one. (My personal favorite is Ruby's.) Mark On Fri, Oct 30, 2009 at 00:32, Doug Schepers <schepers@w3.org> wrote: > Hi, Folks- > > (BCC to potentially affected groups: w3c-html-cg, public-webapps, > public-i18n-core, wai-xtech, www-svg, public-forms, public-xhtml2, > public-html@w3.org, www-voice... please forward on to any relevant groups > or individuals I may have missed, especially outside W3C.) > > As editor of the DOM3 Events specification, I made what some may consider > to be drastic changes in the most recent drafts: > * I changed the syntax of the key identifier strings from "U+xxxx" (a > plain string representing the Unicode code point) to "\uxxxx" (an escaped > UTF-16 character string), based on content author and implementer feedback. > * I renamed the "key identifier(s)" feature to "key value(s)". > > I've mentioned these ideas before in DOM3 Events telcons, and finally > decided to do it, after first consulting with the I18n WG, who generally > approved of the scheme (though not without some comments about details that > will need to be addressed and resolved). > > The new string format should be easier to deal with for developers, and the > new name reflects some confusion I've encountered when explaining what "key > identifiers" are... the work "identifier" seems to evoke the concept of a > unique identifier for a key, when in fact what the feature does is provides > the most appropriate value given the state of keyboard modifiers and modes. > I have tried also to clarify this in the prose of the spec. > > We are aware that there may already be implementations and specifications > that rely on the previous string format and name (as well as links), back > from when this was a W3C Note, and we do not make this decision lightly, but > we do believe this is the right decision for a stable and internationalized > keyboard interface going forward. For those implementations and > specifications that need the previous functionality and name, you may be > able to reference the SVG Tiny 1.2 specification [2] instead, which does > include the old Key Identifiers feature more or less intact from the > previous definition, and is a stable W3C Recommendation. > > You can review the changes in the most recent Editor's Draft [1]. The > WebApps WG welcomes your feedback to the www-dom@w3.org list. This > specification is still a work in progress, though we do hope to go to Last > Call soon, so we are open to suggestions. (Note that the spec is mostly > feature-complete, so new event types and other changes may have to wait for > the next version, but send them on anyway.) > > [1] > http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keyset > [2] http://www.w3.org/TR/SVGTiny12/svgudom.html#KeyIdentifiersSet > > > Regards- > -Doug Schepers, on behalf of the WebApps WG > Editor, DOM Level 3 Events > W3C Team Contact, SVG and WebApps WGs > >
Received on Friday, 30 October 2009 16:23:33 UTC