#520: CSS Overflow: scrollbar-gutter

Visit on Github.

Opened Jun 2, 2020

Hola TAG!

I'd like to request a TAG review of scrollbar-gutter.

The scrollbar-gutter property gives control to Web authors over the presence of scrollbar gutters separately from the ability to control the presence of scrollbars provided by the overflow property. This allows authors to avoid layout changes when the content size changes, while also avoiding ugly visuals when scrolling isn't needed.

Further details:

  • I have reviewed the TAG's API Design Principles
  • Relevant time constraints or deadlines: ideally by July 2020
  • The group where the work on this specification is currently being done: CSSWG

We'd prefer the TAG provide feedback as

💬 leave review feedback as a comment in this issue and @-notify @felipeerias

Discussions

Comment by @felipeerias Jun 9, 2020 (See Github)

Edited: added a link to the explainer.

Discussed Jun 15, 2020 (See Github)

Rossen: A rehash of topic discussed in CSSWG for quite some time. Issue linked (4674) discussed at length, agreed on general shape of the API, and agreed to move on and start specifying it in css-overflow spec. So in terms of venue and having folks engaged I think we're there. Question is does this property and behavior overall make sense from the TAG's PoV.

Discussion of && in CSS syntax.

Rossen: General idea is to make layouts more stable for scrollbars or other UI types for scrolling, custom scrollbars, etc.

Peter: Always weird that change to layout in one dimension can cause scrollbar in the other dimension

Rossen: It's become sort of natural to me :-)

Alice: Looks pretty good, the illustrations help. Would be nice to see each value compared between classic and overlay instead of this big thing. Only question would be why is the current bad behavior the default?

Rossen/Peter: history.

Alice: Looks good to me, but makes me sad we can't fix the default. Maybe explainer should say? Maybe I'll ask in the issue even though I have know the answer. Would be nice to know what would break?

Peter: Some OSes almost always do overlay scrollbars and sidestep the issue.

Rossen: I'm adding comment now to encourage authors to transfer the examples over to the spec since the spec doesn't have any. Would be great to have them in the spec.

Alice: In the context of the spec they'd have no choice to show the classic and overlay examples per-value. It's really only stable that behaves differently between classic and overlay scrollbars. Seems like stable would be a good default, but it's not.

David: probably pages that know there are never scrollbars, would break.

Rossen: Aside, why not an event to say whether there's a scrollbar?

David: Though there was an overflow event... oh, it's Gecko-specific.

Rossen: Back to scrollbar-gutter, seems overall ok... does the TAG need to do more?

Peter: Don't see anything architectural. Though question of where this fits into things like APIs and events that we're missing, I think that's valid feedback

Comment by @atanassov Jun 15, 2020 (See Github)

The overall explainer looks good. I would encourage you to work with the spec editors and have them adopt your illustrations.

Comment by @alice Jun 15, 2020 (See Github)

It would be nice to see a discussion of why stable can't be made the default value.

Otherwise, this looks good to me, thanks for the explainer!

Comment by @atanassov Jun 15, 2020 (See Github)

Having the ability to request and trigger scrollbar gutter space and/or scrollbars is great and this feature certainly makes it better. What seems obviously missing here is a way for developers to check whether or not a scrollbar is present for any given node in the DOM tree. Also, having events and the ability to attach listeners for such scrollbar events seems like a very useful and often requested feature. Perhaps this could be part of the same spec.

Comment by @felipeerias Jun 22, 2020 (See Github)

Thank you very much for your feedback.

Regarding @alice's question about stable not being the default, my personal assumption is that doing so would break existing layouts so it is safer if scrollbar-gutter is an opt-in property.

As the discussion and implementation get started, a couple issues have come up:

In that last issue there is a mention about having "an env() way of accessing the computed scrollbar size for solving these cases" which links with @atanassov's mention of getting more information and events about the scrollbar.

I see scrollbar-gutter as a first step for solving the most common use cases, keeping in mind that eventually there might be a need for more elaborated solutions in some scenarios.

Discussed Jul 20, 2020 (See Github)

Rossen: Propose closing?

Alice: Sounds good.

Rossen: I'll comment and update the label

Comment by @atanassov Jul 21, 2020 (See Github)

Thank you for the prompt and detail answers @felipeerias. Based on developer demand I would encourage you to continue pursuing exposure of the scrollbar state event.

During our breakout session today we discussed your proposal and are happy to see it continue developing with the csswg. We'll close it during our next plenary meeting.

Comment by @felipeerias Jul 21, 2020 (See Github)

Thank you, @atanassov. I agree that it makes sense to also expose a scrollbar state event.

Last month I finished the parsing of the scrollbar-gutter property in Chromium and I am now working on implementing its behaviour. This feature is still in the "test" state (one step before "experimental") so it will not be ready for prime time just yet, but I am happy to report that things are moving forward.

Comment by @atanassov Jul 22, 2020 (See Github)

@felipeerias Sounds great, good luck.