I agree. We need these together. It makes it easier on developers.
Rich Schwerdtfeger
From: Rik Cabanier <cabanier@gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Dominic Mazzoni <dmazzoni@google.com>, Jatinder Mann
<jmann@microsoft.com>, Richard Schwerdtfeger/Austin/IBM@IBMUS,
"Rik Cabanier (cabanier@adobe.com)" <cabanier@adobe.com>, Jay
Munro <jaymunro@microsoft.com>, "Philippe Le Hegaret
(plh@w3.org)" <plh@w3.org>, Canvas <public-canvas-api@w3.org>,
Alexander Surkov <surkov.alexander@gmail.com>
Date: 01/09/2014 07:09 PM
Subject: Re: drawSystemFocusRing and drawCustomFocusRing names are
confusing.
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.
