Re: Positioned Layout proposal

> On 10/20/10 9:09 AM, Shelby Moore wrote:
>>>   Any sort of sane pagination algorithm not only
>>> depends on the layout but also modifies the layout (for a simple
>>> example, the heights of auto-height blocks end up depending on where on
>>> the page the top content edge of the block appears).  As such it needs
>>> to hook into the layout process, and complications to the layout model
>>> also complicate pagination.
>>
>> My point is that as long as the proposed spec only changes the position
>> and size of their containing block within the box model, they the
>> relative
>> position and size constraint solver is orthogonal to those pagination,
>> overflow, etc hooks.
>
> And my point is that positions of objects determine where page breaks
> happen, page break locations affect sizes of containing blocks, and
> sizes of containing blocks affect positions of objects.
>
> Depending on how this interaction is implemented, changing the set of
> ways in which page break locations change the positions of objects may
> make the determination of page break locations more complicated.

I don't yet see how this would be not orthogonal in any case, except for
incorrect implementation design.

The pagination algorithm tests the containing block for intersection with
the page boundary, then it flags the constraint and re-runs the layout
(which calls the various constraint algorithms).  This repeats until there
are no more intersections.

You optimize this for incremental updates, by making special case rules
about how certain constructs can change layout when changed, e.g.
identifying propogation boundaries, but you still need the generalized
algorithm above for those cases that your special case optimizer can't
handle.

Am I far off base?

Received on Wednesday, 20 October 2010 17:38:46 UTC