- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 17 Apr 2014 11:11:58 +0100
- To: James Craig <jcraig@apple.com>
- Cc: TAG <www-tag@w3.org>, Shane McCarron <shane@aptest.com>
On Wed, Apr 16, 2014 at 9:09 PM, James Craig <jcraig@apple.com> wrote: > On Wed, Apr 16, 2014, Anne van Kesteren <annevk@annevk.nl> wrote: >> Not really, they're basically adding a layer of difficulty in figuring out what it all means later. > > I don't think "adding a layer of difficulty" is a fair synopsis. Something like Indie UI does seem like a good thing to have. However, given how well we have documented fundamental concepts such as hit testing, mouse events, focus, scrolling, and now touch and pointer events, adding a layer of abstraction seems troublesome. Without a solid grasp of the foundation, it's unclear where these should be dispatched relative to the others, how setting an event's canceled flag affects processing, etc. Akin to adding something like <template> to HTML before we knew the design of its parser. So as to Domenic's question of how we should deal with UI events... We need to document the core algorithms. Given some system "cursor" task, you adjust for the browsing context's viewport, you hit test on the render tree, you get the corresponding element in the DOM, you calculate the various event property values, you dispatch one or more events as appropriate. If that's too abstract, consider whether or not mousemove and mouseover in http://www.w3.org/TR/2013/WD-DOM-Level-3-Events-20131105/#h5_events-mouseevent-event-order can happen in the same task. Now combine that with pointer events. Or consider interaction of click and focus. -- http://annevankesteren.nl/
Received on Thursday, 17 April 2014 10:12:25 UTC