W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-scrollbars][use-case] Real world product usage (#1969)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Mon, 02 Aug 2021 09:02:12 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-890855726-1627894930-sysbot+gh@w3.org>
Whether few or many, browsers currently don't want to expose parts of scrollbars as pseudos. Here are a few assorted reasons:
* Elements (or pseudo elements) have a performance penalty. If the internal structure of a scrollbar is not exposed to the author, browsers are free to make them happen in any way they please, without creating a pile of DOM nodes. This is not equivalent to adding more properties. Those are not cost-less either, but having a whole DOM subtree for each scrollbar isn't an appealing proposition.
* Exposing *parts* of scrollbars (as pseudos) implies a particular structure to the scrollbar. The more parts, the more likely that the structure isn't actually universal across OSes. Just thumb and track is likely quite robust, but as soon as you get beyond that, you're likely to run into an OS where those parts don't exist, or worse, where they exist but are structured differently. The later is worse because it means author styles created with one platform in mind would have an effect on other platforms, but a different one, not necessarily sensible or even legible
* Would these pseudos be stylable with any amount of regular css? Would their default look-and-feel be created through regular css in the UA stylesheet? If the answer is yes to both, then we're limiting what native scrollbars can look like to what CSS can achieve today. If the answer is yes to the first and no to the second, we need to define how regular css applied to scrollbars interact with whatever magic gives them their native look, and that magic is likely not the same from one platform to another. If the answer is no to the first one, then we need to define exactly what works, what doesn't, and possibly what works-but-not-quite-the-same-way-as-elsewhere, and we'd still need to define the interaction with whatever magic gives them their native look.
* OS vendors and browser vendors (who are sometimes the same) attach a high importance to the usability of the system, which comes in part from a well tuned set of UI controls, for which they insist on consistency, as familiarity helps users figure out how to use the system. This means a high reluctance to giving authors the ability to change UI elements, and scrollbars are one of those. While site authors will frequently want to customize things to better fit their brand and be more distinctive in some way, this can be a disservice to the users if that makes their system less predictable / recognizable, etc. This tradeoff is certainly a matter of degree, but browsers are called user agents for a reason: if there is a tension between author and users, browsers tend to pick what they believe will serve users over what will serve authors.
* Even then, there is a recognition that authors do want more control over scrollbars than is available today. Ability to infulence the thumb/track color and the width is what we're starting with, and it's quite possible there will be more in the future, but so far, there is no browser vendor enthusiasm for a future that involves the ability to apply regular css properties to parts of scrollbars via pseudos

GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1969#issuecomment-890855726 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 2 August 2021 09:02:14 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:42 UTC