Re: [whatwg] Outline style to use for drawSystemFocusRing

On Mon, Jan 6, 2014 at 9:16 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 6 Jan 2014, Rik Cabanier wrote:
> > On Mon, Jan 6, 2014 at 8:41 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > On Mon, 6 Jan 2014, Rik Cabanier wrote:
> > > >
> > > > I think you misunderstood. The drawCustomFocusRing() and
> > > > drawSystemFocusRing() don't cause scrolling, it's when you focus the
> > > > fallback element that the browser should scroll.
> > >
> > > Doing this would imply remembering where the control was the last time
> > > the focusing ring was rendered,
> >
> > Yes, the browser backend remembers the update region of the fallback
> > content. Otherwise, screen readers would not be able to access it.
>
> Why would screen readers need to access it?


I'm not an expert on the subject, but the way Dominic implemented this,
once you call drawSystemFocusRing, you can hover over a region and the a11y
software will know the fallback element (and its aria rules).

(For my own debugging purposes, once the regions are known, you can use
firefox's web inspector and see the focus areas when you hover over the
fallback content. This information is likely available to web authors as
well which could be nice to have.)


> > > which would cause all kinds of problems for authors. Since the last
> > > time the control was rendered, maybe the rendering stopped showing the
> > > control, or maybe when it was last rendered, the control was rendered
> > > just off-screen on purpose so that it could be animated onto the
> > > center of the screen when focused... we simply can't know what the
> > > author is doing.
> >
> > I'm not sure I understand the problem. If the author moves the control
> > somewhere else on the canvas, he's supposed to call drawFocusRing again
> > which will update the region.
>
> If the control is anywhere on the canvas. It might not be. If it isn't on
> the canvas anymore, what you propose would randomly scroll to where it was
> last seen.
>

That would only happen if the author didn't call drawFocusRing again (which
he is supposed to do to update the region of the fallback content)


> But even if the control _is_ on the canvas, that's no guarantee that the
> location it's at is where the author wants to scroll to, as described in
> the examples above. There are (as described above) simple legitimate cases
> where scrolling to the focus position when the control is first focused is
> unambiguously the _wrong_ thing to do. A more elaborate one which I've
> described before would be where all the controls are initially just
> off-screen, visible just on the edge, but when focused, the control moves
> to the center of the screen. No scrolling should ever happen, because the
> author's script is taking care of making the controls visible. But all the
> controls, when initially focused, would have their focus ring first drawn
> on the edge of the canvas, and if we scrolled there, it would be very
> jarring and would be terrible UI.
>
> Forcing such behaviour on the author is bad API design.
>

But once again, it would be consistent. If you were to do this in HTML, the
window would scroll to the initial location of the control.
I'm unsure what happens when you manually move a focused element offscreen.
Is the browser supposed to scroll so it stays visible? If so, maybe
drawSystemFocusRing should scroll as well.

If an author didn't want this behavior, he could locate the controls
off-canvas which would disable the focus ring (or not draw the control at
all and not call drawSystemFocusRing). Then when the fallback content gets
the focus, he can animate the control in place and call scrollPathIntoView
once the animation is done.


> > > This is why there's a separate dedicated API for scrolling. If the
> > > author thinks that the user will want to scroll to the control when
> > > the control is focused, then it's trivial to do. But we should not
> > > force this behaviour. That's terrible API design.
> >
> > Every other control in HTML that gets the focus will cause scrolling.
>
> Sure. Every other control in HTML also has built-in focus ring rendering,
> built-in control rendering, built-in hit testing, etc. But we're not
> talking about built-in controls, we're talking about <canvas>, where the
> whole point is that the author is building the control from scratch.
>
>
> > It's terrible design that this would act differently.
>
> It would certainly be bad UI, sure. But we're not designing the UI here.
> We're designing the API with which the author is going to implement the UI
> that _they_ have designed.

> Drawing a ring but not scrolling feels very unnatural.
>
> I agree, but it's not our place to make this call for the author.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Tuesday, 7 January 2014 05:37:03 UTC