- From: <bugzilla@jessica.w3.org>
- Date: Fri, 13 Jul 2012 21:53:27 +0000
- To: www-dom@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17626 Travis Leithead [MSFT] <travil@microsoft.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needsReview Status|NEW |RESOLVED CC| |travil@microsoft.com Resolution| |WONTFIX AssignedTo|schepers@w3.org |travil@microsoft.com --- Comment #6 from Travis Leithead [MSFT] <travil@microsoft.com> 2012-07-13 21:53:26 UTC --- Historically the spec had mousemove as not cancelable, but sometime between 2002 (http://www.w3.org/TR/2002/WD-DOM-Level-3-Events-20020712/) and 2003 (http://www.w3.org/TR/2003/WD-DOM-Level-3-Events-20030221/events.html#Events-EventTypes-complete) this was switched to cancelable and has apparently been that way ever since. The term "mousemove" doesn't come up anywhere in the www-dom archives during that period either. So, the trail has gone cold trying to understand why the spec changed back then. In checking IE's behavior, we explicitly ignore the canceled state for hover, as has been observed. It does not appear to have other impact that we could readily see, though we didn't follow all code paths. I see the point of making every event that can be cancelable have some rational behavior when it is canceled, but then again, the spec already points out that this logic may not always hold true: file:///D:/DOM3Events/D3E/html/DOM3-Events.html#event-flow-default-cancel At this point, I'd rather not tweak the value in the spec unless there's a more substantive reason to change it. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Friday, 13 July 2012 21:53:28 UTC