- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Tue, 01 Oct 2013 01:41:17 +0200
- To: "Rik Cabanier" <cabanier@gmail.com>, "Dominic Mazzoni" <dmazzoni@google.com>, "Ian Hickson" <ian@hixie.ch>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Tue, 01 Oct 2013 01:10:25 +0200, Ian Hickson <ian@hixie.ch> 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 chaals@yandex-team.ru Find more at http://yandex.com
Received on Monday, 30 September 2013 23:41:44 UTC