W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

[csswg-drafts] [cssom-view] Behavior of MouseEvent.offsetX/Y with inline elements is inconsistent across browsers (#5659)

From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
Date: Fri, 23 Oct 2020 21:21:46 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-728531052-1603488105-sysbot+gh@w3.org>
noamr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom-view] Behavior of MouseEvent.offsetX/Y with inline elements is inconsistent across browsers ==
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:
- Fix the issue in Blink/WebKit to match the spec (I am in favor in this, but not too familiar with the web-compat implication)
- Change the spec and Fix Gecko, maybe create an alternate API to retrieve the offsetX/Y for an inline-element

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5659 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 October 2020 21:21:48 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC