Re: Sticky Positioning

Slightly off-topic, but is there room in Media Queries for viewport scroll
position?

In practice…
h2 {
    position: static;
}
@media (scroll-top: 10px) {
    h2 {
        position: fixed;
        top: 0;
    }
}

On Wed, Jul 11, 2012 at 2:58 PM, Ojan Vafai <ojan@chromium.org> wrote:

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