Re: Changes to DOM3 Events Key Identifiers

Hi,

I really really don’t see the benefit of that change. It only 
complicates things because it looks similar to a JS-string encoded 
character but is not actually one. I.e., "\u2018" does not equal 
"\\u2018". By introducing a backslash, I can already see people getting 
confused by this, writing:

   if (event.key == "\u2018")

instead of

   if (event.key == "\\u2018")

I know I often forget to double-escape the backslash (especially when I 
write regular expressions in strings :)), and then scratch my head over 
why it doesn’t work.

Additionally, using \u gives the impression that it is an encoded string 
character, but that is not the case. People are in my experience having 
trouble realising the difference between serialisation and the actual 
character (e.g. they think that .nodeValue of a textnode containing & 
will return & instead of &). I think introducing this ‘encoding in a 
string value’ does not help people.

Why would the new syntax be more intuitive than the old one? Just 
because one implementor says they got author feedback about this? Well, 
hereby I give you the feedback that as an author I do not ‘like’ the 
UTF-16 escaped character string :). I think it’s nicer to use the 
U+-notation, that is also used all over the place in specifications, web 
logs, the windows character map, etc. Contrary to that, the JS syntax is 
not familiar to me at all, I never use the JS-\u-notation, I encode the 
files as Unicode and insert the actual characters, which makes the 
strings readable.

Also what about characters outside the 16-bit planes? You say escaped 
*UTF-16* character string. Does that mean for the U+10000 character, the 
resulting string will instead be \uD800\uDC00? In this case, I 
definitely think the latter is much more complicated.

And of course there is also the matter that here you are changing an 
existing property which is referenced in a REC specification (SVN Tiny 
1.2). Because you do not really break backwards compatibility as you 
change the property name as well, this could be acceptable, however I 
can see no arguments for making such a change.

To be clear, I do not consider “based on content author and implementer 
feedback” to be a well-founded argumentation to justify such a change 
:). I hope here I *did* provide some concrete reasons why this change is 
*not* a good idea. Especially given the confusing 
double-backslash-escaping described above, I do not think the current 
change was well thought-through by those who gave the feedback.

If you would really want to make things easier, you could not return a 
key identifier but the character itself so you can compare it directly. 
E.g.:

   if (event.key == "\u00A9")

or

   if (event.key == "©")

~Laurens

Op 30-10-2009 8:32, Doug Schepers schreef:
> 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
>


-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Backbase employee; www.backbase.com