Re: [css-containment][css-regions] how does containement and regions interact

On 7/1/15, 8:08 AM, "Florian Rivoal" <florian@rivoal.net> wrote:

>The current definition of the 'contain' property doesn't work well
>with regions. flow-from and flow-into are scoped to the contain:style
>container, but that's not enough, and regions make contain:layout
>ineffective when used without contain:style.
>
><article>
>  <div id=container>
>    <p>Lorem ipsum dolor sit amet...
>  </div>
>  <div id=container>
>    <div>...<table>...<tr>...<td>.../* arbitary nesting */
>       <p>Aenean vestibulum, dui eu bibendum sagittis...
>    </td>...</tr>...</table>...</div>
>  </div>
>  <p>Sed semper vehicula nisl ac dignissim...
></article>
>
><style>
>container {
>  contain:layout;
>  height: 100px;
>  width: 100px;
>}
>p { flow-into: my-flow; }

I think you need flow-into: my-flow contents; here, else you get a cycle
and no region chain.

>p { flow-from: my-flow; }
></style>
>
>You can't know what the content of the second or third <p>
>is going to be (and therefore you cannot lay them out)
>without first laying out the content of the preceding
>container. Which also means you cannot figure out the
>height of <article>, without doing a full layout of all
>its children, despite the presence of contain:layout on
>some of them.

Right - the second <p> doesn’t matter much, but the height of the third
<p> does depend on the breaks arrived at earlier in the region chain.

This isn’t specific to regions, I don’t think. It’s a problem with any
fragmentation context where fragment containers can be individually
styled. So it comes up with ::nth-fragment() and will come up with
::column if we pursue that avenue.

>
>In the best case, that means that UAs cannot do the type of
>optimizations you'd expect from contain:layout if regions
>are involved, and in the worst case, that means UAs can
>never to the type of optimization you'd expect from
>contain:layout because regions *might* be involved, and
>it's too hard to figure out if they actually are.

I’m not sure about this - what’s hard about detecting fragmentation
dependencies? I’m not against your solution (2) below for fragment
containers in general, but I’d like to make sure there’s sufficient
motivation for it.

>
>I see 2 ways out of that:
>
>1) merge layout and style containment
>
>2) add a region-specific rule to layout containment in addition
>to those in style containment. Here's one that should work:
>
>  The first (if any) region in a region chain that is either
>  a contain:layout element itself or the descendant of one is
>  treated as if it was the last region in the chain, and gets
>  all the remaining content in the associated named flow.
>  Subsequent regions in the chain do not receive any content
>  from the named flow.
>  
>You'll still need to walk the through the preceding regions
>in a region chain before you can layout the next one, but
>if any of them is in a contain:layout element, you don't need
>to lay it out before you can continue.
>
>Actually, we need to reword that so that if several regions
>of the same chain are descendants of the same contain:layout
>element, it's the last of one rather than the first, that should
>behave as the last one in the chain. But that's hard to phase well,
>so it's probably easier to understand my point with the definition
>above, even if we need to tweak it before putting it in the spec.
>
> - Florian
>
>

Received on Wednesday, 1 July 2015 16:00:24 UTC