[whatwg] Outline style to use for drawSystemFocusRing

[Rik Cabanier]

On Mon, Sep 30, 2013 at 1:48 PM, Dominic Mazzoni <dmazzoni at google.com>wrote:

> On Mon, Sep 30, 2013 at 1:25 PM, Rik Cabanier <cabanier at 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.
>

I just checked Windows and they offer the option "Make the focus rectangle
thicker". I checked IE and it honors that setting.
It's too bad that we didn't get feedback from them but it does look like
this is something IE would implement.


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

But it's not a 'notify' action though. You're basically asking the browser
if the author should draw the focus area (while also telling the browser
about the region)


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

That sounds very much like 'scrollPathIntoView'.
I think that this is changing the API too much.


>
> 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 at gmail.com>wrote:
>>
>>>
>>>
>>>
>>> On Thu, Sep 12, 2013 at 9:32 AM, Dominic Mazzoni <dmazzoni at google.com>wrote:
>>>
>>>> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at 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'
>>>
>>
>>
>