Re: [csswg-drafts] [css-contain] Need clarification on layout containment & fragmentation

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](https://drafts.csswg.org/css-overflow-4/#fragment-overflow), or potential future selectors for individual columns in a multicol.

Now, this is all annoying to phrase, because we should not have an dependency on any of these, since none of them ares 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.

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 situations 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 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](https://drafts.csswg.org/css-overflow-4/#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:
```html
<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>
```
```css
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.





-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2840#issuecomment-401249631 using your GitHub account

Received on Friday, 29 June 2018 05:14:39 UTC