Re: Positioned Layout proposal

On Mon, Oct 18, 2010 at 12:52 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
>> Behalf Of Tab Atkins Jr.
>> Sent: Monday, October 18, 2010 12:32 PM
>> To: www-style list
>> Subject: Positioned Layout proposal
>>
>> Since I've worked at Chrome, one of the things I've heard developers
>> complain about a lot is the weakness of absolute positioning.  For
>> example, our app devs commonly want to position tooltips relative to
>> arbitrary elements in a contenteditable area.
>
> More use-cases would be helpful.

Sure.

1) Positioning tooltips and other "popup" information on arbitrary
elements.  (CSS currently fails for this, as you must either make the
popup a child in some appropriate position so you can rely on the auto
position, which is hacky and affects innerHTML et al, or use JS to
measure and manually set the position, which becomes invalid if the
element moves around on the screen.

2) Abpos a child above, below, or to the side of its parent to reveal
extra information on hover.  (CSS currently fails for this because
each edge is measured relative to the same edge of the containing
block.  Thus you can only, for example, position an element below its
containing block if you know the height of the element (to set
'bottom' to an appropriate negative length).)

3) Abspos an element relative to the body while an ancestor is relpos
for an unrelated styling reason.  (CSS currently fails for this
because you can't specify what you want to position yourself relative
to - you're automatically relative to the nearest positioned ancestor,
even if that ancestor's positioning is completely unrelated.)

4) Relpos an element for styling reasons without affecting the
positions of any positioned descendants.  (CSS fails this for the
reasons stated above.)

5) Position an element relative to its previous sibling.  (CSS fails
for this because positioning is always done relative to the containing
block; relying on auto positioning *sometimes* works for this, but
you're very limited in what you can do there.)

6) Keep an element in-flow for geometry purposes (like what relpos
does), while positioning it relative to some other element, like how
frozen table headers work.  (CSS currently fails this because relpos
elements can only measure their edges relative to their original
position.)

7) Make an element fill the screen horizontally (left and right edges
against the edges of the body or viewport), while positioning it
relative to another element vertically.  (CSS currently fails for this
because all edges are relative to the same element.)

8) Position an element such that it stays below the lowest of several
elements.  (Demonstrated by the demo app's layout.  CSS currently
fails for this because the relative edge comes from a single element -
the containing block.)

9) Position an element, but ensure that it stays within the bounds of
another element, regardless of the width/height of the positioned
element.  For example, tooltips should always be visible, staying
within the viewport even if the element they're showing for is near
the edge of the screen. (CSS currently fails for this because abspos
doesn't have any way of expressing higher-level constraints on edges.
It also can't express a constraint relative to the viewport while the
element is positioned relative to a containing block.)

10) Frozen table headers, or more generally, keeping an element
visible when it would otherwise scroll off the screen, as long as some
container element is still on the screen.  (CSS currently fails for
this because, well, it simply can't do it.)

My proposal currently addresses everything but #4 directly (#4 can be
done by manually setting the descendants' position-root).

~TJ

Received on Monday, 18 October 2010 20:24:48 UTC