RE: Positioned Layout proposal

> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, October 18, 2010 1:24 PM
> To: Sylvain Galineau
> Cc: www-style list
> Subject: 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.

Not sure I get the 'affects innerHTML et al' part of this, but OK.

> 2) Abpos a child above, below, or to the side of its parent to reveal
> extra information on hover.  

"Abspos a child above, below, or to the side of its parent" is not a
use-case. It describes how a particular use-case is expressed using the
feature. This seems a variation on the popup scenario above.

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

Not a description of a user scenario solved by the feature. This describes 
the CSS construct you can achieve using it.

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

Not a description of a user scenario solved by the feature. This describes 
the CSS construct you can achieve using it.

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

Not a description of a user scenario solved by the feature. This describes 
the CSS construct you can achieve using it.
 
> 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.)

A use-case is mentioned here - frozen table headers - but not sure
what the example is in this case.
 
> 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.)

Isn't this a special case of #8 ?

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

The demo layout is a use-case but that seems more of a grid layout scenario.
Is that intentional ?

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

Then the use-case is tooltips again.
 
> 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.)

How does that differ from #6, which also relates to frozen table headers ?

> 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 21:21:23 UTC