Re: Sticky Positioning

On Jul 1, 2012, at 1:41 PM, Simon Fraser <smfr@me.com> wrote:

> On Jul 1, 2012, at 12:06 pm, Maciej Stachowiak <mjs@apple.com> wrote:
> 
>> 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.
> 
> I don't think you always want that. Imagine a scrolling box that wants sticky headers (e.g. something like the right sidebar on http://io9.com, but not fixed-position, and with the "latest stories" header being sticky). I think, most often, you want that sticky header inside the overflow:scroll to not be sticky to the viewport bounds, but to scroll out of view with its containing overflow element as you scroll the page.

If I follow your example correctly, you are right that my proposal would cause more stickiness than is desired. You could address that either with Brad's proposal of [intersection of containing block and closest ancestor with overflow: scroll] or else add an additional property to explicitly state which boxes define the constraint bounds.

Are there any cases where you really do want to stick to the viewport rather than the closest scrolling ancestor?

Defaulting to viewport and defaulting to scroll container are also both compatible with later adding an additional property to explicitly define constraint boxes.

Regards,
Maciej

Received on Sunday, 1 July 2012 20:53:56 UTC