Re: [css4-ui] Scrollbar tracking control

On Thursday 2012-06-14 17:18 -0700, Tab Atkins Jr. wrote:
> On Thu, Jun 14, 2012 at 5:00 PM, L. David Baron <> 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

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

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

> CSS makes it easy enough to put a "scrollbar-attachment: normal
> !important;" rule into your user stylesheet.  Much easier than trying
> to deal with each page's JS.
> >   So it
> >   seems like there are two separate pieces of information here: (1)
> >   which end the site is adding content from and (2) whether the
> >   site things you want scroll-to-latest-if-at-edge.  If they're
> >   separate, then it's easier for the user to override (2).
> I'm not sure how (1) would be useful as a separate piece of information.

I suppose it's not useful as a separate piece of information if we
can distinguish the concept of a dynamic change involving content
addition or removal in a scrollable region.


𝄞   L. David Baron                  𝄂
𝄢   Mozilla                    𝄂

Received on Tuesday, 4 December 2012 22:41:23 UTC