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