W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-snappoints] Various issues

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 13 Dec 2013 10:06:52 -0800
Message-ID: <CAAWBYDDDXmzicnpnVjvme=SfxiAxwYwbhq82F78+H3Q+FUJGvA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: www-style <www-style@w3.org>, Miranda Emery <miranda.j.emery@gmail.com>
On Fri, Dec 13, 2013 at 2:55 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Following up with more data and a fairly drastic revision to the
> scroll-snap-edges proposal.
> Now that Miranda's implemented a basic prototype of our proposal, we
> immediately realized that it doesn't make sense to simply snap the scroll
> position to the top/left/right edge of some element. For example, when
> scrolling down, you're not interested in aligning the top edge of some
> element with the top of the container. Instead you want the bottom edge of
> some element aligned with the bottom edge of the container because you want
> to see whole elements at the bottom of the container, even if it means you
> have to show partial elements at the top.
> So I've revised https://wiki.mozilla.org/Gecko:CSSScrollSnapping to make
> scroll-snap-edges take "none", "border-box" and "margin-box" values. When
> scrolling down you snap the bottom edge of the specified box to the bottom
> edge of the container, and analogously for the other directions. This makes
> RTL a non-issue. It does however mean that scroll-snap-type:mandatory can't
> be strict apart from scroll gestures, because in a lot of cases (e.g.
> DOM/style changes) we don't know what direction to use for snapping.

This sounds pretty good, and I like that it eliminates the naming
issues, since I was unhappy about them too.

Received on Friday, 13 December 2013 18:07:39 UTC

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