[whatwg] scrollIntoView jarring?

Wed Apr 30 15:42:22 PDT 2008

On Wed, Apr 30, 2008 at 2:21 PM, L. David Baron <dbaron at dbaron.org> wrote:
> 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:
>

The function can become considerably difficult with nested, scrolled containers.

>   * 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)?
>

There are three cases:
1) want to make sure the element is within viewable area
 a) partially
 b) completely
2) want to make sure element is is completely viewable
 a) at top of screen
 b) with least amount of scrolling

I have never been asked to scroll an element so that it is in the
middle of the screen. If the element were larger than the screen, that
would seem to be a bad U/X.

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

Browsers nested, scrolled elements inconsistently with each other.

Having scrollIntoView([top]) will scroll a nested element into view.
It seems to have the effect of passing [top] up the tree, recursively.

<!doctype html>
<html>

<head>
<title>scrollIntoView</title>
</head>
<body style="height:1000px;background: red;">
<div style='height: 100px; overflow: scroll;background:yellow'>

<p style='font-size: 20px; height: 1100px;background: pink'>
blah blah balh
blah blah balh
blah blah balh
blah blah balh
blah blah balh
</p>
<div id='a'>yea</div>

</div>
<script>
var a = document.getElementById("a");
</script>
<button onclick='a.scrollIntoView(false)'>scrollIntoView(false)</button>
<button onclick='a.scrollIntoView(true)'>scrollIntoView(true)</button>
</body>
</html>

Firefox seems to have an internal check for isElementInView, because
calling scrollIntoView(false) after scrollIntoView(true) does nothing.
e.g. "scroll only if it's not visible at all"

This is probably due to the common problem I see:
1) IE has a sort-of useful property that works as desired in some
cases (main path-OK)
2) Mozilla copies it in a little different way (alternate path different)

This is a process issue. It is not confined to scrollIntoView. There
should be a test case for  [insert_feature_here], to demonstrate the
current behavior + any new desired behavior.

SOmeone could even faux-implement it by writing
HTMLElement.prototype.ensureElementIsViewable = function([whatever]) {
};

(ensureElementIsVisible is not a good name because 'visible' means
something specifically different in the context of dynamic browser
scripting.)

Other things like scroll speed would seem to be enhancements that
could be considered later.

-G

>
>  -David