W3C home > Mailing lists > Public > www-style@w3.org > January 2014

Re: [css-regions] performance of regions fragmentation

From: Alan Stearns <stearns@adobe.com>
Date: Thu, 23 Jan 2014 18:44:21 +0000
To: François REMY <francois.remy.dev@outlook.com>, "'L. David Baron'" <dbaron@dbaron.org>
CC: 'Tab Atkins Jr.' <jackalmage@gmail.com>, 'Brian Kardell' <bkardell@gmail.com>, 'Johannes Wilm' <johannes@fiduswriter.org>, "'www-style list'" <www-style@w3.org>, 'Håkon Wium Lie' <howcome@opera.com>
Message-ID: <CF06A10A.36912%stearns@adobe.com>
On 1/23/14, 10:25 AM, "François REMY" <francois.remy.dev@outlook.com>

>± 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
>± have in the specification is there specifically to limit the performance
>± implications of fragmentation in edge cases. The point of section 7 is
>± 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,
>± you combine features complexity goes up. I don’t see anything special
>± 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

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.



Received on Thursday, 23 January 2014 18:44:57 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:36 UTC