- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 4 Oct 2013 23:46:48 -0700
- To: Dominic Mazzoni <dmazzoni@google.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Fri, Oct 4, 2013 at 1:56 AM, Dominic Mazzoni <dmazzoni@google.com> wrote: > if as a web author I call drawCustomFocusRing and it returns false, I'm >>> not supposed to draw anything according to the spec. That's what doesn't >>> make sense to me. >> >> > Why not? >> It means that either the element was not focused or the user selected >> high contrast focus rings. >> The return value of true means that you as an author can draw the focus >> ring in any style. > > > Yes, I agree that's exactly what the spec says. > > What I don't understand is how a browser is supposed to implement the high > contrast focus ring support on a real operating system that exists today. > Are there other apps that do this? Are there published guidelines anywhere? > Well, I assume that there was a good reason that this was added to the spec. It's too bad that Rich is on vacation since he is most familiar with this. > > Windows has a system setting for high-contrast mode. When you turn on high > contrast mode, it changes the default color palette. There's no other > effect on the focus ring that I know of. > > Windows also has settings for the focus ring width. I agree those should > affect the system focus ring, but I don't think users would expect that to > override a canvas author's focus ring. > > High contrast mode may affect the system focus ring color, it's true - but > there's no reason to believe that this system focus ring would look better > on a canvas when high contrast mode is on, and in fact it might look much > worse. > > Third-party accessibility tools that draw focus rings aren't relevant > here. They draw independently of applications; applications like browsers > are not supposed to draw anything different. > It is possible that this is designed for an in-house application that uses the canvas APIs. It doesn't have to be a browser. > > > Or, here's another argument: a canvas can contain absolutely anything. It > might contain a wild and crazy color palette. Only the canvas author knows > what focus ring is going to be visible on top of that canvas. If the canvas > is white text on a black background, then a dark-colored focus ring is > going to be practically invisible, and vice versa. > A focus ring could use blending modes or other graphical features that would ensure that it's always visible. > > It just doesn't make any sense to me that we're providing an API that > says, if you want to draw your own focus ring, use this - BUT, under some > circumstances we're going to tell you not to draw it and the browser or > operating system is going to draw it for you, even though the browser has > no idea what colors are on your canvas and what type of focus ring would be > visible against it. > > If the author wants to draw their own focus ring, it's probably for a good > reason. We should let them. > No, since the author doesn't know that special focus rings are required, it's reasonable to let the UA handle that case. > > We may also want to give web authors visibility into the system color > palette so they can adjust the entire canvas - and not just focus rings - > for high contrast mode. But that's out of the scope of this discussion. > Yes > > On Wed, Oct 2, 2013 at 8:20 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> I just tried this with canary and your demo file, and it is not scrolling >> to the focus ring. Is this what you are asking for? >> > > Yes. > > >> If so, I agree that we should update the spec. There is not much point >> that you can tab into fallback content but the browser doesn't scroll to >> the path. >> > > Agreed. > Great. This means that the steps from 'scrollPathIntoView' [1] should go into the focus ring steps too. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-scrollpathintoview
Received on Saturday, 5 October 2013 06:47:14 UTC