- From: Travis Leithead <travil@windows.microsoft.com>
- Date: Thu, 27 Mar 2008 15:38:09 -0700
- To: Alexey Proskuryakov <ap@webkit.org>, Web API public <public-webapi@w3.org>
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