Re: [DOM3Events] keyCode and charCode [ISSUE-133]

Hi, Hallvord-

Thanks for writing this up.  It's a nice, relatively clean model.  If we 
decide to define keyCode and charCode, this will be a useful starting point.

I have three follow-up questions:

1) My main concern, which I stated before, is that there is an enormous 
amount of legacy content out there, which often compensates for the 
differences between browsers, using brittle methods like browser 
sniffing or other heuristics; if the browsers are changed to be 
consistent for keyCode and charCode, then that content will break.  Have 
you tested this algorithm on a reasonably large and representative 
corpus of web content, across platforms, to determine the negative 
effects changing existing browsers would have?


2) Which browsers, and browser versions, does this behavior match?  Any 
change wouldn't be retroactively supported in older implementations, so 
it would have to match at least one major implementation to be of any 
utility.


3) What benefit does this have for content authors?  Where does it 
provide functionality for them that the new key model doesn't?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Hallvord R. M. Steen wrote (on 9/22/10 2:44 AM):
> On Fri, 17 Sep 2010 12:14:45 +0900, Hallvord R. M. Steen
> <hallvord@opera.com> wrote:
>
>>>>> Please specify keyCode and charCode, even if marked as 'obsolete'.
>
>>> very difficult (if possible at all) to specify keyCode and charCode
>>> in a way that would be consistent across browsers, or even the same
>>> browser on different platforms.
>
> Looked at this again..
>
> AFAIK, charCode is trivial to specify. In a keypress event that will
> generate character input, set charCode to the Unicode reference number
> (code point) of that character. (Basically, event.charCode =
> event.char.valueAt(0)). In keydown/up, set charCode to 0.
>
> This is neither complicated nor bad for i18n - as far as I can tell -
> and should go into the spec without further ado.
>
> That leaves us with event.keyCode - which *is* already specified in the
> KeyEvent interface! [1] But the spec doesn't specify how to set it to a
> suitable value. Now, this is also trivial to define if we say something
> like "Set keyCode to the virtual key code value returned by the
> operating system" and leave it at that.
>
> However, I think we might go a bit further than that - to benefit
> implementations running on peculiar platforms that don't report typical
> virtual key codes. It's somewhat challenging to defer to the virtual
> keycode of the operating system where it's correct and harmless
> compat-wise to do so, and yet suggest some rules for converting the key
> code to something that's going to be fairly web compatible..but I'm
> attaching a suggested spec and propose this is integrated into the spec.
>
> Criticism from developers welcome!
>
> [1]
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-keyCode
>

Received on Saturday, 2 October 2010 18:13:57 UTC