RE: DOM3 Events Keyflow

I think it would still be worthwhile to continue to explore methods of characterizing event flow for the purposes of attempting to unify browser differences even across multiple operating environments (say Opera on the Nintendo Wii, for example).

As Doug mentioned in our telecom, some operating environments may need to design a thin-client layer between what OS messages are generated and what events are dispatched to the web application.

I don't think we should throw up our hands at this point.

-----Original Message-----
From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Alexey Proskuryakov
Sent: Thursday, March 27, 2008 12:14 PM
To: Web API public
Subject: Re: DOM3 Events Keyflow



On Mar 27, 2008, at 9:04 PM, Doug Schepers wrote:

> I've made a trial schematic to get us started [1].  I've also
> modeled it in Graphviz, and I've included the Dot format file here
> (attached). Graphviz is free open source software [2], and the Dot
> format is really simple to edit.


  I've been looking at the diagram periodically for the last couple of
weeks, and I finally have some idea about what to say from a point of
view of someone who has touched this code in WebKit code quite a bit
recently.

  I think that possibly a better way to characterize event flow would
be to think of it in terms of default handlers, not state diagrams.
That would better match what browsers do (we don't really maintain
much state in WebKit, although some is definitely maintained by the OS).

  A state diagram necessarily
a) could only be valid for a single type of focused element, as they
all have different default handlers;
b) conflates very different notions of keyboard events and text input;
c) encompasses several layers of functionality (OS and browser);
d) omits important details about the events (e.g. what
preventDefault() does).

  As I have it in my head, there is really no order for input events -
e.g. textInput can be dispatched because of a mouse click. You even
cannot guarantee that  keypress always comes after a keydown that
caused it! One example: when pressing the key right to "1" on a German
keyboard layout twice, one gets keydown, keydown, keypress, keypress.
Also, keydown may be totally missing if text input comes from some
utility (such as a virtual keyboard, enhanced clipboard manager etc.).
On Windows, any process that sends a WM_CHAR message to a browser view
will generate keypress without a keydown.

  I wish I had realized this earlier, when there wasn't so much work
put into this diagram, sorry about that.

- WBR, Alexey Proskuryakov

Received on Thursday, 27 March 2008 22:38:17 UTC