RE: [D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

Regarding the process of:

>>That's not how I thought this process is supposed to work.  I assumed that the process was:
>>(1) Write a draft proposal
>>(2) Have at least one vendor implement it to identify issues
>>(3) Test, goto (2) as needed
>>(4) Get agreement and release final spec.

Reworking something as fundamental as key events with only one implementation seems like you need more than one vendor. I recall implementing key events in the DOM2 timeframe on both Mac and PC before it was decided they would be out of scope for DOM 2. The separation of key and char is pretty clear – and trying to predict at “keydown” time what “char” will be generated for a “keypress” is nothing more than a guess. I also recall running into similar issues supporting key and char in Internet Explorer for Macintosh, in part because although the concepts map, the platform aspects of how the browser gets the key input from the OS differs.

http://msdn.microsoft.com/en-us/library/ms171536.aspx


https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html


The area of “command” shortcuts is handled differently on various platforms, and trying to tie into the DOM event stream might not be the best solution, particularly if any of the goal is to coexist with the UA platform’s model of exposing such functionality. On the high level, though, the browser knowing that “Expose a shortcut/accelerator key for ‘bold’ preferring “B” as the mnemonic might be enough information for a UA to expose the functionality without dealing with keycodes at all. If “bold” is defined as a keyword for some predefined set of operations, it might even be enough for the UA to also provide a voice shortcut for the “bold” command without any extra work.


From: garykac@google.com [mailto:garykac@google.com] On Behalf Of Gary Kacmarcik (?????????)
Sent: Tuesday, March 12, 2013 5:20 PM
To: Hallvord R. M. Steen
Cc: Masayuki Nakano; www-dom@w3.org
Subject: Re: [D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

On Mon, Mar 11, 2013 at 12:27 PM, Hallvord R. M. Steen <hallvord@opera.com<mailto:hallvord@opera.com>> wrote:
Siterer Masayuki Nakano <masayuki@d-toybox.com<mailto:masayuki@d-toybox.com>>:
On 2013/02/28 17:15, Hallvord Reiar Michaelsen Steen wrote:
I personally agree that it would be nicer to fix KeyboardEvent.char  and KeyboardEvent.key than adding yet-another-property with  KeyboardEvent.code. I guess IE10 implemented .char and .key as  spec'ed already though - we could probably ignore the Opera Presto  implementation as it's being discontinued and few developers  targeted their content at Opera, but if IE already shipped  something it's a lot harder to re-architect it :-(

I think that IE can change the behavior. The .key and .char have only
been implemented on IE. So, such state attribute isn't useful for most
web developers. And also, even if the change will cause something
trouble on a few web applications, such developers should change the
code for the latest spec. D3E is still "Working Draft".

Maybe, maybe not - we'd have to ask the IE team and try to survey if sites and apps have started using .key and .char.

That's not how I thought this process is supposed to work.  I assumed that the process was:
(1) Write a draft proposal
(2) Have at least one vendor implement it to identify issues
(3) Test, goto (2) as needed
(4) Get agreement and release final spec.

And it seems like we're still in the (2)-(3) stage right now (although I think we're pretty close to (4)).  Just because a vendor has released an implementation shouldn't mean that the spec gets locked down with regard to the details of that implementation. For historical context, WebKit had already implemented part of the 'keyIdentifier' attribute before it was completely removed in the 2010/09/07 rewrite of the DOM3 event spec - but changing the spec was the right thing to do because it wasn't completely baked at that time.

The spec is in far better shape now than it was then, but there are still some parts that seem a bit broken. Masayuki and a few others have been identifying areas where the spec needs more clarity:
* Keys that are not defined in the spec (how are browsers supposed to have a consistent implementation?)
* Sections which are underspecified and/or lacking examples
* The value of 'char' for non-printable key events
And I also have some concerns that I need to dig into about deprecating keypress (since AIUI the proposed replacement just tells you that *something* changed rather than letting you know what is being inserted).

I recognize that DOM3 has been going on for over 12 years, but the idea that this is a "legacy spec being standardised for information" is bothersome because I think that some of the problems that remain are minor, but will be rather hard to fix later if we bless the current version. And we risk another keyCode/charCode mess (albeit on a smaller scale) where there are subtle differences between the implementations. I'm not sure if I'm reading this correctly, but I get the impression that we're actively avoiding making edits to the DOM3 spec - even when relatively simple typos and errors are identified.


Personally, I'd like to see KeyboardEvents broken out into a separate document so that it could follow its own track without being tied to (or tying down) the rest of DOM3 or UIEvents. We're going to need all the KeyboardEvent information gathered into one document anyway.

-Gary