W3C home > Mailing lists > Public > www-style@w3.org > June 2012

Re: Sticky Positioning

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 28 Jun 2012 16:50:17 -0700
Cc: Edward O'Connor <eoconnor@apple.com>, www-style@w3.org
Message-id: <FFA0A930-8DB8-49F8-9C9B-47428120EF13@apple.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Jun 27, 2012, at 4:01 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Jun 27, 2012 at 10:32 AM, Edward O'Connor <eoconnor@apple.com> wrote:
>>> I think http://www.xanthir.com/blog/b48H0 addresses the same problem
>>> more generally.
>> The solution in Tab's blog post solves ALL THE PROBLEMS; it is
>> essentially a Grand Unified Theory for positioning. Which is
>> interesting, and definitely worth pursuing. But just because we *could*
>> describe a positioning value in terms of such a Grand Unified Theory
>> doesn't mean that we shouldn't make incremental improvements to the
>> platform now, and add such generalized features later when they're more
>> baked.
> Ignore the first part of that blog post.  Just look at the end, the
> "Containing the Positioned Element" section.  This bit is carveable
> from the rest of the proposal, and solves stickypos in a pretty simple
> way.
> If you want a heading that sticks when it gets within 10px of the top
> of the screen, make it "position: fixed; position-contain: parent;
> top: 10px;".  Or, alternately, "margin-top: 10px; position: relative;
> position-contain: viewport;"

Can you explain in a bit more detail the intended semantic of position-contain? From just your blog post, I can't tell the difference between the above two alternatives or whether either of them would do the same thing as as the proposed "position: sticky". 

My best inference from the blog post is that like the first option would not leave a placeholder, and would prevent the element from scrolling horizontally with its parent; and the latter would prevent the stuck element from ever leaving the screen, even when its parent does. But I might not be fully understanding it.

My best understanding of position: stick is:
- It leaves a placeholder like relative position would
- It positions relative to the intersection of its containing block and the viewport

This seems like a powerful combination for achieving many desirable scrolling effects without scripting. It seems like position-contain, while more complex and potentially harder to use correctly, doesn't provide a direct equivalent to positon:sticky by itself. For example, it seems like neither of the options you gave above would be suitable for the iOS Contacts style sticky headers use case.

I think the idea of a more general mechanism has some appeal. But at the same time, we need to ensure that:
(a) it actually would handle all the use cases; and
(b) it is simple to use for simple cases.

If we get to the point of needing three or four properties to do what could be done with one, then we should think about whether the general solution alone is sufficient. CSS does not have good abstraction mechanisms for packaging sets of properties and their values, so natural syntax for common cases can't be punted to libraries.

Received on Thursday, 28 June 2012 23:50:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:00 UTC