- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Thu, 29 May 2014 23:04:09 +0000
- To: Philippe Le Hegaret <plh@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Gary Kacmarcik (Кошмарчик) <garykac@chromium.org>
- CC: "www-dom@w3.org" <www-dom@w3.org>
From: Philippe Le Hegaret [mailto:plh@w3.org] >On Wed, 2014-05-28 at 18:26 +0200, Anne van Kesteren wrote: >> On Wed, May 28, 2014 at 5:51 PM, Gary Kacmarcik (Кошмарчик) >> <garykac@chromium.org> wrote: >> > On Wed, May 28, 2014 at 7:50 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> >> What happened? What's the plan for fixing DOM Level 3 Events? >> > >> > The plan for fixing D3E is that we're working on addressing all the >> > outstanding bugs for D3E. These FPWDs for the 'key' and 'code' >> > tables are required so that we can normatively refer to them in the >> > next D3E draft (planned for sometime in June). >> >> I'm interested in hearing a plan around solving >> http://lists.w3.org/Archives/Public/www-tag/2014Apr/thread.html#msg26 >> as that's the single biggest bug in the UI event picture today. >> They're not defined in terms of the event loop. Are mousedown and >> click in the same task? Do they perform a single hit testing >> operation? Etc. >> >> You can't really bolt that on top of DOM Level 3 Events and keeping >> its legacy-style way of describing event objects around is not really >> helping anyone. > >I'll admit that the current plan/direction around DOM3Events is unclear to me at this point >and I'd like to understand it better before approving the publication of the two documents. >It happened that I was looking at DOM Events tests over the last week end and the overlap >with the DOM tests was confusing. Plan is to fix the existing overlap between DOM4 and DOM3 Events -- the current editor's draft reflects some work in that area--there's still more to go though. If describing events in terms of the event loop is blocking for CR entry, then we can attempt to fit that in--it might require some work, but I wouldn't say you can't do it. Personally, I don't believe that it is required to prove that mouseevents etc. work interoperably. I understand that it's nice to have if you are writing a browser and there are subtle differences in timing and what can and can't happen between events firing, but I don't think these would hold up the recommendation from proceeding, and they would be very tricky to test (but perhaps not impossible). >I wasn't aware about the split around the keyboard event either (or at least, I don't >remember it). If someone is willing to point me to the right thread to look at, that would >help me and avoid repeating again. The keyboard event is not split. The only thing we've done (and proposed doing) is moving the large tables of key and code values to their own document--it makes the spec much easier to read and properly isolates the tables. Hope this helps.
Received on Thursday, 29 May 2014 23:04:47 UTC