On Thu, Jan 9, 2014 at 4:56 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
> On Fri, Jan 10, 2014 at 12:57 PM, Dominic Mazzoni <dmazzoni@google.com>wrote:
>
>> Idea 1: How about if we just get rid of the logic that skips drawing if
>> it's not focused? Then we could have drawFocus that's clear and does
>> exactly what it says, but it wouldn't improve accessibility of controls
>> when they're not focused. We could also have setFocusPath that never draws
>> anything but notifies the system what path is highlighted when an element
>> has focus, to complement it.
>>
>
> Splitting the method is logical but it means we have to say "whenever you
> call this, you should also call that" which is somewhat annoying.
>
> Idea 2: Create a single API called setElementFocusPath that only needs
>> to be called once (if the path doesn't change), and the browser then takes
>> over drawing the focused path around that element ever time that element
>> gets focus, and clearing it when it loses focus. It would have to do that
>> in a separate overlay. This is much closer to what Ryosuke was proposing on
>> webkit-dev.
>>
>
> That can't work. In general the focus has to be drawn at the right time
> during the app's canvas painting, with the canvas in the right state.
> There's no way to insert the focus drawing at the right place after the
> fact.
>
Why not? If we cache the path, we should be able to draw the focus on top
of the canvas.