| Summary: | Remove layerX and layerY on mouse events | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> | ||||
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED WONTFIX | ||||||
| Severity: | Normal | CC: | ahmad.saleem792, andrea.giammarchi, annevk, aphplix, aroben, jchaffraix, mathias, mrobinson, priyajeet.hora, sam, simon.fraser, syoichi, zcorpan | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Mac | ||||||
| OS: | OS X 10.5 | ||||||
| Bug Depends on: | 69951, 70051, 70052, 86264 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Created attachment 102017 [details]
Proposed fix: Match Firefox's behavior.
Comment on attachment 102017 [details]
Proposed fix: Match Firefox's behavior.
I'd prefer to just remove layerX/layerY. Can you mail mozilla folks and see if they'd agree with this?
Comment on attachment 102017 [details] Proposed fix: Match Firefox's behavior. > I'd prefer to just remove layerX/layerY. Can you mail mozilla folks and see if they'd agree with this? I have discussed briefly about this path on Mozilla's #content channel and the answer was mixed (we lack data to say if it is safe to do so). Filed https://bugzilla.mozilla.org/show_bug.cgi?id=674292 about removing the support on Mozilla side, we will see how it unfolds. Holding the review until we have better visibility. It looks like Mozilla is fine with deprecating layerX and layerY then removing them after some time. On our side, removing them will involve changing 3 APIs that are exposing those 2 properties to the outside world: Mac (objc), Win (COM) and Chromium. I talked with Darin Fisher who is fine with a removal on Chromium side. Not sure about the policy for the 2 others' APIs.
quick consideration for both you and Mozilla folks.
We are in an "online game through canvas" era and with complex/floating/positioned layouts it's nearly impossible to understand where a *touch* on the screen has been fired in *canvas* *coordinate*, where x=0,y=0 is the top-left corner of the touched canvas.
AFAIK, there is no standard way to understand the touch/click inside a generic DOM element and if you guys remove layerX and layerY it would be really nice if you can introduce at least something like:
document.getElementPagePosition(HTMLElement)
// returns {pageX: 20, pageY: 738}
So that at least developers can subtract these coordinates accordingly with touch/mouse pageX/pageY coordinates and calculate the difference in the target to simulate the intention of layerX and layerY
If you see the "mess", as example, jQuery.offset() method is:
https://github.com/jquery/jquery/blob/master/src/offset.js
you can realize such task is one of the most overcomplicated at least I know in a DOM context.
Thanks for your patience and Best Regards,
Andrea Giammarchi
Did you try event.offsetX/offsetY? There's discussion in the standards bodies about mapping points between the coordinate spaces of different elements. WebKit already has window.webkitConvertPointFromPageToNode/webkitConvertPointFromNodeToPage. Simon I am not sure I get the point then ... is it about being standard and well defined or just about not being well defined ? AFAIK Mozilla does not support offsetX and offsetY https://developer.mozilla.org/en/DOM/Event/UIEvent/MouseEvent Also I wonder if these are exposed through Touch events as well and accordingly with W3 Touch Interface these are not. Could you give me some more info about this window.webkitConvertPointFromPageToNode and who's gonna implement it as well and when/if it is going to be standard? Many thanks These attributes are exposed through the COM API on Windows. I don't think anyone actually uses that part of the API, so removing them should be safe. But it would be even safer to rename the functions to "unused1" and "unused2" (keeping the same arguments as today), to preserve ABI compatibility. Sam, I heard you are the one to ask for an ObjC API removal question. Here is the problem: layerX / layerY are exposed through the ObjC API which means that we would need to remove them from the API too. The API is in @interface DOMUIEvent (see Source/WebCore/bindings/objc/PublicDOMInterfaces.h). What would be the best course of action for that? Thanks! Sam, ping about a question on the obj-C API removal policy. Thanks! (In reply to comment #10) > Sam, ping about a question on the obj-C API removal policy. Thanks! We would probably need to start by marking them deprecated, as they are public API. That step would be acceptable if we want to remove them. layerX/Y are supported in Firefox, Chrome & IE. They have been supported for many years and work as expected and as documented. As far as I can tell from the test results posted here the only failure was with Transformed content? I can't see the justification for the removal of useful perfectly working cross-browser compatible functionality with no equivalent functionality to replace it. I use layerX/Y extensively and have done so for many years, I'm sure that I can't be the only person who will be caused massive problems by the removal of these properties. just to clarify, in IE the properties are named x/y but they have the same functionality. Documented where? Please provide URLs. Mozilla documentation is here: https://developer.mozilla.org/en/Document_Object_Model_(DOM)/event.layerX https://developer.mozilla.org/en/Document_Object_Model_(DOM)/event.layerY which states that when the event occurs inside a positioned element the returned value is "relative to the top left of the positioned element". MSDN documentation for x/y is here: http://msdn.microsoft.com/en-us/library/ff974658(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/ff974659(v=vs.85).aspx which states that the values of the properties are the coordinates of the mouse pointer, "relative to the last positioned ancestor element". MSDN documentation for layerX/Y cross-browser compatibility is here: http://msdn.microsoft.com/en-us/library/gg130967(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/gg130968(v=vs.85).aspx Further MSDN documentation detailing layerX/Y in IE9 is here: http://msdn.microsoft.com/en-us/library/ms530302%28VS.85%29.aspx The point is that there is no W3C standard for layerX (or x). CSS OM View does not describe the 'x' property, despite what the MS documentation says. So what is the W3C standard equivalent of layerX then? There isn't one, that's the point. If you think it's needed, you should argue for it in what-wg. > I can't see the justification for the removal of useful perfectly working cross-browser compatible functionality with no equivalent functionality to replace it. I don't think you can call layer{X|Y} cross-browser as: 1) IE used to not support the property as-is (it was called x / y) but just started supporting it with IE9 (http://msdn.microsoft.com/en-us/library/ms530302%28VS.85%29.aspx) 2) Our implementation has been broken for some times: we don't return the same results as FF in non-simple cases (like add zoom-factor, overflow / opacity layers, transforms ...) jQuery and dojo have found some replacements due to our warnings but I don't know what they used. > The point is that there is no W3C standard for layerX (or x). CSS OM View does not describe the 'x' property, despite what the MS documentation says. http://www.w3.org/TR/cssom-view/#dom-mouseevent-x seems to say that x is clientX? I concur with Simon, this should be brought to the WHATWG. jQuery and Dojo have not found a replacement, they have simply dropped layerX/Y from their normalized event objects. I can achieve most of my required functionality with offsetX/Y however offsetX/Y is implemented inconsistently across the browsers and is not implemented at all in Mozilla. x/y in IE may have different names but they are the same properties as layerX/Y and therefore the layerX/Y functionality is present and consistent in the majority of current browsers. For the record, we have decided to remove the warning for several reasons: * we need to assess the web-compatibility issues. * we need to engage the standard bodies to get a replacement. See bug 86264 for more context. WONTFIX given these got standardized. If there's still a need to adjust them because our behavior doesn't match the specification, that's best done as a new bug I think (and hopefully with plenty of WPTs for the various edge cases). |
MouseRelatedEvent::receivedTarget() has this comment: // Adjust layerX/Y to be relative to the layer. // FIXME: We're pretty sure this is the wrong defintion of "layer." // Our RenderLayer is a more modern concept, and layerX/Y is some // other notion about groups of elements (left over from the Netscape 4 days?); // we should test and fix this. I was not able to find a description of "layer" here, but it seems to refer to the parent positioned element. This is not necessarily the parent RenderLayer (since we make RenderLayers for opacity etc).