Re: Sticky Positioning

* 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.

>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.

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). As far as I can tell, your proposal does not account for that,
and it is unclear to me that this is relatively uncommon.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Thursday, 28 June 2012 01:45:29 UTC