W3C home > Mailing lists > Public > public-canvas-api@w3.org > July to September 2011

Precedent for click events on non-visible items

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 18 Jul 2011 14:27:34 -0700
Message-ID: <4E24A546.50301@jumis.com>
To: Canvas <public-canvas-api@w3.org>
A repeated use case for Canvas UI widgets has been simply, to use Canvas 
as a presentational layer,
to improve the aesthetic of UA rendered input controls.

Part of the proposal that Richard put forward months ago, and has been 
repeated since by a few others on this list,
has to do with marshaling pointer events into the shadow dom.

Proposals for something to bind the current path to an element in the 
shadow dom, for the accessibility tree
as well as -possible- point event marshaling:

Richard Schwerdtfeger:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0081.html
http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/att-0090/Canvas2DClickableRegion.html#focus-management 


Charles Pritchard (me):
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0187.html

Jonas Sickling:
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0195.html


There's precedent for special handling of click() events on non-visible 
items:
https://dev.mozilla.jp/localmdc/localmdc_6373.html#Using_hidden_file_input_elements_using_the_click%28%29_method

There's precedent of marshaling click events from html label tags.

There's precedent for the setting of an onclick handler as a special cue 
to the UA
that more work should be done; such as setting onclick to enable touch 
events to be received by an element.

Adding z-index aware hit testing to Canvas is not a fun task, but the 
components are available to do it
and Canvas developers have expressed a strong desire to use 
addEventListener semantics directly on shadow dom nodes.

The hit testing paths would not be "visible" to the scripting 
environment, just as the bounding box information
and other info sent to the UA accessibility api is not visible. As such, 
this is not a retained-mode issue for canvas.

The following example (untested) would show a light blue box with the words
"press me" to the user, which the user could then click on to receive an 
alert.

The platform accessibility API is fully notified that the 2d region is a 
button
and the UA marshals the click event directly to the button, where it 
then bubbles up normally.

The a11y api is fully populated, the dom contains normal html semantics,
and the method setElementPath is reasonably backwards compatible. More 
advanced a11y apis
may chose to pass path information in addition to the bounding box info, 
as is done with drawFocusRing.

<canvas onclick="if(event.target != this) return; 
legacyHitTest(this,event);"><button id="button" onclick="alert('you did 
it!');">press me</button></canvas>
<script>var button = document.getElementById('button');
var ctx = button.parentNode.getContext('2d');
ctx.fillStyle='lightblue';
ctx.rect(30,30,60,60);
ctx.setElementPath(ctx,'1'); // z-index optional
ctx.fill();
ctx.fillText(button.textContent,35,55);
</script>


-Charles
Received on Monday, 18 July 2011 21:28:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 July 2011 21:28:01 GMT