Re: drawSystemFocusRing implementation details

On 8/17/2013 12:52 PM, Rik Cabanier wrote:
>
>
>
> On Sat, Aug 17, 2013 at 10:28 AM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>     On 8/16/2013 8:28 PM, Rik Cabanier wrote:
>>
>>     On Fri, Aug 16, 2013 at 6:33 PM, Charles Pritchard
>>     <chuck@jumis.com <mailto:chuck@jumis.com>> wrote:
>>
>>         On Aug 16, 2013, at 5:13 PM, Dominic Mazzoni
>>         <dmazzoni@google.com <mailto:dmazzoni@google.com>> wrote:
>>
>>         >
>>         > It sounds like what you want is for the focus ring to be
>>         drawn on the page, on top of the canvas (rather than into the
>>         canvas bitmap) - and you want it to disappear when the
>>         element loses focus, whether the canvas is redrawn or not.
>>         >
>>         > I'm not convinced that's better than the current spec - but
>>         I think that'd be the right way to word what you're asking for.
>>
>>
>>         Thanks, yes, that's the behavior I'd like to see implemented.
>>
>>
>>     I'm unsure how this could possibly work.
>>     Wouldn't you have to redraw the focus ring on every frame in this
>>     scenario?
>>
>
>     Are you asking about implementation or consumption of the API?
>

With Blink, it sounds like you might make a copy of the Canvas state 
when drawSystemFocusRing was called and redraw the path during repaints 
as a final step.

I haven't looked at the inner details of Blink to see how it handles 
drawing focus rings for complex scenes like:
<svg style="position: absolute"><path tabindex></svg><video />

Another example might be usemap over an image, though I haven't touched 
image maps in many years.

Dominic, is there a practical, technical issue in implementation that 
would block this?


>     For consumption, the focus ring would show until the element is
>     blurred or the canvas is reset (via height/width setters).
>
>
> I think this is relying on magic. 'drawFocusRing(element)' just draw 
> the current path using the focus style if 'element' has the focus.
> It would be strange if there's some code that would automatically 
> remove the focus ring.

The browser only draws one focus ring on any given page at a time; isn't 
that magic already fairly well-established?
Additionally, the concept of "focus" is also managed by the browser. 
This is handled by all other HTML elements.

My expectation of "set" or "draw" system focus ring was to take:

<div tabindex style="position: absolute" /><canvas />

And turn it into:
<canvas><div tabindex onfocus="path(); ctx.drawSystemFocusRing(e);" 
/></canvas>

> What you want sounds more like an API where you can register areas 
> with corresponding elements and have the browser handle the refresh.

Binding DOM elements to paths is the realm of addHitRegion.

All of these questions being brought up about implementation are items 
that authors would have to [independently] pursue when supporting 
drawCustomFocusRing.
That's why I'm exploring this. Very few authors would want to go beyond 
a simple, managed drawSystemFocusRing.

I don't understand the concern that we'd be "relying on magic".

I'd like it to be that with drawSystemFocusRing, we're guaranteed that 
if there is a focus ring visible, things are working.
That's opposed to drawCustomFocusRing, where we could easily make 
mistakes in our scripts and visually have things looking like multiple 
elements are in focus.

-Charles