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

activedescendant in viewport (Re: [whatwg] scrollIntoView jarring?)

From: David Bolter <david.bolter@utoronto.ca>
Date: Fri, 02 May 2008 13:23:02 -0400
Message-ID: <481B4DF6.30001@utoronto.ca>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
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

Hi Rich,

activedescendant:
Great. If it will work for us, I feel better relying on the user agent 
for bringing active descendants into view. I thought we were going to 
require the DHTML author to perform a scroll of some kind?  If not, 
great, and I agree it would appear to be a akin to tabindex. We should 
definitely discuss one Monday or ping Aaron and others...

scrollIntoView:
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?

cheers,
D


Richard Schwerdtfeger wrote:
>
> David,
>
> 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.
>
> Thoughts?
>
> Rich
>
>
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> Chair, IBM Accessibility Architecture Review Board
> blog: http://www.ibm.com/developerworks/blogs/page/schwer
> Inactive hide details for David Bolter <david.bolter@utoronto.ca>David 
> Bolter <david.bolter@utoronto.ca>
>
>
>                         *David Bolter <david.bolter@utoronto.ca>*
>                         Sent by: w3c-wai-pf-request@w3.org
>
>                         04/30/2008 03:43 PM
>
> 	
>
> To
> 	
> Peter Kasting <pkasting@google.com>
>
> cc
> 	
> whatwg@whatwg.org, W3C WAI-PFWG <w3c-wai-pf@w3.org>, 
> public-html-comments@w3.org
>
> Subject
> 	
> Re: [whatwg] scrollIntoView jarring?
>
> 	
>
>
>
> 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?
>
> Peter,
>
> 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.
>
> cheers,
> David
>
>
Received on Friday, 2 May 2008 17:23:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:13:58 GMT