search

w3c / uievents

UI Events
https://w3c.github.io/uievents/
Other
145 stars 52 forks source link

Standardize layerX/layerY on MouseEvent #135

Closed dtapuska closed 1 year ago

dtapuska commented 7 years ago

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

dtapuska commented 7 years ago

@foolip @garykac

smaug---- commented 7 years ago

oh, they aren't in https://drafts.csswg.org/cssom-view/#extensions-to-the-mouseevent-interface

foolip commented 7 years ago

Is the returned value also interoperable? It looks like it's not an alias of anything else, so maybe it's complicated?

mustaqahmed commented 7 years ago

Looks like in Firefox, layerX/layerY have meaningful (non-zero) values only for MouseEvents and its descendants. For all other UIEvents, the values are always zero.

Here is a quick demo. It checks the following events: blur, focus, focusin, focusout, input, compositionstart, compositionupdate, keydown and keyup.

So, any sites relying on these fields for non-MouseEvents should be either rare or non-functioning.

Go ahead with standardization then?

foolip commented 7 years ago

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.

WebReflection commented 6 years ago

Dear all, is there any update on this? layerX and layerY are essential to simplify drawing on canvas and/or DOM elements used as drawing surface.

Thanks for moving eventually forward.

emilio commented 2 years ago

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 https://github.com/webcompat/web-bugs/issues/94500 we should add outer <svg> as well I guess).

@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.

mfreed7 commented 2 years ago

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 <svg> as well I guess).

So two questions:

  1. What's the use case? It would seem that the definition/behavior changing might actually affect how this API gets used, and how useful it actually is. No?

  2. If we end up changing from something related to layerization to something related to containing blocks, should the name change? Maybe containerX/containerY?

chrishtr commented 2 years ago

In Gecko, we use the closest abspos containing block or scrolling box (and per webcompat/web-bugs#94500 we should add outer <svg> as well I guess).

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 <svg> elements) are there because PaintLayer was a required part of the old compositing system (that system is now gone as of Chromium 96). Various of these cases are instances of what we call the "fundamental compositing bug". We have not yet fixed that bug, since we decided to decouple it from CompositeAfterPaint, but plan to fix it soon.

Once that bug is fixed, the Chromium behavior will be that layerX and layerY refer to the "containing element which is a stacking context, is positioned, or paints in the positioned phase of the paint spec (see w3c/csswg-drafts#2717). That definition seems pretty good, and simpler/more consistent than "abspos containing or scrolling box". @emilio WDYT? Will that definition work for you?

smfr commented 2 years ago

Do we have any usage data for layerX/layerY? It would be useful to know if we need to keep it around just for compatibility, or whether authors find any utility in it.

smfr commented 2 years ago

Maybe this? https://chromestatus.com/metrics/feature/popularity#UIEventLayerX

chrishtr commented 2 years ago

I loked at the code; it's this one: https://chromestatus.com/metrics/feature/popularity#V8MouseEvent_LayerX_AttributeGetter

7% of all page loads.

emilio commented 2 years ago

@chrishtr that definition sounds good to me.

chrishtr commented 2 years ago

@emilio cool, thanks.

After some offline discussion with @progers, he added a comment pointing out the connection as well. So far there are patches out to fix Chromium issue 370604 for canvas and video. Hopefully soon we can fix all of it, including svg and some weird corners of overflow scrolling.

chrishtr commented 2 years ago

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.

emilio commented 2 years ago

@chrishtr are there WPT tests for those changes?

chrishtr commented 2 years ago

@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.

chrishtr commented 2 years ago

Update: I was able to ship the proposed interoperable behavior in Chromium 102. As a reminder this is:

The x and y offset from the containing element which is a stacking context, is positioned, or paints in the positioned phase of the paint spec (*)

(*) w3c/csswg-drafts#2717)

Next up is WPT tests and spec text. Patches welcome for that, otherwise I'll try to find time to do it.

garykac commented 1 year ago

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:

chrishtr commented 1 year ago

"containing element" -> DOM ancestor

"stacking context": https://drafts.csswg.org/css-position-3/#stacking "positioned": https://drafts.csswg.org/css-position-3/#positioned-box "positioned phase": https://drafts.csswg.org/css-position-4/#painting-order (step 11-14)

"paints in the positioned phase as defined in the Paint Spec": this is step 11-14 from above

garykac commented 1 year ago

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.