Re: drawSystemFocusRing implementation details

On 8/17/2013 2:14 PM, Rik Cabanier wrote:
> On Sat, Aug 17, 2013 at 1:33 PM, Charles Pritchard <chuck@jumis.com 
> <mailto: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 <mailto:chuck@jumis.com>> wrote:
>>
>>         On 8/16/2013 8:28 PM, Rik Cabanier 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 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.

Admittedly, I've not considered the effects of CSS transforms. Nor have 
I been active in webkit internal-code for some time.
I do not think that the resolution of the focus ring is something that 
needs to be in the spec; I see that as an implementation detail.

It's certainly a consideration implementers should be aware of, e.g.  
<canvas style="transform: scale(2,2); or... width: 100%;">

I don't think that "drawing" a focus ring onto a canvas element without 
polluting the scratch bitmap is a technical impossibility, but I can't 
speak with certainty.


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

In this case, the browser knows about the element and its bounding box 
because that information has been exposed at the time 
drawSystemFocusRing was called.
It knows both the prior element's bounding box and the current element.


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

Yes, which I'm trying to avoid.


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

That's something that we can investigate.

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

I don't follow your example... Are you talking about a CSS mutation, 
e.g. <canvas style="top: ...">  or the author changing the position of 
the element; e.g.  (function(ctx) { moveAndDrawElement(); 
ctx.drawSystemFocusRing(element); }); ?

In the case of the author repainting the screen, no, this proposal 
doesn't save much time or effort. This proposal targets the wide case of 
Canvas uses which are not very dynamic, in order to reduce author 
managed repaints.
I've not addressed drawCustomFocusRing; you make a good point, I think 
that it should change as well, if we do define this behavior.

If I could summarize this conversation:

I've proposed that drawSystemFocusRing be implemented in a manner where 
the Canvas bitmap is not altered and the focus ring disappears on blur 
of the underlying element.
Rik and Dominic understand that proposal; Dominic is not convinced it's 
needed, Rik has concerns about the difficulty of implementation as well 
as other concerns about author use and confusion.

And my position:

My concern is based on quickest/easiest route to delivering patches to 
existing Canvas applications. I recognize that implementation may not be 
feasible/desirable. I also recognize that many of these Canvas apps were 
not designed with these interfaces in mind, whereas Canvas Layer 2 apps 
would be more amenable to scene graphs, and partial redraws based on 
updated regions.

-Charles