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

On 7/2/15, 3:27 AM, "Florian Rivoal" <florian@rivoal.net> wrote:

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

This all looks good to me. I like the general rules followed by specific
applications of those rules.

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

Yeah, it’s been like that for me since ‘fragmentainer’ was coined.

Thanks,

Alan

Received on Thursday, 2 July 2015 14:00:55 UTC