Re: [css4-ui] Scrollbar tracking control

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

Received on Wednesday, 5 December 2012 17:36:57 UTC