- From: Dominic Mazzoni <dmazzoni@google.com>
- Date: Mon, 30 Sep 2013 13:48:19 -0700
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier <cabanier@gmail.com> wrote: > Ian pointed out on IRC that 'drawCustomFocusRing' *could* draw if the > user requested high contrast rings. (Since I prototyped it in Firefox which > does not have this feature, I forgot about that case) > Yes, but I'm arguing that the high contrast rings is not a good idea and we should drop that part of the spec. Once that part is gone (or once no browser has plans to implement that part), drawCustomFocusRing no longer makes sense. > In light of that, maybe it's OK to leave the spec as-is. ' > notifyFocusLocation' is just as confusing... > I don't think notifyFocusLocation is just as confusing as having a drawCustomFocusRing API that never actually draws. I do agree that most web developers might not realize who is being notified and why, but they can at least surmise that *someone* cares about the focus location and wants to be told where it is. Here's my alternative idea, though: how about calling it something like scrollFocusedObjectIntoView, and have the *primary* purpose of the API be to make the browser scroll the viewport, if needed to make sure that the bounding box of the path is visible, if that object is focused. The drawFocusRing spec would be modified to specify that scrolling the viewport is part of the spec, too. Both APIs would also have accessibility implications, of course - but the average web developer who doesn't know much about accessibility would have two useful APIs for handling focused controls in a canvas, that are easy to test if they're working in any browser. - Dominic > > > > On Mon, Sep 30, 2013 at 10:15 AM, Rik Cabanier <cabanier@gmail.com> wrote: > >> >> >> >> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni@google.com>wrote: >> >>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian@hixie.ch> wrote: >>> >>> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote: >>> > > >>> > > We've finished implementing drawSystemFocusRing and >>> drawCustomFocusRing >>> > > in Chrome. Try it in Chrome 31 or higher (either canary or dev >>> channel >>> > > should work today). You'll need to go to chrome://flags and enable >>> > > *experimental canvas features*, then restart the browser. >>> > > >>> > > Here's a demo I built that uses drawSystemFocusRing: >>> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/ >>> > >>> > Looks good. Was your conclusion that the spec was ok as is, or did you >>> > deviate from the spec in some way that needs a spec change >>> > >>> >>> I think drawSystemFocusRing is good to go. If you want, you can update >>> the >>> spec to reflect that an implementation is available (behind a flag). >>> >>> Only one minor issue for clarification: if the current path is a line or >>> unclosed polygon, should it be closed (or otherwise outlined) when >>> drawing >>> the focus ring? Currently we're not doing so in Chrome, but it might help >>> to clarify. For example, if the path is a line, what's drawn is just an >>> additional stroke on that line, not a "ring". >>> >>> I'm not as sure about drawCustomFocusRing. The spec says "If the user has >>> requested the use of particular focus rings", but I'm not aware of any >>> platform API we could use to query that. To the best of my knowledge, >>> assistive technology that draws its own focus rings, like ZoomText, >>> normally draws an additional focus ring with extra padding, rather than >>> replacing the system one. (Example: >>> http://www.aisquared.com/zoomtext/tour/enhancements#focus_enhancements) >>> >>> So, I'm not sure how I'd implement that part of the spec. Chrome >>> definitely >>> has no plans to give users an additional preference for focus rings as a >>> browser setting. >>> >>> So, what we implemented in Chrome for drawCustomFocusRing is basically >>> just >>> a function that notifies assistive technology of the bounding rect of the >>> focused region within the canvas. It's still useful, but if that's all it >>> does, then drawCustomFocusRing is a poor name. Perhaps it should be >>> called >>> something like notifyFocusLocation or something like that. >>> >> >> 'drawCustomFocusRing' returns a boolean that signals the author that he >> is supposed to draw the focus ring. >> If you want to rename it, then maybe 'needsFocusRing' is better. >> >> 'drawSystemFocusRing' could then be simplified to 'drawFocusRing' >> > >
Received on Monday, 30 September 2013 20:48:45 UTC