Re: [csswg-drafts] [css-scrollbars] Add to Scope section that we intend not to spec WebKit pseudo-element approach for reasons

I re-read the reasons [from the W3C Wiki](

> Why not pseudo-elements?
> Scrollbars are more like text-decoration than they are things like ::before/::after, or ::first-letter or ::first-line.
> Just as we don't have separate pseudo-elements for ::text-underline ::text-overline ::text-strike-through, it doesn't make sense to have separate pseudos for scrollbars or scrollbar parts!

With all due respect, I can't agree with this. Is text decoration really a separate interactive control different part of which have different action when user interacts with them, as a scrollbar is? Scrollbar is a much more complex thing than just a decoration, it's a combination of two distinct functionalities:
- _indicator_ showing both relative size of the visible area to the whole scrollable content and its current position within that content;
- group of _visual controls_ to adjust the scrolling position (usually a draggable handle, clickable areas before and after it for quick navigation, and arrows for fine control).

In CSS, there is no direct analog for this. The closest CSS analog for the scrollbar behavior I can figure out is setting different `pointer-events` values for the element and its pseudo-elements, making them react differently to the user's input — and it seems impossible without pseudo-elements.

Closer analogs to scrollbars can be native HTML controls like `<input type="range">` (it even looks similar to scrollbar on many platforms!). The look of such controls in all known implementations is customizable via pseudo elements (though vendor-prefixed and yet not standardized).

So if the decision to restrict the control over the scrollbar appearance to repainting it in IE5.5 style was based on the assumption of scrollbar as a decoration, I would strongly oppose to it. Scrollbar is definitely not just a decoration, and it can't be truly customized without separate addressing to its completely functionally different subparts.

GitHub Notification of comment by SelenIT
Please view or discuss this issue at using your GitHub account

Received on Thursday, 4 January 2018 14:17:34 UTC