Re: draft of hit testing on active regions (actually paths) in canvas

setDrawingFor(null) lets you draw pixels which aren't associated with any
element. This was in my original proposal.

If you make endElement not take any arguments, and make beginElement
replace any existing element, then the difference is just syntactic with
endElement == setDrawingFor(null).

I don't care strongly about the difference, but a single function does seem
like a smaller API.

/ Jonas

On Monday, October 31, 2011, Frank Olivier <Frank.Olivier@microsoft.com>
wrote:
> IMO for
>
>
>
> beginElement(elem1);
>
> ... drawing operations here ...
>
> beginElement(elem2);
>
>
>
> beginElement(elem2) would do an implicit endElement(elem1)
>
>
>
>
>
> IMO for
>
>
>
> beginElement(elem1);
>
> ... drawing operations here ...
>
> endElement(elem2);
>
>
>
> …this would be an error case. We could actually change to
endElement(elem2) to just endElement(), which would also solve it.
>
>
>
> “It seems like having a single functions, rather than a pair, avoids a
lot of these types of edge cases.”
>
> This makes it impossible to draw into the canvas without associating
pixels with an input element (after the first beginElement() call).
Non-symmetrical APIs are a bad idea generally.
>
>
>
>
>
>
>
>
>
>
>
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Monday, October 31, 2011 5:39 PM
> To: Frank Olivier
> Cc: Richard Schwerdtfeger; public-canvas-api@w3.org;
public-html-a11y@w3.org; chucko@jumis.com; Cynthia Shelly;
david.bolter@gmail.com; janina@rednote.net; jbrewer@w3.org
> Subject: Re: draft of hit testing on active regions (actually paths) in
canvas
>
>
>
> What happens if beginElement is called twice? I.e. for code like:
>
> beginElement(elem1);
> ... drawing operations here ...
> beginElement(elem2);
> ... drawing operations here ...
> endElement(elem2);
> ... drawing operations here ...
> endElement(elem1);
>
> And what happens if the endElement call doesn't match the previous
beginElement call? I.e. code like:
>
> beginElement(elem1);
> ... drawing operations here ...
> endElement(elem2);
>
> It seems like having a single functions, rather than a pair, avoids a lot
of these types of edge cases.
>
> Additionally, I'd really like to hear the input from
</mail/u/0/s/?view=att&th=1335ca9998172f40&attid=0.1&disp=emb&zw>Charles
Pritchard on why a setPath-style API fits better with existing code. If
that's indeed the case then we might be able to much quicker get deployment
of this API on websites.
>
> / Jonas
>
> On Mon, Oct 31, 2011 at 4:46 PM, Frank Olivier <
Frank.Olivier@microsoft.com> wrote:
>
> A preview of that draft, based on notes I took during the meeting:
>
>
>
> These new methods manage the association of pixels drawn with canvas
fallback elements:
>
> beginElement(Element element);
>
> endElement(Element element);
>
> eraseElement(element) ;
>
> eraseElements();
>
>
>
> So, code example:
>
>
>
> For a html page with this content:
>
> <canvas>
>
>   <input type=checkbox id=checkboxA >Checkbox A</input>
>
>   <input type=checkbox id=checkboxB >Checkbox B</input>
>
> </canvas>
>
>
>
> By default, all pixels on a canvas are ‘unassociated’. The author would
use these new methods to associate pixels with fallback elements.
>
>
>
> When drawing the checkbox:
>
> // Rendering code
>
> ctx.beginElement(checkboxA);     //Tell the canvas context that all
non-fully-transparent pixels that we are rendering from this point on
represents the clickable area for the checkbox UI
>
> // Draw a background for the checkbox
>
> ctx.fillStyle = 'white’;
>
> ctx.rect(0, 0, 100, 20);
>
> context.fill();
>
>
>
> // Draw the actual checkbox
>
> ctx.rect(5, 5, 10, 10);
>
> ctx.stroke();
>
>
>
> if (checkboxA.checked)
>
> {
>
>   ctx.fillStyle = 'black';
>
>   ctx.fill();
>
> }
>
> ctx.fillText(‘checkbox’, 20, 10);
>
> endElement(checkboxA); //We are done with element rendering
>
>
>
> The UA/magnifier would associate any pixels rendered from beginElement()
to endElement() with the fallback dom element; the fallback dom element
‘owns’ those pixels on the screen. To resolve overlap, last write wins.
(Implementation note: A UA could use a bitmap to associate pixels with
fallback dom elements. A value of 0 in that bitmap could mean ‘no
association’; value 1 coul
>
>
>
> Jonas,
>
> We discussed your points on the PF call today. Apple was present. I will
write up a revised draft that associated drawing to the elements per your
request.
>
> Thanks for you feedback.
>
> Rich
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> </mail/u/0/s/?view=att&th=1335ca9998172f40&attid=0.2&disp=emb&zw>Richard
Schwerdtfeger---10/31/2011 11:03:00 AM---Rich Schwerdtfeger CTO
Accessibility Software Group
>
> From: Richard Schwerdtfeger/Austin/IBM@IBMUS
> To: Jonas Sicking <jonas@sicking.cc>,
> Cc: chucko@jumis.com, cyns@exchange.microsoft.com, david.bolter@gmail.com,
franko@microsoft.com, janina@rednote.net, jbrewer@w3.org,
public-canvas-api@w3.org, public-html-a11y@w3.org
> Date: 10/31/2011 11:03 AM
> Subject: Re: draft of hit testing on active regions (actually paths) in
canvas
>
> ________________________________
>
>
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> Jonas Sicking <jonas@sicking.cc> wrote on 10/27/2011 07:42:40 PM:
>
>> From: Jonas Sicking <jonas@sicking.cc>
>> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
>> Cc: franko@microsoft.com, chucko@jumis.com, david.bolter@gmail.com,
>> cyns@exchange.microsoft.com, public-html-a11y@w3.org,
>> janina@rednote.net, jbrewer@w3.org, public-canvas-api@w3.org
>> Date: 10/27/2011 07:43 PM
>> Subject: Re: draft of hit testing on active regions (actually paths)in
canvas
>>
>> Some feedback:
>>
>> Limiting to only allowing paths seems like a unfortunate limitation.
>> For example it misses calls to drawImage which I think is quite
>> common. I'd rather prefer a call where you say "all drawing operations
>> from this point should be considered drawing for element X", then let
>> the page do arbitrary drawing operations, then have a second call
>> which says "i'm now drawing for element Y" or "I'm now drawing for no
>> element".
>>
>
> I see. So what would you use compute the bounds? Do you use the all the
points to compute a single rectangle for hit testing? ... or do you compute
multiple paths for an element to do hit testing on?
>
>
>> What is the use case for the zIndex argument? The actual pixel drawing
>> operations hasn't had a need for that so far and instead rely on the
>> painters algorithm. It seems better to me to have a direct mapping
>> between the drawing operations and the accessibility API.
>>
> zIndex: Performance and authors may have overlapping drawing objects.
>
>> Why return false rather than throw an exception if the element doesn't
>> exist? Also what do you mean by "doesn't exist". If the element
>> doesn't exist then how could the page have a reference to it and pass
>> that reference to the function? Do you mean "element isn't inside the
>> canvas"?
>>
> Throwing an exception makes sense. I meant the element did not exist. I
am thinking that the author may have content outside fallback such as a
drop down menu. We could limit the elements to the fallback content. I
would like your feedback on that.
>
>> In general I think I prefer the API I proposed in [1]. Can you
>> describe what problems you were trying to solve with your changes
>> compared to that proposal?
>>
>> [1]
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html
>>
>> / Jonas
>>
>> On Thu, Oct 27, 2011 at 4:56 PM, Richard Schwerdtfeger
>> <schwer@us.ibm.com> wrote:
>> > Hi Frank,
>> >
>> > Thank you for the call today. I am glad we are on the same page onthe
three
>> > basic met
>
>