Summary: | Implement MouseEvent's x and y in terms of clientX and clientY | ||
---|---|---|---|
Product: | WebKit | Reporter: | Gérard Talbot <browserbugs2> |
Component: | DOM | Assignee: | Anne van Kesteren <annevk> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | annevk, ap, simon.fraser, syoichi, webkit-bug-importer |
Priority: | P4 | Keywords: | InRadar |
Version: | 420+ | ||
Hardware: | PC | ||
OS: | OS X 10.4 | ||
URL: | http://www.gtalbot.org/BrowserBugsSection/Opera9Bugs/Opera7EventXY.html |
Description
Gérard Talbot
2006-09-10 20:33:18 PDT
Hello, I reiterate that this bug is still happening, including in Safari 3.0.2 build 522.13.1. This bug may not be a serious bug (hence, I am lowering down priority from P2 to P4) since event.x, event.y are rather "rare birds" in DHTML-driven webpages but I assure you that Safari 2+ do not implement event.x, event.y correctly, that is by following the way its initial implementor (Microsoft IE) implemented it. Confirmed with r23751, sorry that it took so long! One minor comment: as of MSIE 7, the bottom right corner seems to have coordinates (99, 99), while the test expects (100, 100). I haven't tested with MSIE 6. Yes, you're right: 99x99 is correct. The image for the test case should have been 101 by 101 and then offer the 4 coordinates (0, 0), (0, 100), (100, 0) and (100, 100) so that the area 101x101 represent x-distance by y-distance. To cover a 0 to n dimension-distance, one needs n+1 pixels. Testcase code and image updated to reflect that missing pixel. The image has width="101" and height="101". Good catch, Alexey! Cheers! evt.x and evt.y now seem to be defined by W3C CSSOM View Module W3C Working Draft 22 February 2008 http://www.w3.org/TR/cssom-view/#the-mouseeventview-interface so following MSIE's DHTML object model may not be suited or recommended anymore.. References: ----------- "Sets or retrieves the y-coordinate, in pixels, of the mouse pointer's position relative to a relatively positioned parent element. (...) If the event firing element is relatively positioned, then the y-coordinate from the boundary of the element is returned. If the event firing element and all of its parent elements are not relatively positioned, then the y property returns a coordinate relative to the body element. " MSDN documentation, y Property (event, Event Constructor) http://msdn.microsoft.com/en-us/library/ms535164(VS.85).aspx " The y attribute, on getting, must return the value of pageY. (...) The pageY attribute, on getting, must return the vertical coordinate, as number of CSS pixels, of the position where the event occurred relative to the origin of the canvas. " CSSOM View Module, WD 22 February 2008 http://www.w3.org/TR/cssom-view/#mouseeventview-y and http://www.w3.org/TR/cssom-view/#mouseeventview-pagey Right now, Safari 4.0 final release build 530.17 does not comply with the MSDN specification nor with the W3C WD CSSOM View Module specification as it treats x and y properties like clientX and clientY (relative to viewport) properties and not as pageX and pageY (relative to canvas) properties. regards, Gérard Hello all, The CSSOM WD **_changed_** the definition of evt.x and evt.y: these values are now supposed to duplicate clientX and clientY. " The clientX attribute, on getting, must return the x-coordinate of the position where the event occurred relative to the origin of the viewport. The clientY attribute, on getting, must return the y-coordinate of the position where the event occurred relative to the origin of the viewport. The x attribute, on getting, must return the value of clientX. The y attribute, on getting, must return the value of clientY. " CSSOM View Module W3C Working Draft 04 August 2009 http://www.w3.org/TR/cssom-view/#dom-mouseevent-x MSDN on the other hand still claims evt.x and evt.y should return mouse pointer's offset from the closest relatively positioned parent. regards, Gérard Do we have any idea how common event.x and event.y are in the wild? Simon, evt.x and evt.y are pretty "rare birds". I'd be surprised if more than 1% of DHTML-driven webpages use x and y event properties. I'd be surprised if more than 0.01% of all webpages use x and y event properties. Gérard It seems we correctly implement these now, but we could tidy the code up. Pull request: https://github.com/WebKit/WebKit/pull/21633 Committed 271890@main (e0208f9d2075): <https://commits.webkit.org/271890@main> Reviewed commits have been landed. Closing PR #21633 and removing active labels. |