Re: Positioned Layout proposal

[snip]

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


Agreed.

Afaik, there is no way in current CSS to _SIMULTANEOUSLY_ position
relatively and take content out of normal flow (i.e. popup)?

http://www.w3.org/TR/CSS2/visuren.html#propdef-position

Thus, I note that taking the relative positioned element out of the normal
flow is the essense (key enabling difference) you are proposing?

Additionally afaics, you are proposing to generalize position:relative to
other reference points other than the top, left of the positioned element.

And I have generalized your proposal, to propose that we should also offer
relative sizing of the box width and height, so as to combine and
generalize the Flex-Layout proposal:

http://lists.w3.org/Archives/Public/www-style/2010Oct/0372.html


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


Agreed.

Can't do absolute positioning (positive:absolute) with relativity in CSS
without scripting. You must mean that the element you are positioning
relative to, is also absolutely positioned.  So this isn't relative at
all, it is hard-coded pre-computed positioning relationship.  Yeah
absolute positioning as you said.

And if you use position:relative, you reflow the normal flow in current
CSS, which isn't a popup functionality.


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


Agreed.

There is no relative positioning in current CSS that doesn't remove from
normal flow.


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


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


Agreed.

Is this inline?  CSS2.1 always relatively positions relative to the
element's position in normal flow, thus it has nothing to do with the
previous sibling, which might has been on the prior line due to line
wrapping.


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


Yup.


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


Yup.


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


Yup.


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


Yup.


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


Yup.

Received on Tuesday, 19 October 2010 16:43:48 UTC