[css-conditional-5][css-overflow-5] Valid size query containers and box tree re-ordering

[lilles]

In the spec: https://drafts.csswg.org/css-conditional-5/ref-for-query-container①⑧, valid query containers are said to be selected from the element's flat tree ancestors.

We have encountered an issue when the box tree order does not follow the flat tree order. The box for ::scroll-marker-group becomes a sibling of its originating element. While normally pseudo elements can query the size of their originating element, this causes an issue with layout escaping the container causing circularity.

Can we say something generally about box tree re-ordering and size query container candidates?

For the ::scroll-marker-group case we know that if it generates a box, it will be a sibling of its originating element's box. For future cases, if the box tree order depends on the element's style, we might not know at the time we query the container where the element's box will end up.

If we know about the box re-ordering at query time we could either:

1. Not consider ancestors which will not be box tree ancestors as valid size query containers
2. Always evaluate size queries to unknown for such containers

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional-5][css-overflow-5] Valid size query containers and box tree re-ordering, and agreed to the following:

• RESOLVED: For scroll marker groups, the relevant size container cannot be its sibling scroller

The full IRC log of that discussion

<fantasai> futhark: Issue discovered with ::scroll-marker and ::scroll-marker-group wrt size queries
<fantasai> futhark: We pulled the generated box as a sibling of the scroller rather than as a child box
<fantasai> futhark: if the scroller is also a size container, we could end up with a circularity that something outside scroll box can depend on the size container
<fantasai> futhark: In order to fix that we would either say that in this case, element/ancestor in the tree also has to generate a box around that element that queries the container
<fantasai> futhark: or we still consider it a container but we would, like 'display: inline', would always [missed]
<fantasai> futhark: If we have a similar issue with other sibling pseudos, will need a solution to this problem.
<emilio> q+
<fantasai> astearns: It seems simpler to always evaluate size queries as unknown, but is it useful to go with a more complicated solution?
<fantasai> futhark: I don't think it matters
<miriam> q+
<fantasai> futhark: option 2, considering it as a container but always return false seems simplest
<astearns> ack emilio
<fantasai> emilio: I think I agree, question is, in this case it's easy to detect because its a custom pseudo thing
<fantasai> emilio: But if you were to rearrange the boxes, would you be able to tell?
<fantasai> futhark: I'm unsure if the container has a certain kind of containment applied, should it be able to pull the boxes out
<fantasai> emilio: I guess scroll marker group is a weird case here
<fantasai> emilio: it's the only case where you inherit from something that's a sibling
<fantasai> emilio: Maybe we could special-case this and assume it doesn't otherwise happen but it's a bit odd
<fantasai> futhark: I think I heard something about view-transitions-scope wanting to pull view-transition pseudo tree out of the scoping element?
<fantasai> futhark: but I'm not fully up to date with that
<fantasai> fantasai: view transition pseudos don't affect layout of their container though
<astearns> ack miriam
<fantasai> miriam: If we treat something as a container and return unknown, that means you don't automatically get the next container up, so that seems like a noticeable difference between the options
<fantasai> futhark: that's true with 'display: inline' today
<astearns> ack fantasai
<emilio> fantasai: following up on miriam's observation
<emilio> ... display: inline is generally... you don't put stuff _inside_ so if it returns nonsense nobody really cares
<emilio> ... but scrollers generally contain interesting contents
<emilio> ... but if the scroll containers return nonsense that's probably going to be annoying
<emilio> ... not sure if treating the same as display: inline is necessarily great
<miriam> q+
<emilio> ... if you could "pass up" then at least you could get a reasonable size
<emilio> ... but why would you set contain on the scroll-container then?
<emilio> futhark: so yeah we should not choose a different container for ::scroll-marker-group vs something else
<astearns> ack miriam
<emilio> ... (something else inside the scroller)
<emilio> miriam: It's actually common to set size containment in scrollers
<emilio> ... because you're able to overflow the container
<emilio> ... so it's one of the few cases where you can contain both axes
<emilio> astearns: if you're doing that and your scroll container is not going to be able to give you the info you need you want to move up the tree
<emilio> miriam: it seems a situation where you could provide a wrapper and stuff will still work
<emilio> ... because you need that extrinsic size somewhere
<emilio> astearns: and if you don't you go up to the root or window?
<emilio> miriam: you don't get any answer
<emilio> ... if there's no other containers
<emilio> astearns: so are we closing in on the solution of not considering this to be a valid size query container?
<emilio> ... so it can go back up the tree?
<emilio> futhark: if you have containment on the scroller and not allow the scroll-marker-group to escape then you can't have scroll-marker-groups on that scroller
<emilio> futhark: would it be useful on contained scrollers to have the marker group inside?
<emilio> s/futhark:/emilio:
<emilio> futhark: I think we're only talking about special-casing the scroll-marker-group lookup
<emilio> ... everything else would still work as normal
<fantasai> futhark: So only thing we consider here is what's the size container candidate for a scroll-marker-group pseudo-element. Any other element will behave as normal. It's only when looking up the size container candidate for the scroll marker group
<fantasai> futhark: Typically the author won't be styling the markers based on the size of the scroller, because it's cyclic
<flackr> +1
<fantasai> astearns: So proposed resolution is that for scroll marker groups, the relevant size container cannot be its sibling scroller
<fantasai> futhark: Now thinking about it, it makes sense to look further up the tree
<flackr> +1
<fantasai> futhark: because rendered outside the scroller, and maybe you wnat it to respond to the next size container outside
<fantasai> [clarifying what the resolution is]
<fantasai> PROPOSED: For scroll marker groups, the relevant size container cannot be its sibling scroller
<fantasai> futhark: option 1 in my issue
<fantasai> astearns: any objections
<fantasai> RESOLVED: For scroll marker groups, the relevant size container cannot be its sibling scroller