[css-overflow-5] Tree structure of scroll container controls

[flackr]

::scroll-marker-group and ::scroll-button(*) are pseudo elements that originate from the scrolling container. These elements should not move with scrolling content as they are meant for navigating the scroller. Structurally we need to decide if they are children of the originating element scrolling container (like most existing pseudo-elements), or whether they should be siblings.

Options:

1. They are normal children. Developers need to switch to a different positioning model that makes them not contained by (or shifted by) the scrolling content of the scrolling container. E.g. position: fixed or position: absolute (as long as the scroller isn't position: relative), or anchor positioned. It is impossible to reserve space for them outside of the scroller.
2. They are siblings before/after the scroller. They can reserve space in the flow of the scroller's container, possibly be positioned into grid areas or participate in ancestor flexbox sizing. Additionally like other siblings their in flow position is outside of the box of the scrolling container.
3. They are children of the scrolling container but not part of the scrolling content, instead being considered part of the box model for the scrolling container itself (and thus not scrolled by it). We'd have to think more about how exactly this would work (i.e. outside border? inside border? inside padding?) and render, but conceptually they would be part of the box of the scrolling container.

Demo of the approximate layout of the different approaches with minimal extra position styling:
https://flackr.github.io/carousel/examples/pseudo-structure/

I propose that we go with option 2 as it's easy to understand and I think sets up a lot of the right structure by default.

@tabatkins

[ydaniv]

So with option 2 the generated tree would look like this:

::scroll-button(*)
<scroller></scroller>
::scroll-marker-group

correct?
But they're still selected as children of scroller, like scroller::scroll-button(*)?

I guess options 2 and 3 allow you to break out of the scroller's clipping, so that gives more styling freedom OOTB.

IIUC, with option 1 they're clipped by the scroller, which gives less styling freedom for this model. Although this option feels more intuitive, I suppose it will require more opinionated default UA styling to be visually correct by default, since without correct initial positioning it would appear broken.

I think it would be helpful to visualize how we want these to render by default? And with what UA styles? And then see for each option, what it takes to reach different layout use-cases.

[flackr]

So with option 2 the generated tree would look like this:

::scroll-button(*)
<scroller></scroller>
::scroll-marker-group

correct? But they're still selected as children of scroller, like scroller::scroll-button(*)?

That's correct. The chromium implementation of ::scroll-marker-group and the spec suggest matches option 2 right now. However currently the chromium implementation of ::scroll-button(*) is implemented following option 1, so you can see the difference between them on the canary channel with experimental web platform features enabled as well.

I guess options 2 and 3 allow you to break out of the scroller's clipping, so that gives more styling freedom OOTB.

IIUC, with option 1 they're clipped by the scroller, which gives less styling freedom for this model. Although this option feels more intuitive, I suppose it will require more opinionated default UA styling to be visually correct by default, since without correct initial positioning it would appear broken.

That's right, it takes more careful styling to get them to behave as expected and is less flexible. Note that they don't necessarily have to be clipped by the scroller, if they're position: absolute; and the scroller is position: relative than things mostly work as expected. However, this is also limiting, and feels like a bit of a gotcha.

I think it would be helpful to visualize how we want these to render by default? And with what UA styles? And then see for each option, what it takes to reach different layout use-cases.

I made a demo page showing roughly what the different structures would look like if minimal styling were used. Were you thinking that it would be helpful to show how a developer might achieve some common expected designs with each structure?

[argyleink]

a reason to have them as children is they could adapt to container queries and scroll-state queries

i'm also pretty much always positioning these with anchor, which pops them out of the flow. maybe #3 gives the most flexibility but also has the most implementation difficulty?

[ydaniv]

I made a demo page showing roughly what the different structures would look like if minimal styling were used. Were you thinking that it would be helpful to show how a developer might achieve some common expected designs with each structure?

Thanks @flackr, That's very helpful!
What you put there is exactly what I needed for the sake of this issue. But I think it would be a good idea to go through that same exercise that @argyleink did with implementing a few common examples and see how that feels like in Real Life™. I'll try popping one up if you guys won't beat me to it.

---

@argyleink

a reason to have them as children is they could adapt to container queries and scroll-state queries

i'm also pretty much always positioning these with anchor, which pops them out of the flow.

Yes, that's correct.
I guess options 2 and 3 give you the same layout OOTB, but with option 2 you have to rely on the container for queries and positioning, which means you always have to add an extra element.

So I guess it boils down to whether being able to go that extra mile for option 3 and being able to not add a requirement on an having an extra element for positioning and queries is worth it.
I kinda of hoping it does, but we'll need implementer input here.

[lilles]

Container queries work on the element flat tree, not the box tree. Whether the boxes are on the outside or inside of the scroller should not matter for scroll-state() queries. However, boxes as siblings of the scroller causes layout/size containment issues for size containers. I reported issue #11213.

[flackr]

I think the same may be true of anchor positioning - that it would identify its target via the element flat tree - so it should be able to work as well.

[flackr]

Part of the reason I think sibling boxes is very useful is the ability to put them into different grid areas, e.g. on https://codepen.io/flackr/pen/RwXvzOP the scroll marker group is in a separate grid area from the scrolling container.

[argyleink]

sounds like scroll-state() and other container queries will just work, thanks Rune! I've been mostly positioning these elements with anchor, but I agree that grid-area placement is also a very nice strategy.

I change my vote to option 2

[lilles]

sounds like scroll-state() and other container queries will just work, thanks Rune! I've been mostly positioning these elements with anchor, but I agree that grid-area placement is also a very nice strategy.

No, not size container queries. See issue #11213.

[lilles]

I think the same may be true of anchor positioning - that it would identify its target via the element flat tree - so it should be able to work as well.

Maybe, but I think that needs a closer look. You need to lay out the anchor before the anchored element for it to work, so it very much depends on layout and box tree order.

[argyleink]

No, not size container queries. See issue #11213.

gotcha! no prob

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-5] Tree structure of scroll container controls, and agreed to the following:

• RESOLVED: go with option 2 and make them siblings

The full IRC log of that discussion

<dbaron> flackr: overflow-5 specs adds a bunch of new pseudos: scroll buttons and scroll marker group
<dbaron> flackr: we have spec'd that scroll marker group acts like layout sibling to scroll container. Buttons not spec'd that well.
<dbaron> flackr: I think this matters in terms of how developers can lay things out that we define this well.
<dbaron> flackr: my proposal is that they are layout siblings to the scroll container, similar to the scroll maker group
<dbaron> flackr: and that we have a well defined order, informed by the focus order issue (coming later)
<dbaron> flackr: I want to ensure that if we do this we can still support querying things about scroll container state.
<dbaron> flackr: futhark said in issue this seems fine
<TabAtkins> q+
<astearns> ack fantasai
<dbaron> flackr: If making them siblings had prevented querying things on the scroll container that would (have been/be) a concern
<dbaron> fantasai: I agree it's a better route in general.
<dbaron> fantasai: one issue was inability to use size container queries, not sure if that would be a problem
<dbaron> flackr: I don't think that's a problem.
<dbaron> astearns: Is the issue with size containers that if they're siblings then the size containment doesn't consider them?
<dbaron> flackr: I think the size containment algorithm doesn't support using a size container query on a layout sibling
<dbaron> flackr: I don't think it's a big problem that you can't use size container queries -- that particular aspect is not super important.
<ydaniv> q+
<dbaron> astearns: fantasai, anything more on this?
<astearns> ack TabAtkins
<dbaron> fantasai: no, just stating the question.
<dbaron> TabAtkins: I agree this is probably the right model. It's new. I'm interested in seeing how it works, if it's generalizable, annoying, or something we need to keep as a special case.
<astearns> ack ydaniv
<dbaron> ydaniv: I think big difference between second and third is what's your container. If you're doing layout of pseudos -- with opteion 3 it's the same element but with option 2 it's the container of all of them.
<dbaron> flackr: I think the container for *style* purposes can still bet he same.
<dbaron> ydaniv: the same element, the scroller?
<dbaron> flackr: yeah
<dbaron> flackr: In the flat tree they're sort of like descendants -- just in the generated boxes they're siblings.
<dbaron> ydaniv: you mentioned being able to do grid layout -- in both cases display:grid is on the same element and you can place them according to the scroller
<dbaron> flackr: Option 1 and 3 wouldn't support grid layout.
<dbaron> flackr: The idea is that you have display:grid on an immediate ancestor of the scroller -- the only way you can choose grid areas from that if they're effectively layout siblings to the scroler.
<dbaron> fantasai: In general, having them be siblings means they can take up space in layout area outside the scroller, which is sometimes what you want.
<dbaron> fantasai: That's the main advantage of making them siblings.
<dbaron> fantasai: The disadvantage is that you can't use size container queries to change layout of the scroll markers.
<dbaron> astearns: so I'm hearing general agreement that option 2 is the best of what we've presented so far. Shall we resolve on trying it and see how it goes?
<dbaron> flackr: sounds good to me
<dbaron> [heads nodding]
<dbaron> Proposed resolution: go with option 2 and make them siblings
<dbaron> RESOLVED: go with option 2 and make them siblings
<dbaron> astearns: ... knowing that we may come back to this if the size containment thing or anything else proves unwieldy