Checkbox with pointer events revised for setElementPath and beginElement

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.
It's less efficient than setPathForElement.

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

 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.

-Charles

Received on Tuesday, 15 November 2011 00:57:11 UTC