Re: [css-regions] performance of regions fragmentation

On 1/23/14, 10:25 AM, "François REMY" <francois.remy.dev@outlook.com>
wrote:

>± On 1/22/14, 10:41 PM, "L. David Baron" <dbaron@dbaron.org> wrote:
>± > I think CSS regions make a very poor primitive because they have very
>± > poor performance in interesting cases.  Rather than always having a
>± > simple and fast behavior, they have behavior that requires
>± > multiple-pass layout in some cases (especially when combined with
>± > other features like CSS Exclusions).
>± 
>± I disagree with your characterization of ‘very poor performance’ - what
>we
>± have in the specification is there specifically to limit the performance
>± implications of fragmentation in edge cases. The point of section 7 is
>to
>± optimize for performance, and limit the requirements to two-pass layout
>± (not multiple-pass layout).
>± 
>± I’m not sure what you mean about combining with CSS Exclusions. Yes,
>when
>± you combine features complexity goes up. I don’t see anything special
>about
>± the combination of regions and exclusions.
>
>I'm not into David's head but my take is that there's a strong assumption
>in the region layout code that is not possible to express in CSS right
>now: layout independence. To clarify, layout code makes the assumption
>that the following regions will not affect the layout of the previous
>regions.

No, we don’t assume layout independence. That’s why we have step 3 - if
you’re in a situation (like table layout, or flexbox, or the example you
provide) where the sizing of one region depends on the height of a
following region, you take the sizing from step 2 and flow content through
regions of that size. In some cases this ends up being not what I would
want in a layout, but it’s consistent and fast.

>Please note that this is not a CSS Regions issue, though, because you
>could in fact replace the two DIVs by overflow fragments which David
>claims provide saner semantics. Solving this issue is non-trivial and may
>be worth some discussion.

Yes, it’s an issue for overflow:fragments as well. It’s also related to
multicol balancing. Anything that ties a particular fragment break with
later fragmentation decisions runs into this problem. I agree it’s
non-trivial, which is why the regions spec doesn’t provide a full
solution. We stop at the second layout pass for the sake of performance
and leave it up to higher-level fragmentation systems to provide a better
answer for particular use cases.

Thanks,

Alan