Re: [whatwg] Outline style to use for drawSystemFocusRing

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?


> > 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.

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.


> > 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:17:29 UTC