Re: DOM3 Key events

Hi, Bjoern-

Bjoern Hoehrmann wrote (on 8/1/2007 10:11 PM):
> 
> Second, the Working Group agreed long ago to define a keypress event
> (and possibly a "longkeypress" event and legacy context information
> like .charCode and such), but not as part of the DOM Level 3 speci-
> fication, but rather as separate document. That is primarily so be-
> cause nobody has yet come up with specification text for them, which
> in turn is largely because some things are not particularily inter-
> operable about them. I believe Doug Schepers is the latest volunteer
> to work on this.

In light of further input by a large number of other groups, the 
decision to split this off into another spec was reversed.  The intent 
is now to integrate this all into Dom3-Events.  I'm working on this 
right now, which is why I'm coordinating with the implementors.


>>This behaviour is not something that should be used to standardise on  
>>as it has been designed with the goal of website compatibility rather  
>>than to be "nice".
> 
> There seem to be only three options: a) we do not standardize in the
> area, b) we standardize whatever is implemented, c) browser vendors
> change their browsers, probably sacrificing web site compatibility in
> the process.

I don't think A is a realistic choice.  We have this mess now because it 
wasn't standardized.

B is only possible if there is already interoperability, since anything 
else means that at least one browser will have to change; in fact, 
Oliver reports that WebKit is already changing in this regard.

As politically unpopular as it is, I think we should give a serious look 
at C; we should figure out what the scope of any possible damage would 
be (both in terms of raw numbers of pages, and in how badly they would 
be broken), and minimize that.

Pages can usually be changed, especially if we offer a coherent 
transition strategy (that is some sort of tutorial that explains how to 
get the functionality they need).    If we can get all vendors to work 
interoperably going forward, it's worth a small amount of legacy breakage.

So, realistically, the choice lies somewhere between B and C, where we 
specify the most coherent model from what browsers already do and what 
behavior pages rely on (which may not be exactly the same thing).


> As for your other points, is there anything in the specification that
> we absolutely must change, or that Apple would have to change in order
> comply with the specification where Apple is unlikely to do so?

They need keypress, which I agree should go into the specification.

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI

Received on Thursday, 2 August 2007 03:33:38 UTC