Re: hit regions and a11y geometrics

I don't know if it's in the spec, it's probably Firefox implementation
detail. But as long as it's useful it makes sense to request it to be in
the spec.


On Mon, Feb 3, 2014 at 8:56 AM, Rik Cabanier <cabanier@gmail.com> wrote:

>
>
>
> On Mon, Feb 3, 2014 at 8:14 AM, Alexander Surkov <
> surkov.alexander@gmail.com> wrote:
>
>> I should probably answer, just for the record.
>>
>>
>> On Thu, Jan 30, 2014 at 11:26 AM, Richard Schwerdtfeger <
>> schwer@us.ibm.com> wrote:
>>
>>>
>>> Rich Schwerdtfeger
>>>
>>> Alexander Surkov <surkov.alexander@gmail.com> wrote on 01/30/2014
>>> 01:04:29 PM:
>>>
>>> > From: Alexander Surkov <surkov.alexander@gmail.com>
>>> > To: Dominic Mazzoni <dmazzoni@google.com>
>>> > Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>, Richard
>>> > Schwerdtfeger/Austin/IBM@IBMUS, Rik Cabanier <cabanier@gmail.com>,
>>> > Cynthia Shelly <cyns@microsoft.com>
>>> > Date: 01/30/2014 01:05 PM
>>> > Subject: Re: hit regions and a11y geometrics
>>>
>>> >
>>> >
>>>
>>> > On Thu, Jan 30, 2014 at 10:46 AM, Dominic Mazzoni <dmazzoni@google.com>
>>> wrote:
>>> > On Wed, Jan 29, 2014 at 5:03 PM, Alexander Surkov <
>>> surkov.alexander@gmail.com
>>> > > wrote:
>>> > A first thesis I would make is the web author can do CSS to define
>>> > geometry of DOM elements underneath the canvas and in most cases it
>>> > should work well.
>>> >
>>> > I think the problem with this is that it adds an enormous burden to
>>> > the developer, to convert from transformed canvas pixel coordinates,
>>> > back to CSS coordinates. I can draw a nice animated UI with a
>>> > combination of rotations, translations, and scales, plus complex
>>> > curved paths. Why should I need to reverse all of that math in order
>>> > to specify the accessible bounding box of a focusable element within
>>> that UI?
>>> >
>>>
>>> Agreed. What is more the author is intentionally using Canvas to draw
>>> their UI. They are not using CSS to do this. Forcing them to use CSS does
>>> not make any sense.
>>>
>>>
>> I didn't mean they have to CSS style their widgets from shadow DOM the
>> same way as they are drawn in canvas but using CSS to set size and coords
>> should be perfectly fine. After all this is just an approach from the
>> author's toolkit.
>>
>
> This is undefined though.
> There is nothing in the spec that says that CSS attributes are applied in
> the canvas shadow DOM. If there is, can you point me to that?
>
> Testing shows that only Firefox is doing layout in the shadow DOM.
>
>
>>  > Yes, it's some work but it's just a built-in option the web author can
>>> do.
>>> >
>>> > I think there's a lot of support behind the idea of (1) using canvas
>>> > drawing routines to draw a focus ring, and (2) specifying the
>>> > accessible bounding box of an element, using canvas coordinate
>>> > space. The disagreements seem to be about the exact semantics of a
>>> > drawFocus* function, and how much it should do with accessible
>>> > bounding boxes vs having a different API for that.
>>> >
>>> > Hit regions could solve many of these problems in theory, but I keep
>>> > hearing that there's no consensus on those. Who exactly doesn't want
>>> > to implement hit regions?
>>>
>>> Hit regions are a way of and it really should rely on people creating
>>> their own paths. Paths are not done either.
>>>
>>
>> hit regions work with current path and Path object the same way as
>> drawFocusIfNeeded does.
>>
>
> Yes, from reading the (very complex) hit region spec, you could do a
> simple polyfill that just creates or overrides a hit region every time you
> call drawFocusIfNeeded.
>