[whatwg] 2 requests for drawSystemFocusRing

[Rik Cabanier]

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