Re: Checkbox with pointer events revised for setElementPath and beginElement

On 11/14/11 10:35 PM, Jonas Sicking wrote:
> On Mon, Nov 14, 2011 at 4:56 PM, Charles Pritchard <chuck@jumis.com 
> <mailto: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?

The additional hooks on fillText, stroke and fill to build up the 
bounding box that's otherwise explicit in 24 - 30.
It's very minor, especially in this demo, but it's there.

>     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.

Thanks, I appreciate that.

>
> 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.

I agree -- and that's why the proposals are both forwarding pointer 
events and not simply instructing the AT.

> 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.

We want them to use drawFocusRing as well, for keyboard support.
I think the similarity between the two will make it easier.

I'll do a round of e-mails this week and try to get some of the Canvas 
coders on the net to pop onto this mailing list.
There's always a chance we've missed something completely that they'll 
notice.

-Charles