On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson <[email protected]> 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).

Right...

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.

yeah.

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() ?

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
      [email protected]         Find more at http://yandex.com

Reply via email to