-
Notifications
You must be signed in to change notification settings - Fork 52
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
Standardize layerX/layerY on MouseEvent #135
Comments
oh, they aren't in https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface |
Is the returned value also interoperable? It looks like it's not an alias of anything else, so maybe it's complicated? |
Looks like in Firefox, Here is a quick demo. It checks the following events: So, any sites relying on these fields for non-MouseEvents should be either rare or non-functioning. Go ahead with standardization then? |
Having them on MouseEvent might be web compatible for Gecko as well then, seems reasonable to try that first. If it doesn't work out for them, then putting them on UIEvent but returning 0 for non-MouseEvent instances might be a backup plan. In any event, trying to standardize something seems like a very good idea. |
Dear all, is there any update on this? Thanks for moving eventually forward. |
PaintLayer::location_ is relative to the containing block, not the parent layer. For a MouseEvent on a position: absolute element, we were adding the parent layer's location to a value that already included it, which doesn't make sense. The behavior of layerX and layerY remains quirky and not standardized. There is an open issue at w3c/uievents#135. It's unclear if the FIXME about ConvertToLayerCoords is still correct. Bug: 856525 Change-Id: Iba5bb7b2c955b4bd526597628cd789ff0eb42e90 Reviewed-on: https://chromium-review.googlesource.com/1195648 Reviewed-by: David Bokan <bokan@chromium.org> Commit-Queue: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/master@{#587202}
We should do this, lack of interop here is a bit unfortunate. Rather than depending on arbitrary layerization by the browser (which is, AIUI, what's going on in Blink and WebKit), we should come up with a more reasonable / interoperable definition... In Gecko, we use the closest abspos containing block or scrolling box (and per webcompat/web-bugs#94500 we should add outer @christr @mfreed7 @smfr would such a definition work for Blink / WebKit? That should be a reasonably-interoperable definition. It hasn't brought any other compat issues other than the one mentioned above to my knowledge, (which WebKit also suffers from), and the proposal of including outer SVG would fix. |
To fix juster-finance#15 for Safari and Firefox. `MouseEvent.layerX` is not standard (w3c/uievents#135 tracks standardizing it), but meanwhile this should make the behavior match on all major browsers.
So two questions:
|
In Chromium, the definition is "whatever causes a layout object to have a PaintLayer" (see here - all cases where kNoPaintLayer is not returned). Webkit is probably almost the same. Several of those (including Once that bug is fixed, the Chromium behavior will be that |
Do we have any usage data for |
I loked at the code; it's this one: https://chromestatus.com/metrics/feature/popularity#V8MouseEvent_LayerX_AttributeGetter 7% of all page loads. |
@chrishtr that definition sounds good to me. |
FYI we shipped most of the changes referred to in my comment from Dec 10, and I landed the last bit this week. If all goes well it will be in Chromium 102. |
@chrishtr are there WPT tests for those changes? |
No not yet. My plan is to try to ship it and if we can do that without compat issues, we can then add the WPT tests and bless the spec. |
These are non-standard properties, but if they are standardized it will be on MouseEvent, see w3c/uievents#135. Furthermore, it's only on MouseEvent that these properties ever return something other than zero. The apparent removal in Chrome 45 was caused by the move from UIEvent to MouseEvent in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=503276 Since MouseEvent inherits from UIEvent, we can ignore this prototype move in BCD, per our guidelines: https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines.md#apis-moved-on-the-prototype-chain
Update: I was able to ship the proposed interoperable behavior in Chromium 102. As a reminder this is:
Next up is WPT tests and spec text. Patches welcome for that, otherwise I'll try to find time to do it. |
I can update the spec with the definition for these attributes, but I don't know where to link into CSS for proper definitions for the terms that are used: Specifically:
Also, "of the paint spec" parses weird for me, so I must be misunderstanding something. Is this:
|
"containing element" -> DOM ancestor "stacking context": https://drafts.csswg.org/css-position-3/#stacking "paints in the positioned phase as defined in the Paint Spec": this is step 11-14 from above |
SHA: e47b95e Reason: push, by garykac Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I'm not completely happy that the CSS spec doesn't define a proper "positioning phase" since those step numbers could change as the spec is updated. But I'll follow up with them to see if they have a better way to export what we need. |
Being that layerX and layerY are available on all browsers for MouseEvent we should standardize it.
@smaug---- perhaps FireFox should move it from UIEvent to MouseEvent solely?
Edge, IE, Chrome all have it only on MouseEvent
The text was updated successfully, but these errors were encountered: