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

On Sun, 03 Oct 2010 03:13:54 +0900, Doug Schepers <schepers@w3.org> wrote:

> 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 hope so. Reviews from people with implementor experience would certainly  
be welcome, though I have tried to take into account both the implementor  
experience already published in e-mails and bugfixes, and comments on  
earlier attempts here! :-)

> 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?

I will note first that the specific calculation of and support for keyCode  
/ charCode is a very small part of the general chaos that cross-browser  
key events were - and one that isn't actually as messy as other parts of  
the overall model.

The algorithm is based on what browsers currently do (or seem to align on)  
and informed by known compatibility problems Opera has had (and often  
still has) with existing content, from about ten years of experience  
debugging websites and apps.

> 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.

The behaviour basically matches IE, Firefox, Chrome, Safari and Opera -  
all major browsers :).

Browsers that follow the spec's so-called 'conflated model': IE, Opera

Browsers that follow the spec's so-called 'split model': Firefox, Chrome  
(with one minor exception), Safari (with the same exception)

The spec documents existing implementations, and as such no browsers  
should *need* to make any changes to support this. (The only minor  
exception is keyCode for keypress events, where Gecko and WebKit disagree  
- Gecko sets it to 0 and WebKit sets it to the unicode code point. Spec  
follows Gecko.)

The compatibility risks lie not so much in this specific part of the  
specification, more in the overall model - for example how events repeat  
when keys are held down, which keys send keypress and which don't, when  
keypress is captured by an IME and when it isn't. The big picture has many  
details that are more risky than keyCode itself.

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

1) Real, tangible benefit: Backwards compatibility with existing  
implementations, and a guarantee that their old scripts will keep working  
in new implementations written according to DOM3 Events

2) Hypotethical benefit: the potential ability for content authors to  
distinguish and use platform-specific keys that would otherwise be  
reported as 'Unidentified'. Getting a virtual key code for a key the  
implementation doesn't know anything about is better than getting many  
events with event.key set to 'Unidentified', consequently being unable to  
distinguish specific unidentified keys.

-- 
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Received on Monday, 4 October 2010 04:07:51 UTC