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

> On 01 Jul 2015, at 17:59, Alan Stearns <stearns@adobe.com> wrote:
> 
> 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.

Oops. Yes, that's what I meant.

>> 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.

The second p does matter. layout containment should mean that you can
do the layout of the first and second <p>'s content in parallel of
each other, and now you can't.

> 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.

Good point. I had only considered when the parent is a container,
and only regions can escape that. But you are correct that any
fragmentainer that can be directly styled as a layout container
is also an issue.

For the continue/fragmentation/break-target/whatever-we-call-it
property, we can probably affect the computed value so that it
doesn't generate fragments if either contain:layout or
contain:style is on.

Is there any other type of fragmentainer to which the contain
property can be applied?

>> 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.

Even if you can detect them, it's still bad. The goal of the contain
property is to give you an easy switch to isolate things no matter what,
so that you don't have to think about subtle property interactions.
Disabling the optimizations when regions are involved isn't as bad
as killing them always, but it's still bad.

As you say, this should be detectable, but this detection brings
in some complexity, which can mean bugs, or performance impact,
or both.

>> 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 17:50:17 UTC