- 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>
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 David Bolter <david.bolter@uto ronto.ca> To Sent by: Peter Kasting <pkasting@google.com> w3c-wai-pf-reques cc t@w3.org whatwg@whatwg.org, W3C WAI-PFWG <w3c-wai-pf@w3.org>, public-html-comments@w3.org 04/30/2008 03:43 Subject PM 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
Attachments
- 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