[whatwg] scrollIntoView feedback

[Ian Hickson]

(The e-mails included in this reply were all cc'ed to whatwg, but some 
were also cc'ed to other mailing lists. To reduce cross-posting, I've only 
included whatwg at whatwg.org on this reply, since that was the only list 
that was included on all the e-mails. If you reply, feel free to respond 
on any mailing list, but please avoid cross-posting, and include me on 
the cc list if it's not the whatwg or public-html lists. Thanks!)

On Wed, 30 Apr 2008, David Bolter wrote:
>
> I have a concern about "3.5.3 Scrolling elements into view": 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/section-interaction.html#scrollintoview
> 
> In addition to concerns expressed by Brad Fults 
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-October/012655.html), 
> I want to raise a concern about the behaviour of scrollIntoView. 
> Specifically I would ask that:
> 
> 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)
> 
> My concern is that with the movement towards rich interactive web 
> interfaces, we are going to be seeing complex widgets that will need to 
> call such functions fairly often, which may lead to a jarring experience 
> if the function always butts the element to the edge of the viewport. It 
> would be a shame to jar users when unnecessary. I realize there is a 
> (hairy) way to do this but it would be nice to have the convenience.

As the spec is currently written, user agents are allowed to experiment 
with different ways to scroll the content into view. I'll happily change 
the spec to be more in line with what browsers do, if they change.


> Aside: we would like to recommend authors call such a method when using 
> ARIA's activedescendant (draft spec).

Wouldn't that be more appropriate in the ARIA spec?


On Wed, 30 Apr 2008, Peter Kasting wrote:
> 
> I make no formal proposal, but the behavior I would typically want for 
> some kind of a call (perhaps in addition to those above, I don't know) 
> would be:
> 
>    - If the element in question cannot be scrolled so as to make more of it
>    appear in the viewport, do nothing.  (For when the element is completely
>    visible, or is larger than the viewport and already taking up the whole
>    viewport).
>
>    - Otherwise, if the element is not larger than the viewport, scroll such
>    that the element is centered* in the viewport (within the scrolling limits
>    -- if the element is at the bottom of the page, it clearly can't be scrolled
>    up to the middle of the viewport).
>
>    - Otherwise, scroll the element such that the top of the element is
>    aligned with the top of the viewport.
> 
> *Perhaps centered is the wrong choice.  Another suggestion would be to 
> scroll to a point 1/3 of the way from the top or bottom of the viewport, 
> nearer to whichever edge the element scrolled in from.  Also, perhaps 
> the UA's behavior should not be specified in this kind of detail?

As far as I can tell, as defined, browsers would be allowed to do all this 
for scrollIntoView().


On Fri, 2 May 2008, David Bolter wrote:
> 
> I'm not sure of the intended use cases of scrollIntoView, so for now I 
> still agree with Brad Fults, that horizontal scrolling shouldn't be 
> forgotten here. And if we want scollIntoView to butt the element to the 
> edge no matter what, that's fine, but we shouldn't expect that to be 
> received as the ideal/desired behavior by all. Couldn't we make it 
> optional?

It is effectively optional now. Horizontal scrolling is also required.


On Wed, 30 Apr 2008, L. David Baron wrote:
>
> 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.)

I agree with the above.


On Wed, 30 Apr 2008, Jonas Sicking wrote:
> 
> Another question is if the scrolling should be instant, or if smooth 
> scrolling is allowed/desired.

The spec allows both.


On Wed, 30 Apr 2008, Garrett Smith wrote:
> 
> 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

But what are the cases that each of these is used for?


On Fri, 2 May 2008, Aaron Leventhal wrote:
>
> I think if there is an attribute like this which also scrolls for you, 
> then it should be called activedescendant, not aria-activedescendant. I 
> don't see a problem if HTML 5 wants the attribute without aria- to drive 
> browser behavior. In that case perhaps it should style the active 
> descendant to it is active somehow.
> 
> In general it's easier to explain ARIA if there are some consistent 
> principles, such as, it doesn't drive browser behavior. It just allows 
> the JS developer to report what they did. And since the widgets also 
> need to work in older browsers that don't support ARIA, it's better if 
> the aria- attributes maintain that rule.
> 
> Otherwise, without that rule, it really is a slippery slope. First we 
> have aria-activedescendant scroll for you, so why not show it is active 
> for you? Why shouldn't aria-disabled actually make the item disabled? 
> Etc. etc. Pretty soon we're implementing the widgets for the author and 
> none of it works most browsers.

Agreed.


On Tue, 3 Jun 2008, Kristof Zelechovski wrote:
>
> Nothing in the document can be further down than the bottom.  If the 
> document scrolls past the bottom, it shows nothing under the bottom but 
> the bottom is in the middle of the window.  This is inevitable if the 
> document is short so that it can be displayed without scrolling (and 
> without scroll bars); it should be avoided if the document is longer 
> than the window's height.

On Thu, 5 Jun 2008, Bonner, Matt (IPG) wrote:
> 
> I'm wondering if he was thinking about cases where the element is 
> shorter vertically than the viewport?  It might be worth clarifying what 
> happens in that case.  I assume the answer is "nothing"?

On Fri, 6 Jun 2008, Kristof Zelechovski wrote:
>
> If the part of the document following the bookmark is too short for the 
> containing view port, revealing the bookmark should be equivalent to 
> scrolling to the end of the containing page.

On Fri, 6 Jun 2008, Bonner, Matt (IPG) wrote:
> 
> Right, good point. 3.5.3 currently doesn't differentiate between 
> partial-page content following a bookmark, and whole-page content. It 
> appears that it needs to do so.
> 
> I was thinking of the case where the whole document is shorter than the 
> viewport. It would seem worth spelling out the behavior for both 
> vertical cases. And then consider a bit more detail for the horizontal 
> case as well.

Fixed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'