Re: [css-regions] Changing behavior of a named flow without a region chain

On Tue, Apr 23, 2013 at 12:36 PM, Alan Stearns <stearns@adobe.com> wrote:
> On 4/23/13 12:19 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>On Tue, Apr 23, 2013 at 11:10 AM, Alan Stearns <stearns@adobe.com> wrote:
>>> So a named flow without a region chain formats its content as normal, in
>>> place in the parent flow. It's only when you add flow-from that the
>>> display moves from its original location to the region chain. The
>>>behavior
>>> is exactly the same when you have a matched pair of flow-into and
>>> flow-from. The only change is when you're lacking the flow-from, the
>>> content does not disappear.
>>
>>I think this is reasonable a priori, but it may have knock-on effects.
>> It means that you can't lay out an element with flow-into until
>>you've finished resolving styles against the rest of the page, and
>>know whether or not there's an appropriate flow-from.
>>
>>Other layout modes can also require resolving styles against other
>>parts of the document before laying out an early element, but they
>>tend to be bounded in how far they can be affected.  This applies over
>>the entire document.
>
> I agree this could be an issue. It's somewhat analogous to setting
> 'display:flex' on the body element, and having an element at the end of a
> long page compute to 'order:-1', correct? If you're laying things out
> before the entire page resolves styles the boxes laid out earlier will
> jump down as everything lays out again.

Yes.

> We already have this problem if you have a very long page that starts with
> a flow-from element, and the flow-into elements come at the end of the
> page. You either lay out an empty region that pops open with content later
> on, or you have to wait until you've resolved styles on everything before
> laying out content in the region.
>
> I think the benefit of content not disappearing in all cases beats out the
> detriment of content laying out twice in some edge cases.

Okay, convincing to me.

~TJ

Received on Tuesday, 23 April 2013 23:36:51 UTC