[css-overflow-5] Can we relax size containment on ::scroll-marker-group? #11166
Comments
I could use anchor-size() when anchoring, for at least one of the sides, that could help with alignment but wouldnt be intrinsic sizing. but maybe worth noting here that anchor-size() can add a little, or in some scenarios, but wouldnt necessarily solve the unintrinsic nature of contain: size. |
|
just went to go put a background color on the |
|
also, having width on this marker group also means i can position buttons on either side of it with anchor nice and easy. without the width, the positioning gets tricky. |
|
We could adjust the computed style of the scroll marker group to add layout/size containment if |
|
@mstensho Yep, that's option 3. I think that would be enough for many common use cases, I'm just not sure if:
I could still see it being a common gotcha when you're using in-flow positioning, and potentially hard to know what size to set in these cases. |
In-flow without containment? <!DOCTYPE html>
<style>
.container {
width: 700px;
}
.scroller {
overflow: auto;
columns: 1;
height: 110px;
scroll-marker-group: before;
background: yellow;
}
.scroller::scroll-marker-group {
/* Look at me! No extrinsic size! */
float: left;
background: hotpink;
}
.item {
display: inline-block;
width: 300px;
height: 70px;
margin: 10px;
background: cyan;
}
.scroller::column::scroll-marker {
display: inline-block;
width: 50px;
height: 50px;
content: "*";
}
</style>
<div class="container">
<div class="scroller">
<div class="item"></div>
<div class="item"></div>
<div class="item"></div>
<div class="item"></div>
<div class="item"></div>
</div>
</div>With a So I guess we can say that it's stable in this case, although it took a couple of rounds. At least no circular dependencies (but I'm sure it's possible to come up with an example of that as well). The main problem with supporting this (apart from detecting and speccing circular dependencies) is that we would have to do non-trivial amounts of work on every layout algorithm, basically teach them all that the contents of one element may affect the contents of a sibling. This would be a project comparable to adding support for block fragmentation to all layout algorithms, which we did, since we had to, and that took some years, and, like block fragmentation, it would add a heavy maintenance burden. I'd like to go through the other options, the way I see them: Option 1 isn't any weirder than what we currently have. Instead of enforced containment, we have enforced out-of-flow. Exchanging one disadvantage for another. I think enforcing containment is less of a disadvantage than enforcing out-of-flow, though? Not sure what option 2 would give us, apart from annoying behavior if the developer has messed up. :) Option 4 will allow for some chain reactions (example above) (probably even circular dependencies). The size of the scroll marker group could then affect the size of the scroller and/or its ancestors. So option 3 seems like the best option to me, although implying containment from in-flowness is a new invention. |
|
Yep, it is certainly possible to create some cycles if we had something generic like option 4. There are ways to mitigate it, e.g. similar to scrollbar logic where you only ever move forward and/or limit extra cycles per generated frame (could flicker between states like hover), however this potentially adds a lot of complexity and would still require one more layout pass in the common case. As such, I'm inclined to agree that option 3 is probably the best way to get most of the use cases without all of this complexity. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<andreubotella> flackr: the :scroll-marker-group pseudoclass is spec'd to have size containment to avoid cycles in the number of established scroll markers<andreubotella> flackr: but that's a common pitfall for authors, since if they forget to set an explicit size, it doesn't behave as expected <andreubotella> flackr: can we relax that? <andreubotella> flackr: the common case, you are making a target group out of (...) and the size doesn't affect the scroll container <emilio> q+ <andreubotella> flackr: can we make the containment conditional on whether it's out-of-flow positioned? <andreubotella> florian: I don't have an issue, the whole point of containment is to make it easier to reason about this, and this doesn't make it easier <andreubotella> florian: I'm not familiar enough, but don't you need layout containment as well? <andreubotella> flackr: you need it to not affect the size of the container <andreubotella> florian: if its size doesn't change but it's not an IFC and you have a float poking out of it, and the float's size changes, it could jumble the content around it <andreubotella> florian: so i suspect you also need layout containment <andreubotella> florian: making size (and possibly layout) containment conditional on out-of-flow sounds good to me <andreubotella> florian: but even if your position not changing is fine, is it a problem if your content scrolls too far and causes scrollbars to appear? <andreubotella> flackr: not a problem, once scrollbars appear we don't remove them <andreubotella> florian: you could have subtle interactions that break what you thought was a guarantee <astearns> ack emilio <astearns> q+ astearns <andreubotella> emilio: what's the use case for getting them in flow? if 99% of use cases require them to be out of flow, shouldn't we always have containment? <andreubotella> flackr: you need it to be in-flow if you want to put your scroll marker group in a grid area, and have it have the correct size, which is relatively common <andreubotella> flackr: i could see leaving that as an open question <andreubotella> flackr: maybe resolve to do this switch, but consider if there are legitimate use cases for in-flow position <andreubotella> emilio: we can do this magic to force containment if not abpos, and contain is already a magic property with interactions <andreubotella> astearns: if the problem is that the size containment is unexpected for authors, then having it be unexpected only in abspos makes the problem worse <astearns> ack astearns <andreubotella> florian: but for in-flow, it's unexpected and unnecessary <andreubotella> PROPOSED RESOLUTION: scroll-marker-group applies containment when it is in-flow only <andreubotella> RESOLVED: ::scroll-marker-group applies containment when it is in-flow only <andreubotella> astearns: as for whether we also need layout containment, we'll have another issue if that is a problem |
|
Dropping size containment on out-of-flow is fine, but I've come to realize that we always need layout containment. If a scroll-marker-group is out-of-flow, and it has scroll markers that are fixed-positioned, they would otherwise escape the scroll marker group, which would be bad, since the scroll-marker-group is populated (and depopulated) during layout. |
|
Sounds good, i think that still allows for the expected use cases to work just fine. I made a demo to play with it: |
The spec currently recommends the following default UA stylesheet:
This is necessary to prevent cycles in certain cases, e.g.
Without size containment, the size of the
::scroll-marker-groupdepends on the number / layout of the::scroll-markerelements that are within it. However, when the size of the group changes, it changes the space available for the scroller which could change the number of::columns.However, having this size containment means that even in cases where the size doesn't affect the size of the scroller (e.g.
position: absolute), they can't have it automatically sized and aligned based on its size, which adds a fair bit of complexity to achieving certain designs.Some ideas that might make this less surprising or easier to work with:
overflow: autoto make the problem more obvious when you're overflowing the space.contain-intrinsic-sizeafter the first layout perhaps?The text was updated successfully, but these errors were encountered: