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


>> > Even if we do that, the size of a positioned element still affects the
>> > layout of its descendants, and therefore with your spec you can have
>> > cycles
>> > where some dependencies are explicit positioning constraints and some
>> > are
>> > implicit layout constraints.
>>
>> 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.
>
> 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.  I believe I can clear that
up with some careful wording.  I'm wondering if there are more complex
cases, though, involving specifics of layout modes.


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

Most of them are fine: tooltips, controls, and annotations are all
okay with this restriction.

The newsreader layout I described, though, isn't.  Any element can
expand in the three columns, and push down the elements in the other
columns, so there's no ordering you can provide that will ensure
you're always positioning relative to earlier elements.  However, it
would be possible to do it without referring to any later
non-positioned elements, so you can make an end-run around the "layout
produces a lot of complicated implicit constraints" problem.
Specifying my way around the implicit cycle problem above (mutually
referring to descendants) would then prevent the remaining issues, I
think.

Writing this will be "fun".

~TJ

Received on Tuesday, 19 October 2010 03:59:47 UTC