[css-contain] Need clarification on layout containment & fragmentation

[dholbert]

Here's a quote of the spec's bullet point number 2 under contain:layout ( https://drafts.csswg.org/css-contain/#layout-containment ):

If a fragmentation context participates in layout containment, the first element with layout containment affecting the fragmentation context must “trap” the remainder of the fragmented flow. Fragmentation must not continue past the layout containment boundary, and the last fragmentation container within the first layout containment boundary is treated as if it is the last fragmentation container in its fragmentation context.

If subsequent fragmentation containers in the fragmentation context are only generated when more content remains in the fragmented flow, then they are not generated. If they would exist regardless, they remain part of the fragmentation context, but do not receive any content from the fragmented flow.

I don't really understand what this is saying, after a few readthroughs. Here are the primary bits of vagueness that I'm stumbling over:

• In the first sentence, what does it mean for a fragmentation context to "[participate] in layout containment"? Is this talking about the fragmentation context being established by a parent of the contained element, or established by the contained element itself, or by a child inside of a layout-contained element? Or some/all of the above?

• Similarly, what does "layout containment affecting the fragmentation context" mean? Would a tiny block descendant with contain:layout be considered to "affect" a fragmentation context that was established by its ancestor multicol element?

• In the second sentence, the phrase "the last fragmentation container within the first layout containment boundary" doesn't make sense to me... (in part because I'm not sure whether we're considering fragmentation containers that are ancestors or descendants of the layout-contained thing, as noted above). Hypothetically if this is talking about cases where the fragmentation container element is a parent of the layout-contained thing, then I don't know how it would generate fragmentation containers "within" a layout containment boundary. Alternately, if this is talking about cases where the fragmentation container element is the layout-contained thing (or is a child of the layout-contained thing), then that phrase would trivially be describing the first fragment, and it sounds like there would simply be no fragmentation, I think...

CC'ing editors @frivoal @tabatkins . Thanks in advance!

[fantasai]

I don't understand what it's saying either, fwiw.

It looks like that text dates from FPWD, and probably should be removed... https://hg.csswg.org/drafts/annotate/ffc34d7908a7/css-contain/Overview.bs

[frivoal]

I don't think it should be removed, but it should certainly be clarified. It took me far too long to manage to remember/understand what this is supposed to say.

This is trying to make a generic statement about things like regions, or or fragment overflow, or potential future selectors for individual columns in a multicol.

Now, this is all annoying to phrase, because we should not have any dependency on any of these, since none of them are stable and broadly accepted.

At the same time, we felt it was necessary to have requirements about that sort of things in general, because if we didn't and those later specifications forgot to introduce the corresponding requirement, then it would break containment (rather than break those later features). By break containment, I mean that the assumptions that containment is trying to enforce so that the various desirable optimizations can be valid would no longer be true, and the "optimizations" would become bugs, making this spec useless.

Hence the abstract phrasing, to place constraints on what future specs can do. But on top of being abstract, it is also vague and hard to understand, so we need to fix that.

Before I get back to the phrasing, here is a sample situation where this would trigger.

With regions, you could have a scenario where you're flowing from region A to region B to region C. If B has layout containment, or if B is a descendant of an element with layout containment and C is not a descendant of that same element, then C should receive no content, and B gets all the content that didn't fit into A even if that makes it overflow, as if it was the last region in the chain. If we're flowing from A to B to C to D, and both B and C are descendants of the same element with layout containment, C is the one that traps the rest of the content, not B.

If we didn't have this, then layout changes within the element with layout containment could affect the layout of the rest of the page, by way of changing what part of the fragmented flow flows out to a fragmentation container outside of the layout-contained element.

In the first sentence, what does it mean for a fragmentation context to "[participate] in layout containment"? Is this talking about the fragmentation context being established by a parent of the contained element, or established by the contained element itself, or by a child inside of a layout-contained element? Or some/all of the above?

a fragmentation context is a series of fragmentation containers. Talking about a fragmentation context that participates in layout containment is an attempt to talk about a fragmentation context where at least one of the fragment containers either has layout containment itself, or is a descendant of an element that does, and at least one of the other fragment containers is not.

If we consider pages, this cannot happen, since there is no selector that will let you apply containment to a page (and pages don't have ancestors).

For multicol, we also don't have (for now) selectors that let you apply containment to a single column, so that also cannot happen, and while you can put the entire multicol inside layout containment, then all the columns are inside, and that does not matter either.

However, if we consider either regions, or fragment overflow, then this becomes a possibility, since selectors can target the fragment container itself.

Similarly, what does "layout containment affecting the fragmentation context" mean? Would a tiny block descendant with contain:layout be considered to "affect" a fragmentation context that was established by its ancestor multicol element?

If all of the fragment containers in a fragmentation context are outside of layout containment (which is always the case for pages), or they are all inside of a single element with layout containment (which can be the case of multicol if the multicol itself or one of its ancestors has layout containment), the fragmentation context is not affected.

If some fragmentation containers establish layout containment themselves (which can happen with regions, :nth-fragment, or a hypothetical column selector), or if the several fragmentation containers are descendants of different elements with layout containment (which can only happen with regions), or if some fragmentation containers are descendants of an element with layout containment but other fragmentation containers are not (which can also only happen with regions), then the fragmentation context is affected.

In the second sentence, the phrase "the last fragmentation container within the first layout containment boundary" doesn't make sense to me... (in part because I'm not sure whether we're considering fragmentation containers that are ancestors or descendants of the layout-contained thing, as noted above). Hypothetically if this is talking about cases where the fragmentation container element is a parent of the layout-contained thing, then I don't know how it would generate fragmentation containers "within" a layout containment boundary. Alternately, if this is talking about cases where the fragmentation container element is the layout-contained thing (or is a child of the layout-contained thing),

It's the later one, "cases where the fragmentation container element is the layout-contained thing (or is a child of the layout-contained thing)".

then that phrase would trivially be describing the first fragment, and it sounds like there would simply be no fragmentation

Not necessarily:

<article>Lorem ipsum…</article>
<div id=a></div>
<aside>
  <div id=b></div>
  <div id=c></div>
</aside>
<aside>
  <div id=d></div>
  <div id=e></div>
</aside>
<div id=f></div>

article {flow-into: foo;}
#a, #b, #c, #d, #e, #f {flow-from: foo;}
aside {contain: layout}

The point here is to say that content can flow from a to b, from b to c, but that c, as the last fragment container in the first layout-contained element, traps all the remaining content, and nothing gets flowed into d, e, or f. And to say that in a way that not only apply to regions, but to any other region-like thing that me might later think of.

[dholbert]

Thanks for the clarifications!

[frivoal]

Now, if you have a suggestion at less terrible wording, I'm all ears. Otherwise, I'll try to think of something.

[dholbert]

I don't have specific suggestions, but my primary general request would be to make it clearer (in the spec) that this requirement is specifically about things that only matter for regions and ::nth-fragment syntax, and that (for now) multicol and printing-based fragmentation are unaffected.

(multicol and printing are the two commonly-implemented fragmentation modes, so they're what someone will naturally have in mind when reading spec text about interactions between a CSS feature & fragmentation. So if there's some spec text about fragmentation that happens to specifically not affect those common fragmentainers, it's probably useful to call that out somehow, to help the reader orient themselves.)