[css-conditional-5] container-type:scroll-state and single-axis scrollers

[tabatkins]

In CSS Conditional 5, we've added the ability to query the scroll-state of a container with container-type: scroll-state, which allows children to use queries like scrollable(bottom) to see if there's scrollable content being hidden by the bottom edge of the scrollport.

When I was making edits to support single-axis scrollers, I made the assumption that non-scroll containers would simply ignore being declared a scroll-state container, so you could query horizontal scrolling and get the answer from the nearest horizontally scrollable container, and query vertical scrolling and get the answer from the nearest vertically scrollable container. I assumed this is how things already worked for non-scrollers, but that's not the case; the spec makes it clear that if an element uses container-type: scroll-state but isn't a scroll container, the queries just evaluate to unknown. (This is consistent with making yourself a size query container when you don't have a box, like display:contents.)

The ability to query different containers for scroll state when single-axis scrollers are in play is still useful, tho, for all the reasons single-axis scrollers are useful in the first place.

So, which approach do we want to take?

1. Fix the spec so that queries against an element that's not scrollable in the relevant axis evaluate to unknown, consistent for both non-scrollers and single-axis scrollers. Add inline-scroll-container and block-scroll-container keywords to allow an element to declare it can answer queries in just one axis.
2. Change the spec so that scroll queries against an axis that isn't scrollable will skip up the ancestor tree until it finds a query container that can answer the question. Do the same to size queries, for consistency.

@lilles tells me in private chat that option 2 is complicated, but I'm still working through understanding the reasons that is the case.

[lilles]

@lilles tells me in private chat that option 2 is complicated, but I'm still working through understanding the reasons that is the case.

It's not really that complicated, but it means we need to be more careful specifying how computed values are taken into account to decide whether an element is a query container candidate. We originally discussed whether we should have an explicit container-type property at all for the size queries or rely on the contain property and ended up with the explicit container-type.

My preference would be to keep it simple and continue to rely on container-type only.

[lilles]

There are also scroll-state containers which are not scroll containers such as sticky and snap containers. Should they also only be considered candidates only if position:sticky or having some snap-* properties set?

[tabatkins]

We originally discussed whether we should have an explicit container-type property at all for the size queries or rely on the contain property and ended up with the explicit container-type.

The choice of what signal to use to make yourself a query container is, I think, somewhat separate from this question (actually being capable of answering a given query). I'm fine with sticking with container-type as the way you declare yourself; I'm just concerned about the ability to combine these queries with single-axis scrollers reasonably.

There are also scroll-state containers which are not scroll containers such as sticky and snap containers. Should they also only be considered candidates only if position:sticky or having some snap-* properties set?

I can go either way on those. You need to be stickypos to be stuck, sure, but any element can be not stuck. Similar for snapping.

That said, now that this is in mind, it's somewhat odd that wanting to query whether an ancestor is stuck actually prevents you from querying whether a higher ancestor has scrollable overflow, or is snapped. Is this an intentional limitation, to prevent an element from being able to key off the scroll state of multiple scrollers? (If so, that obviously makes the case for block/inline-scroll-state harder...) Or is it just an accidental tie-together due to them all being vaguely scroll-related and thus grouped together semantically? I'm wondering if it would be better to have those two actually be their own container-types, like container-type: scroll-sticky and container-type: scroll-snap.

[lilles]

We originally discussed whether we should have an explicit container-type property at all for the size queries or rely on the contain property and ended up with the explicit container-type.

The choice of what signal to use to make yourself a query container is, I think, somewhat separate from this question (actually being capable of answering a given query). I'm fine with sticking with container-type as the way you declare yourself; I'm just concerned about the ability to combine these queries with single-axis scrollers reasonably.

There are also scroll-state containers which are not scroll containers such as sticky and snap containers. Should they also only be considered candidates only if position:sticky or having some snap-* properties set?

I can go either way on those. You need to be stickypos to be stuck, sure, but any element can be not stuck. Similar for snapping.

That said, now that this is in mind, it's somewhat odd that wanting to query whether an ancestor is stuck actually prevents you from querying whether a higher ancestor has scrollable overflow, or is snapped. Is this an intentional limitation, to prevent an element from being able to key off the scroll state of multiple scrollers? (If so, that obviously makes the case for block/inline-scroll-state harder...) Or is it just an accidental tie-together due to them all being vaguely scroll-related and thus grouped together semantically? I'm wondering if it would be better to have those two actually be their own container-types, like container-type: scroll-sticky and container-type: scroll-snap.

My original proposal was to have separate container-types, but the WG discussion ended up resolving to have a single one.

[tabatkins]

Yeah, that was a very fast discussion that didn't touch on the issues:

<bramus> RESVOLED: add sticky, snap, and overflow as new container type values
<bramus> astearns: state as conflict … scroll or scroll-state were suggested … can add scroll-state to start with?
<bramus> futhark: yeah, no strong opinion about the name

So we should probably reopen that. I'll open an issue.