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

On 7/1/15, 2:34 PM, "Florian Rivoal" <florian@rivoal.net> wrote:

>
>> On 01 Jul 2015, at 21:51, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> 
>> On Wed, Jul 1, 2015 at 12:30 PM, Florian Rivoal <florian@rivoal.net>
>>wrote:
>>> 
>>>>> 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.
>>>>> 
>>>>> [...]
>>>>> 
>>>>> 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.
>
>This is tricky to phrase well. Which of these 2 (meant to be equivalent)
>do you like best?
>
>The first <a>CSS Region</a> in a region chain which is either:
>  - an element with <a>layout containment</a> itself or
>  - the last of one or more regions in this chain
>    to be descendants of the same element with <a>layout containment</a>
>is treated as if it was the last region in the chain, and gets all the
>remaining content in the associated <a>named flow</a>. Subsequent regions
>in the chain do not receive any content from the <a>named flow</a>.
>
>
>The first element with <a>layout containment</a> to either be a
><a>CSS Region</a> or to have descendents which are <a>CSS Regions</a>
>interrupts the <a>region chain</a> chain in the following way:
>  - if it is a <a>CSS Region<a> itself, it is treated as if
>    it was the last region in the chain, and gets all the remaining
>    content in the associated <a>named flow</a>.
>  - if it has decendants which are <a>CSS regions</a>, the last such
>    descendant in a particular region chain is treated as if it was
>    the last region in that chain, and gets all the remaining
>    content in the associated <a spec=css-regions>named flow</a>.
>Subsequent regions in the chain do not receive any content from the
><a>named flow</a>.

I still think this should be generalized to fragmentation contexts.

How about:

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. So the last fragment
container within the first layout containment boundary is treated as if it
is the last fragment container in its fragmentation context.
 
>
>If you like neither, can you suggest something better?
>
>In either case, we should probably also says what happens in the CSSOM.
>I suggest that:
>  - these subsequent regions that don't get content are
>    still considered part of the region chain as returned from the
>    getRegions() method of the NamedFlow interface (if you don't want
>    that, use contain:style)

Yes.

>  - the regionOverset attribute of the Region interface of the region
>    which eats all the content is set to overset if the content doesn't
>    fit. The current regions spec only allows this value on the last
>    region in the chain, but it's behaving as if it was.

Right, and the region-fragment property (or whatever the name ends up
being) should affect the “treated as the last” fragment container.

Thanks,

Alan

Received on Wednesday, 1 July 2015 22:32:25 UTC