[whatwg] scrollIntoView jarring?

On Wednesday 2008-04-30 13:58 -0400, David Bolter wrote:
> 1. scrollIntoView not do anything in the case that the element is already 
> fully visible (possibly in the middle of the viewport), or
> 2. ensureElementIsVisible to be added as described by Daniel Glazman 
> (http://lists.w3.org/Archives/Public/public-html/2007Nov/0188.html)

It seems like authors might actually want different options here for
different uses.  Aligning things with an edge of the viewport, or
with the edge of some other scrollable container, might be useful in
some cases, and just ensuring that it is visible might be useful in
others.

Mozilla has an internal function used to implement a number of
different scrolling APIs (including scrolling to named anchors) that
has a bunch of options:
 * scroll into view (no matter where)
 * scroll to align with a particular edge of the page
 * scroll only if it's not visible at all

I think in many cases these scrolling APIs are about making things
that authors can already do (using scrollTop, offsetTop,
offsetHeight, offsetParent, and similar properties) easier to do.
So I think the main questions to consider for these APIs are:

 * what capabilities do they provide that can't already be done?

 * what are the common uses of the existing features for scrolling
   things into view (perhaps adjusted by how hard it is to do the
   different possibilities)?

(It's also worth thinking about how all of these deal with nested
scrollable containers, and about how they deal with the interaction
of vertical and horizontal scrolling.  The existing text in
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrolling
doesn't seem to account for either.  But browsers actually do need
to handle these, and the spec should describe how.)

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Wednesday, 30 April 2008 14:21:39 UTC