Re: Sticky Positioning

Just to close the loop here, I'm fine with sticky as proposed despite my
earlier concerns. I think sticky meets the majority use-case simply and
will map to a subset of the more complicated proposal.


On Sun, Jul 1, 2012 at 1:53 PM, Maciej Stachowiak <mjs@apple.com> wrote:

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