Re: Positioned Layout proposal

> On Mon, Oct 18, 2010 at 6:29 PM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>> On Tue, Oct 19, 2010 at 1:56 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>>
>>> This problem is a much more general one, and cycles of this nature are
>>> possible to create with existing CSS.  For example, percentages in
>>> padding-top refer to the width of the box.  In some cases this can
>>> create a box which is tall enough to create overflow vertical overflow
>>> in its parent.  Generating the scrollbar reduces the width, though,
>>> which will reduce the amount of padding as well, possibly making the
>>> element short enough to no longer generate overflow in its parent.


I have also seen that the browsers can not settle on a constraint in one
iteration of a repeatable case.  I thought it was a bug, and now I see it
might be due to circular oscillating constraints.

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.


>>> I believe there are other methods that can do similar things.
>>>
>>> In this case, I don't think the behavior is defined, but I think
>>> Firefox has a good answer - generate the scrollbars, but make them
>>> inactive.  That reveals the full content while reducing the WTF to a
>>> minimum.


Clever.


>>> Is this behavior something we can specify in CSS?  If so, then at
>>> least some of the cycle behavior can be dealt with.
>>
>> You're right that it's an existing problem, but your proposal makes it
>> significantly worse, so I think it's something we need to deal with now.
>
> I agree.  I'm curious as to what level is appropriate for this.  Can I
> specify overflow behavior directly?  I suspect not, given the
> platform-dependence of scroll behaviors.  I'll probably have to just
> be general about scrolling behavior changing the size of the box, and
> how to resolve cycles based on this.


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


[snip]


>>> Can you expand on this?  I know that, in general, you can create
>>> cycles by referring to descendants; I'll go ahead and add a note so I
>>> don't forget that.  This can only happen when the element() function
>>> is being used to specify a root edge.


Siblings can cause circular constraints. See below...


>> Consider elements E1 and E2 with descendants D1 and D2, where E1's
>> position
>> depends on D2 and E2's position depends on D1.
>
> Yeah, that's the canonical "complex" case.


The constraint solver will report "unsolvable" because it searches all the
possibilities and can not find a reference point (everything is circular).

On such error, the elements are placed back into normal flow?


> I believe I can clear that
> up with some careful wording.


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

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.


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

I rescind my statement from my first post about unsolvable constraints[A],
because I now understand that relative-positioning to other elements will
always be removed from _localized_ normal flow[B]. Meaning their parent
can still optionally be in normal flow and they will expand their parent's
box?[C], but this won't cause any conceptual hardship to the existing
layout engines that isn't already conceptually handled with
'position:relative'.

Thus the constraint solver has to disallow that any relative position (or
size if we integrate Flex-Layout) can between elements (even indirectly)
that resolve to different parents in normal flow. I think that is the key
algorithm insight?

[A] http://lists.w3.org/Archives/Public/www-style/2010Oct/0372.html
[B] http://lists.w3.org/Archives/Public/www-style/2010Oct/0386.html
[C] http://lists.w3.org/Archives/Public/www-style/2010Oct/0398.html

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 think that all the cycle problems not dealing with scrollbars are
>>> enabled by the element() function?  The other values dont' seem like
>>> they should create any problems that don't already exist with
>>> positioning.
>>
>> You're probably right.


Ditto what I wrote above.


>> If we added a requirement that the referenced element be earlier in the
>> document than the positioned element, how many of your use-cases would
>> be
>> adversely affected? That requirement would help a lot.


How does that help? Or why is that necessary?

[snip]

Received on Tuesday, 19 October 2010 22:12:34 UTC