W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: Positioned Layout proposal

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 18 Oct 2010 14:34:02 -0700
Message-ID: <AANLkTi=MLh1a7rdY0QOHQ0yGY_zh6bM9F4ZV7TfFJSKk@mail.gmail.com>
To: Sylvain Galineau <sylvaing@microsoft.com>
Cc: www-style list <www-style@w3.org>
On Mon, Oct 18, 2010 at 2:20 PM, Sylvain Galineau
<sylvaing@microsoft.com> wrote:
>> 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.

The tooltip isn't actually part of the content.  If you're, for
example, saving the contents of a contenteditable element via XHR, you
don't want a spellcheck tooltip to show up in the saved data.  In
order to use auto positioning, though, you need to insert the tooltip
element into the content, which would have precisely that problem.

You can do filtering to strip out things like that, but that's
annoying.  As well, the auto position is still only *occasionally*
useful.


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

Sure it is.  I could try and avoid using existing CSS terminology, but
what's the point?  I have some block, I want to show some info to the
side of it on hover without affecting the geometry.  I do that right
now with my blog composer - the list of blog posts pops down some
metadata 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.
>
> Not a description of a user scenario solved by the feature. This describes
> the CSS construct you can achieve using it.

Again, I could avoid using CSS terminology, but it wouldn't gain me
anything.  I want to "position" an element relative to the body while
an ancestor is relpos for an unrelated styling reason.  I used the
word "abspos" instead, but of course anything could potentially be
used to resolve that.


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

Again, no it's not, for the same reasons.


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

Not sure what you mean here.  I didn't even use the words "abspos" or
"relpos" here.  There's no mention, even implicitly, of any CSS
constructs (unless you count the word 'position', but that's the
entire point of this case).


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

I'm not sure what you mean.  What don't you understand?  I can try to
explain better.


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

Not as far as I can tell.  Can you elaborate as to how you think #8 is
a more general form?


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

I tried solving the layout with some form of grid layout.  I couldn't
figure out how to do it cleanly, but it's certainly possible.


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

Sure, but a different aspect of tooltips that should be captured
separately.  I could just say "tooltips!", but then it's possible to
accidentally overlook one of the requirements for tooltips when
formulating a solution.


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

Same as previous - it's an additional aspect of the use-case of
"frozen table headers".

~TJ
Received on Monday, 18 October 2010 21:34:55 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT