Re: Sticky Positioning

On Jun 27, 2012, at 6:44 pm, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Edward O'Connor wrote:
>> 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.
> 
> Putting something at the side is very different from putting something
> at the top or bottom. At the side sticky elements don't tend to occlude
> content, but they do at the top and bottom, and menacingly so. Typical
> toolbar-like elements for instance usually break scrolling using page-
> up and page-down keys, and they become very obnoxious when zooming, as
> they grow far too big, not to mention that they require the user to ad-
> just to a new reading position, which I find extremely annoying. I have
> in fact "Hide position:fixed" as the first item in the right click menu
> in the browser I use the most to escape this kind of UI horror.

What you say may be true (in languages with top-to-bottom writing modes),
but I'm not sure how this informs on the proposal. Side-sticky would be
just as easy with this proposal as top-sticky.

> 
>> 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;
>> }
> 
> If you consider the case of a toolbar that initially is at the top of a
> page and then sticks there as the user scrolls down, it seems erroneous
> to me that the scroll bar would extend past the toolbar. I would expect
> 
>  [button] [button] [button] [button] 
>  +--------- Content Area ----------+ ^
>   ...                                |
>   ...                                |
>   ...                                |
>  +---------------------------------+ v
> 
> while currently you would get (the scrollbar extends into the toolbar)
> 
>  [button] [button] [button] [button] ^
>  +--------- Content Area ----------+ |
>   ...                                |
>   ...                                |
>   ...                                |
>  +---------------------------------+ v
> 
> This is one reason why page-up and page-down scrolling is broken by such
> "sticky" elements, the browser is unaware of the toolbar occluding the
> content in a bad way, so it keeps using the height of toolbar+content to
> determine how much a page should be scrolled using the keys. Elements on
> the side, in contrast, do not cause such problems. Your proposal doesn't
> seem to address this.

Authors could achieve your first layout by either using <iframe> (ick),
or by bypassing main page scrolling altogether, and putting the content area
into an overflow:scroll element.

I think it's too much to ask the UA to automatically adjust where to
display main-page scrollbars based on fixed or sticky elements in the
content, and this problem is not new. I don't think we need to solve
this problem before we specify sticky position.

> I also note that real-world uses tend to be a bit more complex, cnet.com
> for instance hides the bottom toolbar once you scroll past the content
> area (or rather, it places it at the end of the content area above the
> footer).

I don't see that (Safari/Mac). I do see that the "Top Categories" section
is an ideal candidate for position:sticky, but the header and footer just
scroll with the page for me.

> As far as I can tell, your proposal does not account for that,
> and it is unclear to me that this is relatively uncommon.

If you find a page doing a common sticky-like behavior, where position:sticky
would not work, then we'd be interested to see it.

Simon

Received on Thursday, 28 June 2012 03:21:05 UTC