[css-ui-4] pointer-events should have a filtering capability

[astearns]

Once #4438 has the currently implemented version of pointer-events added to css-ui, we should take a look at the feature requests in https://wiki.mozilla.org/SVG:Pointer-events and our own issue list. One item on the Mozilla wiki is

Provide a way to filter which pointer events are intercepted by an element. For example, to specify that an element should intercept most pointer events, but not mouse wheel events. This would allow elements with fixed position to pass wheel events on to the elements below them.

There is also a request in #4499 to have a value that just stops events (instead of passing them through). I think it would be useful to combine these ideas and allow a CSS declaration that declares which events are handled, which are passed through, and which are stopped.

The particular case that led me to opening this issue is an overlay where we want it to respond to hover events, but have click events pass through to the element underneath.

[SebastianZ]

I believe pointer-events should rather have been introduced as some kind of JavaScript API as it defines the interaction with elements. But here we are now and the property is supported everywhere for a long time.

Therefore, it somewhat makes sense to me to extend that property to filter the events it handles. An important question is how fine-grained the control should be that authors have over events. E.g. does it make sense to allow hover events, pass through move events and stop any other events? Do people want to pass through pointer down events but stop pointer up events?
And which of those possibilities are better left to JavaScript?

Sebastian

[aeharding]

As a web developer, my use case is a simple css scroll snap carousel with left/right buttons on desktop.

(Example: https://snap.glitch.me/carousel.html)

If the user is hovering over the left/right buttons while attempting to scroll, it doesn't scroll the carousel. (This is worse if the buttons are touch friendly/bigger.) Even worse, on horizontal scroll views on a Mac, this causes horizontal scroll to be redirected to the document root which causes the browser to navigate (forward/back).

Workarounds I've tried:

1. Use pointer-events: none; and attach to document mousemove/click events to essentially reimplement interaction with JS. Obviously, this is not great for many reasons, and is flakey due to this Chrome bug
2. position: sticky can be (ab)used for the back/forward buttons when placed inside the scrollview. However, each click event inside a scroll view causes smooth scrolling to stop and/or stutter - badly on Firefox. (I've also not been able to override this behavior with e.preventDefault()

At this point, there's no good solution. This is made worse by there being no way to determine if the user is interacting with a touchpad or via a mouse - so I can't just remove the buttons if the user has a touchpad.

Solution

pointer-events: no-wheel; or similar.

Thank you for your consideration.