Re: [css4-ui] Scrollbar tracking control

This proposal is going to make developer's lives easier In trying to make
this sticky behaviour work using JS, there are several disadvantages over a
declarative solution as proposed earlier in this thread.

In particular, we are using declarative transitions to smoothly animate new
content into the bottom of a frame. The new piece of content is added to
the bottom of the existing content at height 0, and smoothly grows to its
final size. In native (mobile) versions of the app, it looks great and
feels slick.

In the browser, trying to use JS to set the scroll position at the same
rate that the transition is happening just never works smoothly.

It's also exposing an asymmetry in the scroll positioning behaviour - if we
were inserting content into the top of the frame (and the user is scrolled
to the top), everything just works. We could also try implementing a custom
scrollbar to invert the scrolling behaviour so the desired 'sticky'
behaviour happens on the bottom instead, but yuck :(

What I like about this proposal is that it moves common behaviour that is
otherwise tricky and cumbersome to implement (not to mention jank prone as
you try to use JS to reset the scroll position at 60Hz to keep up with the
animation) into declarative code. Into the bargain, for power users who
really do desire a different behaviour (hi David! :) ), they are able to
override the CSS - where if the behaviour was implemented in JS that
wouldn't be an option. It's just as useful for desktop browsers as it is
for mobile.

David, Simon - does this address your concerns?

The proposed syntax as I understand it is:

----
overflow-anchor: none | [ [ before | after ] <length>? | [ start | end ]
<length>? ]

before/after: logical direction referring to the "block axis", which is
vertical in English text, but horizontal for "vertical text" like Japanese.
start/end: the corresponding logical directions for the "inline axis",
which is perpendicular to the block axis.
length: a ‘safe zone’ - if you’re at least this close to the edge, then
it’ll be sticky. If this is omitted, then the UA can supply whatever value
it thinks is best.
Initial value: overflow-anchor: before

Note that concepts of ‘x’ and ‘y’, or ‘top’ or ‘left’ are not used - these
presuppose a writing direction, and interact wrongly with eg RTL text.
-----

Are there any problems with this as it stands that people would object to
an experimental implementation?

On 6 December 2012 04:36, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Tue, Dec 4, 2012 at 2:40 PM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Thursday 2012-06-14 17:18 -0700, Tab Atkins Jr. wrote:
> >> On Thu, Jun 14, 2012 at 5:00 PM, L. David Baron <dbaron@dbaron.org>
> wrote:
> >> > I'm worried about a few things here:
> >> >
> >> >  * I wouldn't want this to preclude browsers improving their
> >> >   behavior in other ways (since there are a bunch of improvements
> >> >   that could be made)
> >>
> >> Brief examples?
> >
> >  - preserving the user's position in the content when the user
> >    resizes the page
> >
> >  - preserving the user's state of being at the (bottom/end) edge of
> >    the content when the user resizes the page
> >
> >  - preserving the user's position in the content a non-end position
> >    when content is added
>
> None of these are prevented by my proposal to define a sticky edge,
> actually.
>
> > Stepping back, I think there are a bunch of infinite-scroll UIs
> > being added these days, where new content gets added dynamically.
> >
> > I can think of two big models:
> >
> >  * new content at the top, but ability to scroll to get more old
> >    content at the bottom (twitter, facebook)
> >
> >  * new content at bottom (chat)
> >
> > The interesting thing about the first is that content can be added
> > at both ends.  When I scroll to the bottom in facebook or twitter,
> > it dynamically adds more new content at the bottom (and doesn't
> > scroll when it appears); when I scroll to the top, it dynamically
> > adds new content to the top, and there are use cases both for
> > holding position-in-content and for staying at the edge.
>
> I agree!  There was another thread around the same time as this one
> about dynamic updates, where I think I proposed some way to declare
> that if a container gained/lost elements or some elements changed
> height *outside* of the visible scrolling area, it would auto-adjust
> your scrolling position to keep your apparent position stable.  That
> works fine with this proposal.
>
>
> > I tend to think we need a concept of a container for
> > infinite-scrolling content in which the browser knows that it ought
> > to pay attention to either
> >
> >   (a) position preservation of the content present both before and
> >   after a dynamic update, across that update, or
> >
> >   (b) preservation of a position at the edge of the content
> >
> > regardless of whether content is being added or removed from one
> > edge or the other.
>
> For (b), you still have to bias it towards one edge, so that the user
> experience is nice when the elements transitions from "not scrolling"
> to "scrolling" as you fill it with content.
>
>
> >> >  * As a user, I hate this behavior.  I generally want to know where
> >> >   I left off, and I hate it when sites think I want the latest and
> >> >   don't care where I last stopped reading.  So I'm personally much
> >> >   more interested in having the position be maintained.
> >>
> >> I suspect this isn't actually your position in chat rooms. ^_^
> >> Otherwise you'd have to constantly hit pagedown just to keep up with
> >> the conversation.  But even if it is, pushing this functionality into
> >
> > It actually is my position in chat-rooms; if I want to catch up, I
> > want to read forwards rather than backwards rather than search for
> > my previous read-to point; if I don't, I can get to the end easily.
>
> Huh, ok.  I'll have to trust you on this, but your preference seems
> extremely weird and uncommon to me.  This isn't really about catching
> up, it's about having to *constantly* press PgDn to see new content
> every few seconds in a conversation (in fact, even your own messages
> won't be initially visible).
>
>