[css-ui][pointerevents] Should the scrollbar should keep responding on scrollable elements with pointer-events: none?

[Sharcoux]

When using pointer-events: none on a scrollable element, it is unclear if the scrollbar should respond to click. If you read those bugs reports: https://bugzilla.mozilla.org/show_bug.cgi?id=1839481 and https://bugzilla.mozilla.org/show_bug.cgi?id=880671 , you will see that the behavior has already changed twice in Firefox. Currently it doesn't respond to click.

On Chrome, I didn't understand why yet, but I got different results in different cases, so I'm not sure about the current policy.

IMO, the scrollbar should respond to clicks even with pointer-events: none. This is because, if the dev doesn't want the user to interact with the scrollbar, they can hide it with, for instance, overflow: hidden. On the contrary, if they want to ignore the clicks on the scrollable container but still let the user interact with the scrollbar, they would be doomed. Anyway, showing a scroll bar that the user cannot use is probably a bad idea for accessibility.

Here is a concrete case that can serve as an example: https://stackoverflow.com/questions/76517363/scrollbar-is-not-clickable-in-firefox-when-using-pointer-events-none

Here is a working demo illustrating my point: https://codesandbox.io/s/scrollarea-wider-with-pointer-event-clthvw

[nt1m]

I think the scrollbar should not respond on elements with pointer-events: none, for 2 reasons:

• The scrollbar is part of the element
• Not every platform has space reserved for the scrollbar (macOS & mobile have overlay scrollbars) , meaning that being able to scroll the container would be dependent on the platform you're using.

[Sharcoux]

I think the scrollbar should not respond on elements with pointer-events: none, for 2 reasons:

The scrollbar is part of the element

While I agree that this is lexically correct, I don't see why this is a strong argument about what should be done here. Especially because:

1. If the scrollbar doesn't respond to clicks:

• It is unexpected and frustrating for the end user to have a scrollbar they can't interact with
• The dev has no way to make a component ignore mouse events but still be scrollable

2. If the scrollbar responds to clicks

• The UI would align with what is actually possible for the user to interact with
• If the dev really wanted the user to not be able to interact with the scrollbar, they could use scrollbar-width: none;

In the end, IMO, the benefits for the community seems clearly in favor of the 2nd option.

Not every platform has space reserved for the scrollbar (macOS & mobile have overlay scrollbars) , meaning that being able to scroll the container would be dependent on the platform you're using.

I don't see why this is related to the problem. The fact that the scrollbar is drawn aside or over the container doesn't change anything, does it?

[nt1m]

The fact that the scrollbar is drawn aside or over the container doesn't change anything, does it?

It does, if you have overlay scrollbars, your pointer needs to be hovering over the element for the scrollbars to show, and pointer-events: none disables all pointer events, including hover. So in the end you'd have no way to trigger the overlay scrollbar.

[Sharcoux]

Well, at least, that makes the UI match what the user really can do

[jonjohnjohnson]

Since a scroll container with pointer-events: none can have descendants with pointer-events: auto, which enable scrolling, I would prefer any visualized scrollbar to still/always respond. And separately we have scrollbar-width: none to explicitly remove scrollbar affordances.