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

Re: Sticky Positioning

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 01 Jul 2012 12:06:55 -0700
Cc: Brad Kemper <brad.kemper@gmail.com>, Edward O'Connor <eoconnor@apple.com>, "www-style@w3.org" <www-style@w3.org>
Message-id: <BF6DADF9-ABD4-44A5-AFB6-78622372D7DA@apple.com>
To: Simon Fraser <smfr@me.com>

On Jun 28, 2012, at 11:16 AM, Simon Fraser <smfr@me.com> wrote:

> On Jun 28, 2012, at 10:37 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> I think this would be great. But I don't think the tbrl keywords should be only be relative to the viewport, but rather to the nearest potentially scrollable ancestor (overflow: auto | scroll). In many designs that might be the main scrollable content area with the viewport itself not scrolling at all.
> We've had others suggest this too.
> A complication is that an ancestor may only be scrollable in one direction (overflow-y: scroll), so you may want to sticky-position on the Y axis relative to your overflow:scroll ancestor, and sticky-position on the X axis relative to the viewport. That's slightly crazy.
>> I'm not sure what you mean by the containing box's edge, especially if you are talking about only the viewport being the measure of what the 'top: 10px' is relative to. Wouldn't it stop at the edge of the same box, ie the viewport?
> The sticky element is positioned inside a box that is the intersection of the viewport (inset by the top/right/bottom/left values), and the containing block (inset by the sticky element's margins).
> So the sticky element never escapes its containing block.

A possible alternate rule that would address Brad's case without being *too* much more complicated:

"The sticky element is positioned inside a box that consists of the containing block as clipped by all ancestor overflow rules."

This would handle the case of a scrollable area that is not the viewport and would give a clear way of handling the "scrollable in only one direction" problem. Note: I don't know if this would cause significant implementation difficulties.

Received on Sunday, 1 July 2012 19:07:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:18 UTC