Alice: appreciate that the explainer links out to use cases which link to bugs asking for this feature. Great example.

Ken: I appreciate the security & privacy section though

Dan: on the self-review... they answered yes to point 11, but can it "affect securtity & privacy controls"?

Alice: Is the scroll bar privacy & security critical in any way? it doesn't allow anything you couldn't already do... you could already make a fake scroll bar

Ken: and remove the scroll bar...

Alice: I can't see a security or privacy implication. I can see an accessibility implication. Users could use a user style sheet.

Yves: it's using the system scrollbar. if you have a system that redefines the system scrollbar instead, it's better to use the system one as it can be linked to external tools.

Dan: prefers color scheme?

Alice: right now the browser doesn't do anything with prefers color scheme...

Ken: auto?

Ken: if the browser does dark mode for your website then it could do the same for your website.

[discussion of dark mode]

Alice: prefers color scheme is orthoginal

Ken: some compoents in material web compoents support dark mode...

Alice: assuming they considered having seaprate properties for the thumb and the track... Things that cascade together. Can be auto, dark, light or 2 colors.

Dan: Maybe one feedback point could be asking them to be clearer about the interaction betwee this and prefers-color-scheme ?

Alice: specifically the interaction between the light and dark properties and prefers-color-scheme... Do we want a shortcut to say "match what the colorscheme wants"?

Dan: any a11y issues?

ALice: anytime you can override color you can do so to make it less accessible. If you do a super-light-grey-on-white scrollbar that can't be easily seen - it would be nice to have users have a way to unmatch the styles. More of a UA question but it might be nice to highlight that.

• We'd like to see screenshots from different platforms and/or dark mode to make sure this generalizes well - scrollbars look ver different on Windows where there are arrow buttons that have hover effect and can be pressed. Also they look different when two scrollbars meet
• Maybe allow auto instead of either of the <color>'s to auto-generate the other with proper contrast.
• Control over scroll indicator vs scrollbar. What if I want a scroll indicator but not a scrollbar? (scroll indicators are painted over the website and auto hidden, scrollbars are always there). Some developers don't like scrollbars that take up space as they can change rendering when they appear and disappear, like on YouTube where scrollbar can appear because you open the drawer, ending up resizing all thumbnails. Slack as one example turns off naive scrollbars and draws their own scroll indicators which we would like to avoid as it can have a performance penalty. We think a third property is needed to control this distinction.

Lea: filipe replied and opened an issue - and replied to some of our issues. Also one point lack of consensus. ... Also scrollbar_gutter ...

Dan: Can we close?

Ken: concerned about scroll indicators...

Lea: does scrollbar_gutter ...

Ken: allows you to reserve the space.

Lea: it looks like this property should go through TAG review independently.

Dan: What's the status of scrollbar_gutter ?

Ken: Draft.

Lea: as a general comment - it's kind of a shame that the use cases are lost in the process of making it into the spec - you can't find the use cases.

Ken: scroll bars are everywhere on the web - and we want people to make good experiences that look like native. why not just go the last mile ... why not hear the use cases for not doing your own scrolling solution? "strong reason why people want their own scrolling solution" - ok let's hear the use cases.

[Ken posts comment]

Dan: doesn't make it easy to figure out what to do next

Rossen: proposing to add capabilities for controlling colour and width for scrollbars

Dan: we had discussion last time. We discussed scrollbar gutter, and we should have realised we had reviewed scrollbar gutter. My question is, what is there for us to review here? Ken's points are important.. one is asking for more use cases. Some in a wiki. If we ask them to amend the explainer with the use cases and come back to use - then are we done, or do we need to come back to it? Or should we close it and say please do that, let us know if you need more help?

Lea: he did mention usec ases. Our feedback was not just about scroll indicators, but also about being able to specify one colour which is being discussed in an issue (no resolution yet). So still in progress.

Dan: maybe we could say yes to update the explainer and we think these are the outstanding issues that need to be resolved.

Rossen: can I summarise where I see this work being. This work came about from mozilla two or three years ago when they were facing a lot of comapt issues with scrollbar customisation, going all the way back to i5 or i6 which is when scrollbar colour customisatins were exposed as propietary css properties that allow you to style the track, the arrow and the sub parts of the sscrollbar controller was one of the motivations. The spec was codifying that capability. When it camee to CSS WG the feedback was wait what about the other customisation that was also exposed through webkit prefix properties that allow even greater expanse of scrollbar customisation to the point where you can target individual parts. That became the feedback and the expectation of the overall direction of the spec was to figure out what from the combined set of historical behaviours what is the most actionable path forward. Reading the use cases - they still refer to parts and bits and pieces of specific behaviour that was enabled before. The spec here is a pretty coarse approach. The width is the entire scrollbar component, you cannot target the indiidual components. the colour is also a one stop shop, you can only apply the colour to the entire control. That's where the spec is currently. The current proposal, if we believe it is part of the platform whcih should allow developers to have these two quick and massive behaviours to control the size and the colour of the scrollbars independently that will allow them to create their own components, that's great. All of the details will be worked out further in CSS WG, so we shouldn't sweat those here. The general question for us is as developers is this enough?

Dan: there's an existing set of webkit apis which do more than what this does. So there's an existing implementation. Has that implementation been proposed by anybody?

Lea: I don't think just standardising the webkit implementaitonw ould be a good idea, it's painful to use. There are so many things that need to be customised and often you just want to set the colour of the scrollbar and you have to set a bunch of CSS rules, I don't think that's a good direction.

Dan: I wasn't suggesting we should propose that, just saying to Rossen's point about not micromanaging the styling of scrollbars, but what is appropriate for us to do is talking about browser compatibility and one web and the fact that web developers expect to be able to do the same thing across browsers, the same capabilities or similar, so that would be a good reason to make that comment that Rossen made about it not being fine grained, maybe?

Rossen: yes. To our previous unfinished rule about high vs low level primitives, this fits nicely because it starts high, starts to expose capability at the top level only, the scrollbar control is a black box thing you can shrink or expand as a whole, or style it, that's it. That doesn't prevent if we want to further break down and expose additional capabilities later. We'll start approaching both the ie styling mostly around colours as well as the webkit styling around the different parts inside and placement and sizing.

Lea: in terms of low vs high level, that's just right.

Rossen: I'm of the mindset that we dont' need to give them too much hard time n this proposal, from the point of view of what they're trying to achieve, can they make the explainer better absolutely. In terms of the intended path forward for this kind of capability - I'm close to the spec, biased opinion.

Lea: I agree with Rossen. Ken felt very strongly about the point about scroll indicators vs scrollbars. Do you think it would be a good idea to discuss this when Ken can weigh in before we leave feedback

Rossen: sure

Dan: I can leave a brief note saying thanks and sorry about scrollbar gutters.

[will discuss at plenary]

Lea: wanted to get Ken's opinion - personally I'm satisfied with filipe's response.

[replaying Breakout A discussion on this...]

Ken: I think this is good enough. They seem to have thought about it. I'm good with this.

Dan: "propose close" then?

Proposed comment: `We took another look at this during this week's meetings, and we are happy with the direction this proposal is going, so we are going to go ahead and close this. If/when there are substantive changes, feel free to open another review request.

Lea: looked at filipe's response - i'm happy - but Ken might have thoughts. After filipe's response, some responses from ruben. Should this discussion be happening in our design review?

Rossen: maybe suggest to them that they take the discussion to [their repo].

Peter: let's move to breakout C?

Dan: meta point - at some point people discussing a specific technical issue should open an issue on the spec repo and continue the discussion there

Rossen: [leaves comment requesting this