On 1/08/2007, at 7:11 PM, Bjoern Hoehrmann wrote:
Thanks for your comments. There are two things I would like to note.
First, the former DOM Working Group spend a good deal of effort on the
new events, their context information, and the key naming; we already
have implementations of them and other specifications require support
for parts of it. It's very late to make changes to them, and if there
are major issues, it might be best to split them completely into a new
specification.
Righto, as I said, I only sent this email as Doug had asked for my
input :D
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 wouldn't consider (a) an option :D
(c) is out of the picture, as no browser will make any substantial
changes due
to the large potential for widespread site breakage. Given the
choice WebKit (and I
imagine Firefox, Opera, etc) would choose to match a standard,
however that would
immediately become problematic if matching the spec caused sites to
break.
(b) is clearly best, but it is difficult as not all browsers match
each other exactly. The behaviour
that we have implemented in WebKit seems to provide the most
compatibility, and is largely
sensible. My main worry is IME handling, it seems particularly ugly
to use such an arbitrary
keyCode for keydown events that have been handled by an IM, however
not doing so causes
a number of sites to break (various google apps, a number of ajax-y
sites, basically any webapp
that likes to think reacting during a keydown is a good thing).
Ignoring the keyCode bludgeoning that we do during composition, etc I
feel that the WebKit
keyevent model is sensible, clear, and provides a high degree of
cross site compatibility, so would
be reasonable to use as the basis for a spec. In fact the keyCode
bludgeoning is the only
part that seems bad to me, it is unfortunate that it is necessary.
However I wrote our event handling model, so I am clearly biased in
this matter, so the
model should be examined by other independent bodies (preferably
including people
from the other major browsers)
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?
I am very concerned at the attempt to make composition events
masquerade as keyevents.
While providing DOM level composition events is indeed useful and
desirable, and would
be beneficial to IM aware sites, I feel it would likely introduce
worsen the experience of IM
users on non-IM aware sites.
Other than that, nothing has immediately struck me as being awkward/
wrong.
Cheers,
Oliver
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://
bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://
www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://
www.websitedev.de/
