-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[cssom-view] Behavior of MouseEvent.offsetX/Y with inline elements is inconsistent across browsers #5659
Comments
Do you have compelling examples for use cases where the specified behavior is better than what Chromium and WebKit happen to do? I'm pretty sure there are some, but examples will help us to distinguish between the two possible courses of action. Some more points:
|
Absolutely. Take for example the hover preview popups in wikipedia, the arrow appears close to the actual mouse hover point, relative to the anchor. |
I'm not sure if modern libraries try to work around this. |
I see. You mentioned elsewhere (e.g. here) that this is a common source of layout thrashing. If it isn't common libraries, is it that many sites apply workarounds? Would any of the common workarounds you've seen break if all browsers moved to the currently-specified behavior? If so, do those workarounds use UA sniffing to not do it in Firefox? |
The workaround, using I don't know about libraries that sniff for Firefox and use btw I didn't claim that this issue specifically was a common source of layout thrashing, rather that synchronous measurements can cause layout thrashing, and my hypothesis is that fixing some of these browser compatibility bugs can help reduce use of these synchronous measurement anti-patterns. I did see this several times in practice, including in my current project with wikipedia. |
I think the fact that this interop issue is only related to inline elements diminishes the compat risk quite a bit here, fwiw. And if Chromium / WebKit can change to be consistent regardless of the display type, that'd be awesome. |
I was surprised to find out that I did some investigation and found that a main contributor to that could be this line in old versions of jQuery. Apparently jQuery copies some of the mouse event props from the native event to the jQuery event, So Chrome UseCounter for offsetX/offsetY doesn't check actual usage in this case (and in potential many other cases), but some arbitrary library behavior. This behavior was fixed in jQuery 7 years ago. |
See https://drafts.csswg.org/cssom-view/#dom-mouseevent-offsetx
According to the spec, offsetX/offsetY of the MouseEvent should correspond to the target element's padding edge.
However, only Gecko conforms to that when it comes to inline elements.
This makes it so that getting the offsetX for e.g.
a
elements requires an additional computation, and only on certain browsers, and basically makes offsetX/Y unusable for inline elements.In the Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=1054515#c21 it is stated that web compatibility would be an issue if they decide to change this.
Currently the only way to compute offsetX/Y in a cross-browser way is to use potentially costly measurements such as
getClientRects
and subtracting them from the event's clientX/clientY.Some websites do this to avoid the cross-browser complexities.
I suggest one of the following:
The text was updated successfully, but these errors were encountered: