W3C home > Mailing lists > Public > public-html-comments@w3.org > May 2008

Re: [whatwg] scrollIntoView jarring?

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 2 May 2008 11:22:27 -0500
To: David Bolter <david.bolter@utoronto.ca>
Cc: Peter Kasting <pkasting@google.com>, public-html-comments@w3.org, W3C WAI-PFWG <w3c-wai-pf@w3.org>, w3c-wai-pf-request@w3.org, whatwg@whatwg.org
Message-ID: <OFFED3BD35.EE7137CD-ON8625743D.00546ACC-8625743D.0059F314@us.ibm.com>


To be honest, the right solution for this is to have the user agent do it
like tabindex. Since activedescendant is not being adopted until FF 3, IE
8, Safari ?, and Opera ? all existing browser targets for web application
developers should require the use of tabindex. So, why not make it
consistent with how the browsers process tabindex.

Further justification:

activedescendant requires the browser to fire additional focus change
events to the AT. It is intended to reduce the code the author has to
write. ScrollIntoView is not available until HTML 5 as well.

We can all discuss this on Monday's calls.



Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist
Chair, IBM Accessibility Architecture Review  Board
blog: http://www.ibm.com/developerworks/blogs/page/schwer

             David Bolter                                                  
             ronto.ca>                                                  To 
             Sent by:                  Peter Kasting <pkasting@google.com> 
             w3c-wai-pf-reques                                          cc 
             t@w3.org                  whatwg@whatwg.org, W3C WAI-PFWG     
             04/30/2008 03:43                                      Subject 
             PM                        Re: [whatwg] scrollIntoView         

Peter Kasting wrote:
> On Wed, Apr 30, 2008 at 10:58 AM, David Bolter
> <david.bolter@utoronto.ca <mailto:david.bolter@utoronto.ca>> wrote:
>     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)
> I agree that this is a use case which scrollIntoView does not seem to
> solve well.  I am not sure Daniel's proposal for
> ensureElementIsVisible is perfect either, though it is clearly better.
> 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?


Nice. I agree on all points, except maybe if larger than the viewport we
might want to butt an element corner to a viewport corner (perhaps
top-left for left-to-right languages), but I also wonder if that is too
much detail.


(image/gif attachment: graycol.gif)

(image/gif attachment: pic20223.gif)

(image/gif attachment: ecblank.gif)

Received on Friday, 2 May 2008 16:23:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:24 UTC