W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Outline style to use for drawSystemFocusRing

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 7 Jan 2014 21:18:04 -0800
Message-ID: <CAGN7qDB0ByibiwDUXgO+2s3OGoD_JUNpFaXWNdd-x=PELc2a4A@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Dominic Mazzoni <dmazzoni@google.com>, Ryosuke Niwa <rniwa@apple.com>
On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson <ian@hixie.ch> wrote:

> > I don't see that as an argument against caching the last known location
> > of an object too.
> If you want to store state, that's what addHitRegion() is for. It's the
> retained mode API for canvas. The draw*FocusRing() methods are direct-mode
> APIs. There's no expiry logic, there's no API contract that implies that
> the calls will be made, or made correctly, if the element isn't focused.

I believe this is where part of our confusion/disagreements come from.
The draw*FocusRing methods are NOT direct-mode APIs for *a11y*.

By calling draw*FocusRing on a fallback element, the a11y software will now
associate that element (and its aria rules) with the path that was in the
canvas' state.
This HAS to be stateful because the a11y software queries the browser for
the bounds of the fallback element to draw its own focus rectangle.

For the blink and firefox implementations (and the webkit patch) "informing
the user" [1] means telling the DOM about the region of the fallback
element so the a11y software can query it later.
Because of this, there also needs to be a way to disassociate the region
from the fallback element (ie by having no current path when you call

> As a meta-point: when you, as an implementor, disagree with the spec, the
> right way to approach this is to report the problem, describe the use
> cases, and so forth. If you want to implement something different, the way
> to do that is to design a coherent API, and make sure this new API doesn't
> conflict with the specced API, and then implement that new API.
> Implementing something that is "inspired by", and conflicts with, what the
> spec proposal suggests, is not going to lead to a coherent platform,
> because it is is essentially just mixing in multiple people's designs and
> goals without coming up with a coherent single vision.
> To clarify, I'm not saying "implement what the spec says". I'm just
> saying, if you don't want to implement what the spec says, please do
> actually design a coherent complete solution. Otherwise we'll end up with
> things like a direct-mode API that acts like a retained-mode API but lacks
> core retained-mode features like expunging expired data.

I completely agree.
I *think* I'm on the same page as Rich and Dominic but we're all a bit
fuzzy on the details/edge cases.

Received on Wednesday, 8 January 2014 05:18:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC