- From: Brian Blakely <anewpage.media@gmail.com>
- Date: Fri, 13 Jul 2012 14:00:38 -0400
- To: "www-style@w3.org" <www-style@w3.org>
- Cc: Maciej Stachowiak <mjs@apple.com>, Simon Fraser <smfr@me.com>, Brad Kemper <brad.kemper@gmail.com>, "Edward O'Connor" <eoconnor@apple.com>, Ojan Vafai <ojan@chromium.org>
- Message-ID: <CAJGQg4HOUyO=8P-xt++caVCZx6HqZKdyWLswKm0v208xEAep0Q@mail.gmail.com>
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 >> >> >> >> >
Received on Friday, 13 July 2012 18:01:27 UTC