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

[David Bolter]

Replying to myself below...

David Bolter wrote:
>
> 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...

I just chatted with Aaron over IRC.

I think active-descendant probably shouldn't drive behavior in this way.

Here's why: I'm thinking of the common use case for active-descendant 
today... and aria active-descendant, rightly or wrongly, is often going 
to be added after the DHTML widget behavior has already been 
implemented. This behavior would already, presumably, make sure that the 
thing(s) we want to attach active-descendant to are in the viewport. If 
adding aria active-descendant performs, via the browser, a redundant, 
and perhaps even slightly different scroll, that would be bad IMO. In 
fact, it could be very frustrating to authors.

Yeah let's chat about it.

cheers,
D
>
> 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 at utoronto.ca>David Bolter <david.bolter at utoronto.ca>
>>
>>
>>                         *David Bolter <david.bolter at utoronto.ca>*
>>                         Sent by: w3c-wai-pf-request at w3.org
>>
>>                         04/30/2008 03:43 PM
>>
>>     
>>
>> To
>>     
>> Peter Kasting <pkasting at google.com>
>>
>> cc
>>     
>> whatwg at whatwg.org, W3C WAI-PFWG <w3c-wai-pf at w3.org>, 
>> public-html-comments at w3.org
>>
>> Subject
>>     
>> Re: [whatwg] scrollIntoView jarring?
>>
>>     
>>
>>
>>
>> Peter Kasting wrote:
>> > On Wed, Apr 30, 2008 at 10:58 AM, David Bolter
>> > <david.bolter at utoronto.ca <mailto:david.bolter at 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
>>
>>
>
>