Re: Positioned Layout proposal

Also: positioning something outside of, but relative to the edge of an element with overflow:<not visible>.


On Oct 18, 2010, at 1:23 PM, Tab Atkins Jr. wrote:

> 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 Tuesday, 19 October 2010 03:44:20 UTC