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

> On 02 Jul 2015, at 00:31, Alan Stearns <stearns@adobe.com> wrote:
> 
> On 7/1/15, 2:34 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
> 
>> 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.

The intent is general, but the mechanics vary a bit by type of
fragmentation context.

A region chain is the only one which can have some fragmentainers
or a fragmentation context be descendants of an element with layout containment
and some other not (or descendant of another one).

Some times of fragmentation contexts generate more fragmentainers when there's
content left in the flow (like nth-fragment or good old pages), and some don't
(like regions).

This makes the generic phrasing more complicated. But at the same time, if
we can get a generic phrasing to work, this is more robust and extensible, so
let's give it a shot.

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

Not bad :) You took something awkward to phrase, generalized it to a broader
situation, and still managed to craft a sentence that makes sense.

I'd add:

  If subsequent fragmentation containers in the fragmentation context
  are only generated when more content remains in the fragmented flow,
  then they are not generated. If they would exist regardless, they
  remain part of the fragmentation context, but do no receive any content
  from the fragmented flow.

  Specifically:
    - CSS Regions following the one which traps the content are still
      considered part of the region chain as returned by the
      getRegions() method of the NamedFlow interface.
    - the regionOverset attribute of the Region interface of the region
      which traps the content is set to overset if the content doesn't
      fit, even if it is not the last region in the region chain.
    - If the computed value of the continue property on an element with
      layout containment would otherwise have been ''auto'' or
      ''fragments'', it must instead compute to ''overflow''.


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

That spec isn't stable yet, but I'm already removing this restriction
anyway, and allowing break (renamed to discard), and other values on
non last regions. The wording above works based on that.

 - Florian
PS: fragment no longer looks like a real word to me.

Received on Thursday, 2 July 2015 10:28:26 UTC