Re: Positioned Layout proposal

>> 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.

+1

>> 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.

My +1 above meant I think you propose to add a CSS setting to specify
which choice is made (the solution space choices):

* disabled scrollbar
* expand the element (until no more overflow)
* contract the element (until no more overflow)

>> 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).

The determinism would come from order, e.g. first specified which has a
circular path becomes 'position:inherit'? (note I think we can reuse and
extend the existing CSS 'position')

The reason I don't like that, is it would allow erroneous cases to be
adopted by trial&error designers, e.g. my "((elem1 left of elem2) left of
elem3) left of elem1" would display as "(elem2 left of elem3) left of
elem1".

Also it wouldn't be deterministic but rather like noise (aliasing error).
I prefer to hard fail back to non-positioned.

>> 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.

Agreed. My point was that restricting the relative relationships to
siblings, does not eliminate the possibility of unsolvable circular
constraint.

>>>  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.

Agreed, that is why I said no float or table elements can be relatively
positioned. And that is why I added the constraint that no tree of
relative positions can resolve to live in 2 different positions in normal
flow. If those requirements are violated, hard fail.

>> 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.

That is what I meant too. Their 2D extent, i.e. their impact on layout
issues, is bounded by their parent. As long as we keep our generalized
spec within that, then the existing layout engines can accomodate our spec
without a major refactor.

>  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.)

Can still create unsolvable constraints in that model, but they are fewer
and more easy to pre-plan around:

<div style='position:absolute; width:51%'></div>
<div style='position:absolute; width:51%'></div>

That is just a special case of siblings constraints that are unsolvable. 
We special case that one, because it is common and it has a logical
solution.

> 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.

I think I already provided the general rule for what needs to be detected
as hard fail by the constraint solver where I wrote "...And that is why I
added the constraint that no tree of relative positions can resolve to
live in 2 different positions in normal flow. If those requirements are
violated, hard fail."

Received on Wednesday, 20 October 2010 03:13:11 UTC