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
