Re: hit regions and a11y geometrics

On Mon, Feb 3, 2014 at 8:59 AM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

>
>
> Rich Schwerdtfeger
>
> Alexander Surkov <surkov.alexander@gmail.com> wrote on 02/03/2014
> 10:14:03 AM:
>
> > From: Alexander Surkov <surkov.alexander@gmail.com>
> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> > Cc: Rik Cabanier <cabanier@gmail.com>, Cynthia Shelly
> > <cyns@microsoft.com>, Dominic Mazzoni <dmazzoni@google.com>,
> > "public-canvas-api@w3.org" <public-canvas-api@w3.org>
> > Date: 02/03/2014 10:15 AM
>
> > Subject: Re: hit regions and a11y geometrics
> >
> > 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.
> >
>
> I understand but they are using canvas to do the drawing at a particular
> location. This is all based on transformations in canvas - not css.
>
> >
> > > 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.
>
> My point being that there is no Path object in Canvas 1.0. There are a
> number of additional methods from Canvas 2.0 which would need to be
> included to accommodate Path. If we were to add hit region support we would
> also need to add Path. We did not yet have Path support in browsers a month
> ago.
>

Alex is talking about the "current path" which lives in the canvas graphics
state. It's the same concept that we used for the drawFocusIfNeeded