Re: [csswg-drafts] [css-overflow-5] Tree structure of scroll container controls (#11125)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;dbaron> flackr: overflow-5 specs adds a bunch of new pseudos: scroll buttons and scroll marker group<br>
&lt;dbaron> flackr: we have spec'd that scroll marker group acts like layout sibling to scroll container.  Buttons not spec'd that well.<br>
&lt;dbaron> flackr: I think this matters in terms of how developers can lay things out that we define this well.<br>
&lt;dbaron> flackr: my proposal is that they are layout siblings to the scroll container, similar to the scroll maker group<br>
&lt;dbaron> flackr: and that we have a well defined order, informed by the focus order issue (coming later)<br>
&lt;dbaron> flackr: I want to ensure that if we do this we can still support querying things about scroll container state.<br>
&lt;dbaron> flackr: futhark said in issue this seems fine<br>
&lt;TabAtkins> q+<br>
&lt;astearns> ack fantasai<br>
&lt;dbaron> flackr: If making them siblings had prevented querying things on the scroll container that would (have been/be) a concern<br>
&lt;dbaron> fantasai: I agree it's a better route in general.<br>
&lt;dbaron> fantasai: one issue was inability to use size container queries, not sure if that would be a problem<br>
&lt;dbaron> flackr: I don't think that's a problem.<br>
&lt;dbaron> astearns: Is the issue with size containers that if they're siblings then the size containment doesn't consider them?<br>
&lt;dbaron> flackr: I think the size containment algorithm doesn't support using a size container query on a layout sibling<br>
&lt;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.<br>
&lt;ydaniv> q+<br>
&lt;dbaron> astearns: fantasai, anything more on this?<br>
&lt;astearns> ack TabAtkins<br>
&lt;dbaron> fantasai: no, just stating the question.<br>
&lt;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.<br>
&lt;astearns> ack ydaniv<br>
&lt;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.<br>
&lt;dbaron> flackr: I think the container for *style* purposes can still bet he same.<br>
&lt;dbaron> ydaniv: the same element, the scroller?<br>
&lt;dbaron> flackr: yeah<br>
&lt;dbaron> flackr: In the flat tree they're sort of like descendants -- just in the generated boxes they're siblings.<br>
&lt;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<br>
&lt;dbaron> flackr: Option 1 and 3 wouldn't support grid layout.<br>
&lt;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.<br>
&lt;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.<br>
&lt;dbaron> fantasai: That's the main advantage of making them siblings.<br>
&lt;dbaron> fantasai: The disadvantage is that you can't use size container queries to change layout of the scroll markers.<br>
&lt;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?<br>
&lt;dbaron> flackr: sounds good to me<br>
&lt;dbaron> [heads nodding]<br>
&lt;dbaron> Proposed resolution: go with option 2 and make them siblings<br>
&lt;dbaron> RESOLVED: go with option 2 and make them siblings<br>
&lt;dbaron> astearns: ... knowing that we may come back to this if the size containment thing or anything else proves unwieldy<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11125#issuecomment-2489014073 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 November 2024 16:16:20 UTC