RE: Positioned Layout proposal

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 UTC