Re: Positioned Layout proposal

On Tue, Oct 19, 2010 at 9:43 AM, Shelby Moore <shelby@coolpage.com> wrote:
> [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

I don't believe it is worthwhile to attempt to generalize this enough
to somehow solve the problems of both Positioned Layout and Flexbox
Layout.  The two are intended to solve different features, and involve
different types of constraints.  While it is possible in principle to
merge them, I believe it would be too confusing to authors and too
expensive for browsers (as you'd probably need to do something like
simulated annealing to solve the constraints).

Instead, I believe it's best to design separate layout models that are
powerful by themselves and well-designed for solving particular
use-cases.  The current set of new layout models I'm pushing
(Positioned, Flexbox, and Template) all satisfy this.


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

No, I just meant what I said.  Given a normal-flow parent, I want to
position a child to one side of it.  For example, in my blog post
composer, I have a listing of all my blogposts, with each entry
showing just the name of the post initially.  On hover, the
creation/publication date is revealed.  I'm doing this guessing at the
height of the date element, and then setting its 'bottom'
appropriately to pull it below the parent.

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

Be careful with your terms here - relative positioning (with
"position:relative") keeps the element in normal flow.

~TJ

Received on Tuesday, 19 October 2010 17:04:08 UTC