- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 15 Oct 2025 16:34:23 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <fantasai> futhark: Issue discovered with ::scroll-marker and ::scroll-marker-group wrt size queries<br> <fantasai> futhark: We pulled the generated box as a sibling of the scroller rather than as a child box<br> <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<br> <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<br> <fantasai> futhark: or we still consider it a container but we would, like 'display: inline', would always [missed]<br> <fantasai> futhark: If we have a similar issue with other sibling pseudos, will need a solution to this problem.<br> <emilio> q+<br> <fantasai> astearns: It seems simpler to always evaluate size queries as unknown, but is it useful to go with a more complicated solution?<br> <fantasai> futhark: I don't think it matters<br> <miriam> q+<br> <fantasai> futhark: option 2, considering it as a container but always return false seems simplest<br> <astearns> ack emilio<br> <fantasai> emilio: I think I agree, question is, in this case it's easy to detect because its a custom pseudo thing<br> <fantasai> emilio: But if you were to rearrange the boxes, would you be able to tell?<br> <fantasai> futhark: I'm unsure if the container has a certain kind of containment applied, should it be able to pull the boxes out<br> <fantasai> emilio: I guess scroll marker group is a weird case here<br> <fantasai> emilio: it's the only case where you inherit from something that's a sibling<br> <fantasai> emilio: Maybe we could special-case this and assume it doesn't otherwise happen but it's a bit odd<br> <fantasai> futhark: I think I heard something about view-transitions-scope wanting to pull view-transition pseudo tree out of the scoping element?<br> <fantasai> futhark: but I'm not fully up to date with that<br> <fantasai> fantasai: view transition pseudos don't affect layout of their container though<br> <astearns> ack miriam<br> <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<br> <fantasai> futhark: that's true with 'display: inline' today<br> <astearns> ack fantasai<br> <emilio> fantasai: following up on miriam's observation<br> <emilio> ... display: inline is generally... you don't put stuff _inside_ so if it returns nonsense nobody really cares<br> <emilio> ... but scrollers generally contain interesting contents<br> <emilio> ... but if the scroll containers return nonsense that's probably going to be annoying<br> <emilio> ... not sure if treating the same as display: inline is necessarily great<br> <miriam> q+<br> <emilio> ... if you could "pass up" then at least you could get a reasonable size<br> <emilio> ... but why would you set contain on the scroll-container then?<br> <emilio> futhark: so yeah we should not choose a different container for ::scroll-marker-group vs something else<br> <astearns> ack miriam<br> <emilio> ... (something else inside the scroller)<br> <emilio> miriam: It's actually common to set size containment in scrollers<br> <emilio> ... because you're able to overflow the container<br> <emilio> ... so it's one of the few cases where you can contain both axes<br> <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<br> <emilio> miriam: it seems a situation where you could provide a wrapper and stuff will still work<br> <emilio> ... because you need that extrinsic size somewhere<br> <emilio> astearns: and if you don't you go up to the root or window?<br> <emilio> miriam: you don't get any answer<br> <emilio> ... if there's no other containers<br> <emilio> astearns: so are we closing in on the solution of not considering this to be a valid size query container?<br> <emilio> ... so it can go back up the tree?<br> <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<br> <emilio> futhark: would it be useful on contained scrollers to have the marker group inside?<br> <emilio> s/futhark:/emilio:<br> <emilio> futhark: I think we're only talking about special-casing the scroll-marker-group lookup<br> <emilio> ... everything else would still work as normal<br> <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<br> <fantasai> futhark: Typically the author won't be styling the markers based on the size of the scroller, because it's cyclic<br> <flackr> +1<br> <fantasai> astearns: So proposed resolution is that for scroll marker groups, the relevant size container cannot be its sibling scroller<br> <fantasai> futhark: Now thinking about it, it makes sense to look further up the tree<br> <flackr> +1<br> <fantasai> futhark: because rendered outside the scroller, and maybe you wnat it to respond to the next size container outside<br> <fantasai> [clarifying what the resolution is]<br> <fantasai> PROPOSED: For scroll marker groups, the relevant size container cannot be its sibling scroller<br> <fantasai> futhark: option 1 in my issue<br> <fantasai> astearns: any objections<br> <fantasai> RESOLVED: For scroll marker groups, the relevant size container cannot be its sibling scroller<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11213#issuecomment-3407344774 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 October 2025 16:34:24 UTC