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>wrote:

> Siterer Masayuki Nakano <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