Re: Sticky Positioning

I was also discussing this with jamesr just last week, we definitely agree
the problem needs addressing.

Like Ojan, I prefer a "position-contain" type approach as it's more
general.  For an example of a site that would benefit, if you visit
http://google.com/ on a phone and tap "Restaurants", you'll get to a search
results view with a fixed-positioned map with the "sticky"-style behavior
(simulated in JS).  Observe that the map drops out of view when you reach
the bottom of the page, which I don't think is expressible by "sticky".


There is another use case prominent in our minds, which is to start
addressing the broken/undefined behavior of fixed-position in the presence
of pinch zoom gestures.  "position-contain" could allow webmasters to
restrict fixed-position elements so they don't spill over important areas
of the page when pinch zoom comes into play.  For example, when there is a
fixed-pos box meant to live in the left margin of a text paragraph, it
could be restricted explicitly to that margin.

(There is a wider discussion to be had around pinch zoom/fixed-pos, but I
mainly want to emphasize that it will be an increasing problem as
touchscreens get more common, and we should make sure new fixed-pos-related
features build towards a framework that addresses it.)

On Tue, Jun 26, 2012 at 9:30 PM, Ojan Vafai <ojan@chromium.org> wrote:

> On Tue, Jun 26, 2012 at 4:50 PM, Edward O'Connor <eoconnor@apple.com>wrote:
>
>> Hi,
>>
>> Many web sites have elements that alternate between being in-flow and
>> being position:fixed, depending on the user's scroll position. This is
>> often done for elements in a sidebar that the page author desires to be
>> always available as the user scrolls, but which slot into a space on the
>> page when scrolled to the top. It can also be done for table headers
>> which remain visible after the top of the table has been scrolled off-
>> screen.
>>
>> Lots of sites, such as news.google.com (the "Top Stories" sidebar) and
>> yelp.com (the search results map), use scroll event listeners in
>> JavaScript to achive this effect. However, browsers are increasingly
>> moving towards scrolling implementations that make use of hardware
>> acceleration to improve performance, for example by leveraging the GPU,
>> and doing scrolling on a thread other than the main UI thread.
>>
>> In this situation, browsers may use fast scrolling but fire scroll
>> events asynchronously, which will result in rendering glitches on pages
>> that update element positions from JavaScript via scroll events.
>> Alternatively, the browser may fall into a slow scrolling mode when
>> scroll events are listened for; this impacts the perceived quality of
>> the browser's scrolling. To address this problem, common scrolling
>> behaviors like this should be exposed declaratively, through CSS.
>>
>> A feature like this has been a long time coming. It was first proposed
>> (for table headers) by the OEBPS (EPUB) folks on www-style in 2002[1]:
>>
>> > One of the examples of the desired layout\formatting behavior would be
>> > that the header column would stay frozen if horizontal scrolling is
>> > required to view additional columns of the table (similar to the
>> > "Freeze Panes" option in Excel).
>>
>> Mikko Rantalainen proposed generalizing such a feature to elements other
>> than table headers[2]:
>>
>> > Perhaps a new position value (e.g. "fixed-relative") that is a mix of
>> > "relative" and "fixed": the content still reserves space in the flow
>> > similar to relative but it would be displayed as fixed if the element
>> > would not fit in the viewport but its containing block is visible. In
>> > that case, the element would be "moved" within its containing block
>> > until it would fully fit in the viewport.
>>
>> Mikko's proposal is very close to what we have in mind: a new value for
>> the 'position' property, similar to relpos, but with a new method of
>> calculating the element's offset.
>>
>> You'd use it like this:
>>
>> h1 {
>>  position: sticky;
>>  top: 10px;
>> }
>>
>> This means that every <h1> in the document will "stick" 10 pixels from
>> the viewport top when things scroll such that the <h1> would have been
>> partially off-screen. When the viewport has scrolled such that the
>> visible portion of the <h1>'s containing box is too small to fit the
>> <h1>, it should stop at the containing box's edge and only be partially
>> displayed.
>>
>> There are a lot of details to work out, of course. Doug raised several
>> questions about such a feature in [3]; here are some preliminary
>> thoughts on them.
>>
>> Doug wrote:
>> > * should sticky content accumulate?
>>
>> No. In some future level of this feature, it might be worth
>> investigating a new property or set of properties which could cause such
>> accumulation. We should avoid this problem in the first level of this
>> feature by having the sticky elements simply overlap, just as other
>> positioned elements do.
>>
>> Doug wrote:
>> > * what should be the behavior when a user jumps to the middle of a
>> >   containing block that would otherwise have a sticky header/footer
>> >   when scrolled (e.g. a row in the middle of a very long table, a
>> >   paragraph under a sticky <h2> itself under a sticky <h1>)? (I think
>> >   it the sticky content effect should be applied, though I suspect
>> >   this will make implementation rather more difficult.)
>>
>> The sticky effect should be applied, just like any other positioning
>> scheme.
>>
>> Doug wrote:
>> > * should there be an event that is thrown when content sticks, so
>> >   that the author can choose to enhance the effect via script or
>> >   declarative animation?
>>
>> No. A big advantage of this feature over emulations of it in JS is the
>> lack of events.
>>
>
> Great use-case. Something long-overdue for CSS to address. Some other
> related use-cases:
> 1. positioning an element with respect to another element (e.g. a rich
> tooltip or formatting bar) without exceeding the bounds of the viewport.
> 2. sticking an element to a boundary other than the viewport
>
> I think http://www.xanthir.com/blog/b48H0 addresses the same problem more
> generally. The proposed solution to your use-case is hidden in the last
> paragraph, i.e. add the position-contain/position-restrict property instead
> of adding a new position value. This proposal also gives added flexibility
> of whether you want the element to take part in layout. You can get sticky
> behavior with absolute or relative positioning.
>
> For now, in order to address your use-case, we could just spec and
> implement position-contain/position-restrict. position-root is only needed
> for use-case 1 above and is a bit orthogonal I think.
>
> Ojan
>
>
>>
>>
>> Thanks,
>> Ted
>>
>> 1. http://lists.w3.org/Archives/Public/www-style/2002May/0153.html
>> 2. http://lists.w3.org/Archives/Public/www-style/2009Dec/0165.html
>> 3. http://lists.w3.org/Archives/Public/www-style/2009Dec/0204.html
>>
>>
>