RE: [css4-ui] Scrollbar tracking control

I'm also interested in hearing about the challenges GMail has encountered in this scenario.  I don't disagree that a concise way to specify this behavior would be nice to have, but just want to make sure any new designs are accounting for the scenario properly.  Shouldn't this just require something like this for a basic scenario?
document.querySelector(".chat-window:last-child").scrollIntoView()

Regarding feedback that came up on the call today -- I agree this does draw some heavy parallels to scroll snap points, where "maintain a scroll offset that aligns the snap point against the viewport" sounds a lot like "maintain a scroll offset that aligns the bottom of the content against the viewport".  I don't think it's necessarily duplicate functionality though (yet, at least), since scroll snap points are intended to affect both user-initiated scrolling as well as non-user-initiated scrolling (script, relayout, etc.) whereas this feature seems to only want to affect non-user-initiated scrolling.  I do think that we should attempt to ensure scroll snap points and this feature should handle non-user-initiated scrolling in similar fashions.

My other feedback on the call was that this feature also draws parallels to the problem of keeping content in view while resizing responsive web pages.  E.g. open up any W3C spec, scroll to the middle, resize the window until text re-wraps -- now you've lost your place.  I'd be interested in seeing if this feature could be generalized to solve the broader scenario of preferring to keep particular content in view as the page layout changes.  I think this is also important for solving the Twitter scenario mentioned on the call, where the desire is to keep currently-visible tweets in-view despite content being added both above and below the current scroll offset.

Thanks,
-Matt

> From: aelias@google.com [mailto:aelias@google.com] On Behalf Of Alexandre Elias
> Sent: Tuesday, April 15, 2014 5:31 PM
> To: Tab Atkins Jr.
> Cc: Simon Fraser; Mike Lawther; L. David Baron; www-style list
> Subject: Re: [css4-ui] Scrollbar tracking control
> 
> I would be interested in hearing the details of what GMail is running into when trying to do this in Javascript: I assume there is some kind of async behavior causing problems.  I wonder if we could instead solve those underlying problems: fixing it at that level may be useful to allow a variety of other resize-linked behaviors.
> 
> In principle, if an event is sent synchronously after resize and Javascript changes the scroll position before it returns, that could behave the same way as your proposal.  We shouldn't run into any of the usual difficulties with off-main-thread scrolling in this area (at least in Chromium/Blink, and hopefully other browsers), it's just a matter of making things happen in the right order on the main thread.
> 
> 
> 
> On Tue, Apr 15, 2014 at 12:20 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Tue, Apr 15, 2014 at 11:52 AM, Simon Fraser <smfr@me.com> wrote:
> > I’m finding it hard to understand, from Mike’s original email, what the intent is here.
> > Is it to preserve the user’s scroll position as content is being added dynamically to the document?
> >
> > This is certainly a request we’ve heard from people like Facebook, but I’m not sure it’s solvable in CSS.
> No, not full tracking.  (Though I came up with suggestions for that in
> the past.)
> 
> It's just about "sticking" the scrollbar to a particular edge when
> it's close enough to that edge, even as content is added.  That is, if
> the scroll position is within X distance of the indicated sticky edge,
> any adjustments to the scroll width/height of the element maintain
> your relative distance to the edge.
> 
> It's mainly for the common case of chat windows and other log-type
> things (consoles, etc.) that add content at the bottom.  It's
> *remarkably* difficult to make a robust chat window that properly
> sticks the scrollbar to the bottom of the window - I get regular
> complaints from the people implementing Gmail chat windows about this.
> 
> ~TJ

Received on Wednesday, 16 April 2014 20:48:49 UTC