Re: Checkbox with pointer events revised for setElementPath and beginElement

On Mon, Nov 14, 2011 at 4:56 PM, Charles Pritchard <chuck@jumis.com> wrote:

> Jonas, drawFocusRing already sets up and expects path-based semantics.
>
> We've not gotten to a point in this discussion about whether the
> drawFocusRing semantic
> would be retired in favor of beginElement/setElementPath. I suspect that
> it will be maintained.
>
> I'm still a bit unsure as to what Maciej and Hixie had in mind with the
> WHATWG draft of focus rings.
>
> Here, on pastebin, is an update to the checkbox example from the W3C
> Canvas 2d spec:
> http://pastebin.com/gGHQdDZQ
>
> In both cases, I'm only setting the clickable regions once, as they do not
> change position during the scope of this script's execution. I'm using
> aria-busy as a placeholder for that. Thus lines 71 and 72.
>
> Note that line 74 - 80 effectively and efficiently signals the pointer
> region.
> It re-uses the pathOnly semantic we added earlier for drawFocusRing.
>
> Line 82 , 84 and 86 uses the beginElement semantic as you intended.
>

Part of the goal here is to be able to get rid of hit-testing. Once we have
setPathForElement/setDrawingFor/beginElement basically all the code in
lines 98-145 is no longer needed.

Once we do that, the code at 24-30 and 74-30 is needed for
setPathForElement vs. 82, 84 and 86 for beginElement/setDrawingFor. This
seems like a clear win in ease of use for beginElement/setDrawingFor.


> It's less efficient than setPathForElement.
>

How so?


> The browser does a lot of unnecessary extra work for beginElement, and
> it'd require a lot more work on implementers to support beginElement.
>

What "extra work" and "more work" are you referring to here specifically?


> From a coding perspective: setPathForElement works with drawFocusRing
> semantics, and it's less likely that coders will encounter unwanted side
> effects. I'm more likely to use beginElement as I used setPathForElement
> (line 74-80); but then I'd have to set the fillStyle to transparent, and
> run a fill command. Instead, I take a risk of side effects in the lengthier
> drawCheckbox code path.
>

I do see the advantage of being compatible with drawFocusRing as well as
sites that want to be compatible both with existing browsers and browsers
which use the new API we're creating.

Ultimately I think all of these proposals are extremely close in
functionality and so I can live with either of them. The main goal that I
have is that I want to come up with a solution that makes it attractive for
people to do their hit testing using the new API. That is how we can
encourage people to build websites which are accessible to everyone. If we
create a solution which "only" adds value for AT users then we'll see a lot
fewer sites using it. I.e. bolt-on solutions tend to see much less use than
approaches which are accessible by default.

So whatever API will make the most people use it to do all of their hit
testing using the UA API I think will be the API which will lead to the
most accessibility friendly websites.

/ Jonas