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

The CSS Working Group just discussed `Real-world scrollbar usage`, and agreed to the following:

* `RESOLVED: With ack of the use-case, we still reject exposing a large set of pseudos for scrollbars (webkit-prefixed or otherwise)`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Real-world scrollbar usage<br>
&lt;TabAtkins> github:<br>
&lt;TabAtkins> florian: at a high level, both these issues are looking at what's in SCrollbars and saying "controlling width/color is nice, but we want way more, can we have a bunch of pseudos to control things"<br>
&lt;TabAtkins> florian: precisely how they justify it is a little different, the exact set they're asking for is a little different<br>
&lt;TabAtkins> florian: One is following the existing webkit pseudos, the other isn't<br>
&lt;TabAtkins> florian: But both are complaining they're too simple and they want access to the deep structure<br>
&lt;TabAtkins> florian: I believe we've already resolved not to do this, for several reasons<br>
&lt;TabAtkins> florian: Not least that scrollbars are UI and OSes want control over this<br>
&lt;TabAtkins> florian: And OSes have different scrollbar structures, so one way of exposing won't work right for another<br>
&lt;TabAtkins> florian: So we've rejected in the past for these reasons<br>
&lt;TabAtkins> florian: I suggest doing so again<br>
&lt;TabAtkins> florian: We have an intro in the spec explaining why we're not doing this<br>
&lt;TabAtkins> florian: fantasai and I are iterating on it a little<br>
&lt;TabAtkins> florian: But preferred action is making the intro clearer as to why we're rejecting, then close as WONGFIX<br>
&lt;emilio> +1<br>
&lt;TabAtkins> florian: Coutner-argument is that if we do this, we might end up with authors not using scrollbar properties at all, and instead using JS scrolling, which is less accessible<br>
&lt;castastrophe> +1<br>
&lt;smfr> +1<br>
&lt;TabAtkins> florian: But still I think the right way is to close and hope that OpenUI helps us with advanced use-cases<br>
&lt;TabAtkins> +1<br>
&lt;Rossen_> q?<br>
&lt;smfr> +1 in support of what florian proposed<br>
&lt;castastrophe> Sorry, +1 to wontfix<br>
&lt;Rossen_> ack fantasai<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> fantasai: If we're deciding not to fix this, but webkit continues to ship the pseudos, does that mean we'll eventually need to spec those anyway? or is webkit planning to remove?<br>
&lt;astearns> q+<br>
&lt;TabAtkins> smfr: webkit is phasing them out - we don't support them on iOS<br>
&lt;emilio> q+<br>
&lt;TabAtkins> smfr: And generally slowly removing webkit-prefixed things. At some point in the future these'll probably go away<br>
&lt;Rossen_> ack astearns<br>
&lt;TabAtkins> astearns: Wonder if we're not quite closing wontfix, but "wontfix now"<br>
&lt;TabAtkins> astearns:<br>
&lt;TabAtkins> astearns: ARgument is that people will adopt these props, and won't see a boost in the number of custom scrollbars<br>
&lt;Rossen_> q<br>
&lt;Rossen_> ack emilio<br>
&lt;TabAtkins> astearns: If in the future we see that happenings, great; if not we can revisit. So slightly moderated response<br>
&lt;TabAtkins> emilio: We haven't gotten any compat reports about webkit scrollbars for quite a while.<br>
&lt;TabAtkins> emilio: Pages use them, but for now Firefox hasn't gotten compat issues<br>
&lt;smfr> q+<br>
&lt;astearns> s/, great; if not/<br>
&lt;TabAtkins> florian: Back to alan's point, the use-case of having *some* control over scrollbars isn't being ignored; we're taking steps toward that<br>
&lt;TabAtkins> florian: The idea of a whole pile of pseudos is being rejected<br>
&lt;emilio> q+<br>
&lt;TabAtkins> florian: The idea of doing more than today isn't rejected; we're pretty sure that a bunch of pseudos will never be workable, tho<br>
&lt;astearns> +1<br>
&lt;TabAtkins> florian: I niether want to make these people believe we're rejecting their use-case, nor let them believe if they push a little more we'll relent<br>
&lt;Rossen_> ackk smfr<br>
&lt;Rossen_> ack smfr<br>
&lt;TabAtkins> smfr: emilio said firefox hasn't had compat reports about not implementing, but a lot of Google props are using custom scrollbars<br>
&lt;TabAtkins> smfr: Woudl like info from chrome people about why they're still used, if it's not important on firefox<br>
&lt;TabAtkins> emilio: They use the scrollbar-color as well<br>
&lt;Rossen_> ack emilio<br>
&lt;TabAtkins> smfr: Ah, good. They currently show the scrollbars always next to videos on safari, which looks quite bad.<br>
&lt;TabAtkins> emilio: Note that a bunch of pseudos has some perf implications. We have some internal pseudos that we use, but we'd like to stop that, too.<br>
&lt;TabAtkins> Rossen_: so it sounds like the path forward is to acknowledge the use-case, but this isn't the path to pursue<br>
&lt;TabAtkins> Rossen_: Looks like a lot of +1s in chat for that<br>
&lt;TabAtkins> Rossen_: Anything else?<br>
&lt;TabAtkins> Rossen_: Objections?<br>
&lt;TabAtkins> RESOLVED: With ack of the use-case, we still reject exposing a large set of pseudos for scrollbars (webkit-prefixed or otherwise)<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 29 July 2021 21:16:17 UTC