Re: Positioned Layout proposal

On Tue, Oct 19, 2010 at 3:12 PM, Shelby Moore <shelby@coolpage.com> wrote:
> But a circular oscillating constraints is not the same as an unsolvable
> constraint, in the sense that the above has two oscillating bounds as a
> "solution space" (browser can pick one?) and the case we discuss below has
> no solution.

Right; an oscillating constraint merely needs a deterministic method
to settle on one answer.  Right now, there is no such method
specified, so I need to ensure that I make one.


> Overflow won't be any more of a problem than than the way it is handled
> cleverly above.

Well, you have to be a little roundabout.  I can't just specify
Firefox's behavior, because overflow handling is UA-dependent.  I just
have to state the constraint such that, if the overflow method changes
the layout in such a way that the element no longer suffers from
overflow, the element continues to act as if it was suffering from
overflow, but with the scrolling method inactivated.


> We can say that if one specifies circular constraints, they get an error
> condition and reversion to normal flow?

Not sure how *exactly* I want to specify it, but that's one way (just
collapse the entire cycle back to non-positioned).  Another choice is
to pick an arbitrary-but-deterministic link in the cycle and break it
(setting some element to 'position-root: self', which is guaranteed to
not cause cycle issues).


> How to explain it more clearly than that? Because for example even
> siblings can be circular, e.g. ((elem1 left of elem2) left of elem3) left
> of elem1.

It's not the sibling reference that's circular there.  The siblings
are fine.  It's the final one, where elem1 and elem3 are tied
together.


>>  I'm wondering if there are more complex
>> cases, though, involving specifics of layout modes.
>
>
> The more I think about this, all cases of circular constraints can be
> searched in real-time. There is no complex math involved, because this is
> just an element tree hierarchy search.

If you just pay attention to the constraints introduced by Positioned
Layout, you're right.  But think about Table Layout.  There, every
element has multiple implicit constraints tying it to all its previous
and following siblings on the row, the row itself, cells in different
rows but the same column, the column itself, row groups, col groups,
and finally the table itself.  I'm not willing to state that this web
of constraints can't produce cycles that are more expensive to suss
out.


> Afaics, Boris's comment[D] means that existing layout engines know how to
> handle 'position:absolute' children, because (it is a hierarchal box
> model[C] where) their parent bounds the union of their 2D content extents.
>
> As for relative positioning that pulls out of the normal flow, this is not
> compatible with existing layout engines, unless we also make these bounded
> by their parent's 2D extent?
>
> [D] http://lists.w3.org/Archives/Public/www-style/2010Oct/0378.html

I believe the important bit is that existing layout engines can handle
position:absolute elements because they always reference boxes earlier
in the tree.  It's impossible to create cycles when you have a
restriction like that.  (You can maybe create oscillating constraints,
but that's a different issue.)

Unfortunately, that's slightly too restrictive for one of the
use-cases I have, so I'm experimenting with ways to safely allow
references to elements later in the document so that cycles are easy
to detect and break.

~TJ

Received on Tuesday, 19 October 2010 23:43:57 UTC