[css-scrollbars][proposal] New "better" proposition for scrollbars

[Nadya678]

Due to this preposition and fact that the ::pseudoelements cannot have :pseudoclasses described in spec of selectors.
button::after:disabled is equivalent of button:disabled::after I have new proposition for scrollbars.

These pseudoelements are applicable only for elements with set overflow:auto or overflow:scroll and are not inherited. The property overflow cannot be used for these pseudolelements due to recurency problem.

::vert-scroll - describes height, position, background color and other properties of Vertical Scrollbar
::horz-scroll - describes width, position, background color and other properties of Vertical Scrollbar

::horz-scroll-thumb - the thumb of horizontal scrollbar,
::vert-scroll-thumb - the thumb of vertical scrollbar

::scroll-grip - the gripper (if present) mainly for textareas

::scroll-up-active - the active button that scrolls top in vertical scrollbar,
::scroll-up-inactive - the inactive button with bottom arrow in vertical scrollbar,
::scroll-up-pressed - the active button that scrolls top in vertical scrollbar in pressed state.,

Additionally in the same manner:

::scroll-down-active 
::scroll-down-inactive
::scroll-down-pressed

::scroll-left-active 
::scroll-left-inactive
::scroll-left-pressed

::scroll-right-active 
::scroll-right-inactive
::scroll-right-pressed

The ::vert-scroll and ::horz-scroll shall have possible to set at least background, width/height, opacity, borders, visibility. the default position shall be position:relative. The default overflow shall be overflow:visible.

The buttons shall have possibility to set width and height, colors, background, borders, position including left, top, right, bottom, The detault positioning is position:absolute (relative to ::vert-scroll/::horz-scroll)

The thumb shall have possibility to set min-width/min-height, colors, backgrounds. borders (including border-radius).

additionally for all these pseudoelemts shall be possible to set display:none and visibility:hidden.

This model meets reality od scrollbar construction and meets CSS3 requirements for pseudocalsses and pseudoelements. There is possible to describe standard PC browser scrollbars and standard mobile browser scrollbars. If it is needed I can describe scrollbars with standard styles and there elements for you.

Btw: To think about:
::horz-scroll-thumb-pressed - the thumb of horizontal scrollbar if mouse down or touched,
::vert-scroll-thumb-pressed - the thumb of vertical scrollbar if mouse down or touched

::vert-scroll-thumb-inactive - has no adoption - the thumb is not present in the case. Thus without active/inactive suffix.

How do you think about it?

[SelenIT]

In fact, the current CSS Selectors Level 4 draft allows some pseudo-elements to have "user action" pseudo-classes after them (so things like ::first-line:hover are going to be valid). Browsers also widely support things like ::-moz-range-track:hover for their vendor-specific pseudo-elements created for native HTML5 controls like <input type="range">. The same approach can be used for the pseudo-elements for scrollbar parts, so making the names that long would be probably unnecessary.

Hovewer, like many other commenters before, in general I strongly prefer this pseudo-element-based approach for scrollbar customization, not the current IE5-like "repainting". The assumption that scrollbars are purely decorative things, "just like text-decoration underlines", which the current approach seems to be based on, doesn't seem a solid reasoning to me.

[Nadya678]

What the draft interfere with current webpages where p::first-line:hover means p:hover::first-line?

If the pseudoclasses will be permitted for pseudoelements, I guess for previous solution. But if p::first-line:hover will not be equivalent of p:hover::first-line the pages may start to display wrongly.

"NO" for IE5-based scrollbars.
Many commenters here also said NO for IE based solution.

"purely decorative things"

If they are a decorative elements, they should have 0 width but in Chrome, Firefox and IE they makes extra gap in the layout. They are decorative on mobile versions of browsers.

[SelenIT]

where p::first-line:hover means p:hover::first-line?

It doesn't. They never were equivalent. The CSS Selectors Level 3 spec effectively allowed the pseudo element to be only at the end of the selector:

Only one pseudo-element may appear per selector, and if present it must appear after the sequence of simple selectors that represents the subjects of the selector.

The elements of a document tree that are represented by a selector are the subjects of the selector.

so if the element represented by the selector — the subject of the selector — is a hovered paragraph, then the pseudo element can only follow the p:hover part, but never be inserted between p and hover. In fact, p::first-line:hover was simply invalid (though it was not very clear per grammar) and was treated as such in all browsers (AFAIK).

UPD: @Nadya678, I reworded my previous comment a bit to make it clearer that in general I support your pseudo-element based approach, not oppose to it:)

[Nadya678]

Yes, I retested IE11, Chrome 63 and Firefox 52, the p::after:hover is not supported. Thus I must edit my first post. I saw in past this behaviour but I cannot recall in whose browser.

[ExE-Boss]

Well, the Shadow DOM ::slotted(*) pseudo-element does allow being followed by one more pseudo-element, so special casing the ::scrollbar-* custom elements to allow having their own pseudo-classes wouldn’t be without precedent.

Also, I’m giving my NO to specing IE5 scrollbar colours and giving my YES to this.

[frivoal]

This seems like a duplicate of #1969. Can we close as duplicate?

[SelenIT]

To me, it looks more like a duplicate of #2009, which was closed despite some objections in actively upvoted comments. But I don’t mind keeping any issue open for tracking use cases that are difficult to cover with the currently chosen approach.

As such useful use cases, I’d mention distinct hover styles for the scrollbar track and thumb, rounded corners pf the thumb (Tweetdeck, one of the recent CSS-Tricks redesigns) and making scrollbar thumb visually consisent with other interactive elements (on CSS-Tracks, it was styled like the button, with gradient fill and pill-like shape).

In general, the “let’s give people the tool they ask for, but prevent overusing it by restricting it so much that it becomes nearly impractical” approach seems to be kind of premature optimization. The similar issue with the highly demanded :has() selector — basically disallowing it for the thing it was most needed for, the styling — made browser vendors not interested in implementing it for years. The alternative that devs had to resort to — jQuery-like JS solutions — likely had worse performance and usability implications than this restriction tried to avoid. I don’t want this happen to scrollbar styling too.

[bmathwig]

Windows 11 is introducing a new visual style and with it, new scrollbar designs that are intended to be consistent across both the desktop and the web. I agree with the resolution of #2009. Microsoft Edge (and subsequently any Chromium-based browser) will have these new scrollbars going forward on Windows.

@SelenIT It's not necessarily just about developers. As a browser product, we see lots of complaints from customers about web developers who have hindered their customers ability to use a web page by styling or removing the scrollbar. It is more important to keep an OS-consistent scrollbar experience for Users of a browser than to give a developer freedom to change the scrollbar to fit their designs.

I think we can all be open to broadening the scope of the scrollbar spec, but we should make sure we consider the user experience as well.