[Bug 11239] Canvas support accessible caret tracking independent of Focus Ring tracking

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11239

--- Comment #51 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-10 22:30:16 UTC ---
> If you review my change proposal you will see that I allowed a focused element
> or a descendant of it to pass drawing the focus ring. The chairs did not
> exclude this from the decision. 

You really didn't. You might think you did, but that isn't what the diff's
normative text said, and it's not what the "details" section of the CP said.


> OK. So, I discussed that with Maciej and we agreed that overloading something
> that drew a caret and selection position was a problem for authors.

setCaretSelectionPos() doesn't draw a caret. All it does, in both your text and
mine, is move the magnifier.


> The second
> problem with this is that you were limiting the drawing of the focus rings to a
> rectangle was wrong. This was a comment that you and Josh Graham both told me
> would be a problem and that we should use a drawing path. The author might want
> a circle for all we know.

I have no idea what you're referring to here. No version of drawFocusRing() has
ever been limited to rectangles.


> Please see my point above. We are actually in violent agreement. The only
> difference is that we need to do this with a function that does not limit the
> drawing to a rectangle.

There is nothing limiting anything to a rectangle except the function that
moves the magnifier (which is a rectangle purely because that's what
accessibility tools _do_, there's not much point trying to magnify a circle or
whatnot if the magnifiers don't do that).


> But, that is not accurate. The author could say canDrawCustom, the function
> returns without drawing the focus ring and the author could create and draw an
> entirely new path that does not fit the one passed to the magnifier. Is that
> incorrect?

It would be a pointless use of the function. The whole point of the function is
to indicate to the accessibility APIs what area is going to be focused, and
allow users who need special focus rings to get their focus rings, while other
users can get the author's preferred look.


> Having a text be a different size is not a focus "ring". This sounds like a new
> requirement.

Yet it's how many games (the main use case for canvas) draw focus when the user
doesn't need custom focus rings.


> Ian, the problem I want to avoid is dropping out of the function
> and allowing an author to then draw a custom ring that does not match the one
> generated in drawFocusRing().

That makes no sense. The whole point of the API is to allow that.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 10 May 2011 22:30:18 UTC