- 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