[whatwg] Outline style to use for drawSystemFocusRing

[Rik Cabanier]

On Fri, Oct 4, 2013 at 1:56 AM, Dominic Mazzoni <dmazzoni at 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 at 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