Re: [whatwg] Outline style to use for drawSystemFocusRing

On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson <> wrote:

> On Mon, 30 Sep 2013, Rik Cabanier wrote:
>> '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'
> On Mon, 30 Sep 2013, Rik Cabanier 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)
>> In light of that, maybe it's OK to leave the spec as-is. '
>> notifyFocusLocation' is just as confusing...
> Yeah... The current name isn't great, but I don't know what would be
> better (without making its name an essay or something).


> On Mon, 30 Sep 2013, Dominic Mazzoni wrote:
>> Yes, but I'm arguing that the high contrast rings is not a good idea and
>> we should drop that part of the spec.
> Some users have great trouble seeing the default focus rings.


>> Once that part is gone (or once no browser has plans to implement that
>> part), drawCustomFocusRing no longer makes sense.
> It's certainly true that if we don't want to support users with poor
> vision, the API would be simpler. But I don't think that's an option. We
> don't get to arbitrarily ignore some users.

Yes, I hope not :)

> But drawCustomFocusRing() does more than just draw high-contrast focus
> rings. It also moves the magnification, moves the screen-reader focus,
> etc. It does everything drawSystemFocusRing() does other than draw the
> actual focus ring.

So it seems that a real question is whether browsers prefer to deal with  
two APIs, or allow customisation of "the" focus ring. which comes down to  
a question of implementation strategy - do browsers rely on a system focus  
style, or draw it themselves, feeding from a system default style?

>> 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.
> How would this differ from scrollPathIntoView() ?



Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex         Find more at

Received on Monday, 30 September 2013 23:41:44 UTC