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

On Wed, Jul 1, 2015 at 12:30 PM, Florian Rivoal <florian@rivoal.net> wrote:
> On 01 Jul 2015, at 20:22, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Jul 1, 2015 at 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; }
>>> 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.
>>>
>>> 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 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.
>>
>> I'm fine with layout containment also breaking region chains.
>
> By which you mean do what I said, or do the same as contain:style?

Either.  ^_^  But yours is less disruptive to regions in general; it
means you can still flow into a layout-contained element, and it
doesn't stop you from flowing *out* of one.  So yeah, yours is
preferable.

~TJ

Received on Wednesday, 1 July 2015 19:52:06 UTC