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

RE: Positioned Layout proposal

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Mon, 18 Oct 2010 21:44:17 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E280AE7C4@TK5EX14MBXC115.redmond.corp.microsoft.com>
CSS terminology is not what I'm asking for.
Your draft spec already tells me what the 
feature does in CSS terms.

What design scenario is solved by this particular
construct ? What is the author trying to achieve on 
the page for the user's benefit ? I could describe 
how adjoining floats can be merged in CSS terms; that 
doesn't tell anyone what scenario it's useful for.

Your email below describes *how* some use-case is
resolved by your proposal in CSS terms without 
defining what the actual use-case is. 

Positioning tooltips is a use-case. Ojan's scenario
to allow the positioning of resizing icons over an
image is a use-case. Freezing table headers is a use-case.
These are really helpful in framing the proposal and judging
its value.

"Abspos a child above, below, or to the side of its parent"
is not. Sorry...




> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Monday, October 18, 2010 2:34 PM
> To: Sylvain Galineau
> Cc: www-style list
> Subject: Re: Positioned Layout proposal
> 
> 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:44:54 GMT

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