- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 16 Dec 2013 20:29:31 -0800
- To: "whatwg@whatwg.org" <whatwg@whatwg.org>
1. scrolling to the focused element >From a previous exchange: On Wed, 2 Oct 2013, Rik Cabanier wrote: > > I don't understand. If the path that is active during > drawCustom/SystemFocusRing is off screen and the element is focused, the > browser will scroll to that area. drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything to scroll. That would be very confusing, IMHO. (When would you scroll? Consider the case of the control originally being off-screen on purpose, and animating into position. You want the focus ring drawn the whole time, and the zoom to follow it maybe, but you only want to scroll once, at the start, to the location that it will have at the end.) We want to scroll if the element is focused and the area that is described by the current path is offscreen. This should follow CSSOM View's definition of scrolling [1]. Not having this feels weird since you will see scrolling if you tab to html element, but not the html element that are used as fallback content. Firefox's implementation already does this. 2. Change when the user is informed of the location With the current definition [2], if the element is not focused, the algorithm immediately returns. It would be very helpful if it always ran step 3 first. Step 3 doesn't inform the a11y software of focus action; instead it tells the a11y software of the area of the fallback content. [3] This is very useful since this allows hit testing. I was told that Chrome's implementation already does this and I have a patch to enable this in Firefox too. 1: http://dev.w3.org/csswg/cssom-view/#scrolling 2: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring 3: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#inform
Received on Tuesday, 17 December 2013 04:29:58 UTC