Re: Positioned Layout proposal

On Mon, Oct 18, 2010 at 4:25 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Unfortunately, the problem of cyclic dependencies is very serious. It's not
> restricted to cycles of explicit positioning constraints.
>
> For example, the geometry of positioned elements can affect whether
> overflow:auto elements have overflow, which affects whether scrollbars are
> present, which can affect the available width and hence the layout of any of
> the descendants of the overflow:auto element. Furthermore, the presence or
> absence of a horizontal scrollbar can affect the height of an element and
> hence the positions of many other elements inside and outside the
> overflow:auto element. The only way I can think of to resolve those issues
> in a sane way for your spec would be to have your specially positioned
> elements not contribute to the "scrollable overflow area" of any of their
> ancestor elements. That may cause problems for some of your use cases.

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.


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

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.

In particular, any problems with 'self' should probably already be
present with auto-positioned abspos element.  I think that 'previous'
should be roughly similar to 'self', and don't immediately see any
cycle problems with it.  'container' is just a functionality that
already exists, as is 'root' (it generates the ICB) and 'viewport'
(for fixpos).  'parent' should be the same as 'container' in terms of
issues, as the container often *is* the parent.

I don't *believe* any substantial new issues are introduced by being
able to refer to the edges of different elements either.  For example,
any issues caused by setting top/bottom to container and left/right to
window should be similarly caused by just making a normal abspos
really wide.

Similarly, I don't think that using the *most() functions with any of
the predefined keywords should cause any problems that don't already
exist with positioned elements.

So, the problem is the ability to reference arbitrary elements with
the element() function.  Unfortunately, it's necessary for several
important use-cases: positioning popups, edit handles on images,
positioning out-of-band annotations next to the referred text, etc.
It's also completely innocent in many of these cases, and fairly easy
to resolve.  For example, we don't have any problems with using the
equivalent of element() rooting in our newsreader layout driven by a
js constraint solver.  We're also doing basically the entire layout of
the page in either constraint-driven abspos or vanilla fixpos, though,
with only the insides of the blocks using static layout, so there's
not much chance of any implicit cycles getting created.

I suspect I can eliminate a lot of implicit cycles with some careful
text about ancestors and descendants.  I'll have to think more about
if there are many remaining cases; I'd like to avoid listing the
implicit constraints for every layout mode for use in cycle-checking,
but I'll do so if necessary.

~TJ

Received on Tuesday, 19 October 2010 00:57:38 UTC