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.
>
Yes, it is annoying but less confusing.
Well, maybe we just need to make sure that people are educated about the
method and keep them together.
Let's keep 'drawFocusIfNeeded' and make it the same as 'drawSystemFocusRing'
> 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.
>
> Rob
> --
> Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
> stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr,
> 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp
> waanndt wyeonut thoo mken.o w
>