Re: drawSystemFocusRing implementation details

On Sat, Aug 17, 2013 at 1:33 PM, Charles Pritchard <chuck@jumis.com> wrote:

>  On 8/17/2013 12:52 PM, Rik Cabanier wrote:
>
>
>
>
> On Sat, Aug 17, 2013 at 10:28 AM, Charles Pritchard <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>wrote:
>>
>>> On Aug 16, 2013, at 5:13 PM, Dominic Mazzoni <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.
>

Are you assuming that the canvas resolution matches the screen? If the
rings are drawn on top, they will be in the device resolution.
Otherwise, you'd need a whole other copy of the canvas pixels which is not
acceptable.


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

No, because the browser knows about the elements and their bounding boxes.
There's no magic there.


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

That would work with today's code except that 'onfocus' should call a
function that redraws the canvas using the focus ring APIs.


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

Your proposal sounds reasonable but I think it's not straightforward to
implement.

In addition, it might not make things easier for authors. For instance, if
the canvas move the region that the element represents, the area for the
focus rings needs to be updated too. The code will look very similar with
the current API and your proposal.
It's also confusing that drawCustomFocusRing would not change...