This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Allow image maps to be added to the canvas element: <canvas usemap="#test"> This will make it easy for developers to add focusable interactive regions to canvas.
Related References: Minutes from the canvas group http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0148.html Re: minutes: Canvas sub-group HTML A11y Task Force telecon, 2010-02-15 http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0160.html Greg Houston: http://demos.greghoustondesign.com/piechart/ http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014136.html
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Unfortunately if we provide this we will be causing authors huge headaches, because while it would be possible to use canvas with image maps for the most trivial of pictures (pictures much better rendered on the server side), it becomes vastly more complicated to use image maps to do the slightest dynamic work once the canvas is made in any way more advanced. For example, any use of transforms, any use of large strokes, anything animated, etc, quickly makes it inordinately difficult to use image maps. In the meantime, all the use cases of image maps are trivially handled today using the API. Therefore I think it would be a design mistake to do this.
(In reply to comment #2) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are > satisfied with this response, please change the state of this bug to CLOSED. If > you have additional information and would like the editor to reconsider, please > reopen this bug. If you would like to escalate the issue to the full HTML > Working Group, please add the TrackerRequest keyword to this bug, and suggest > title and text for the tracker issue; or you may create a tracker issue > yourself, if you are able to do so. For more details, see this document: > http://dev.w3.org/html5/decision-policy/decision-policy.html > > Status: Rejected > Change Description: no spec change > Rationale: Unfortunately if we provide this we will be causing authors huge > headaches, because while it would be possible to use canvas with image maps for > the most trivial of pictures (pictures much better rendered on the server > side), it becomes vastly more complicated to use image maps to do the slightest > dynamic work once the canvas is made in any way more advanced. For example, any > use of transforms, any use of large strokes, anything animated, etc, quickly > makes it inordinately difficult to use image maps. In the meantime, all the use > cases of image maps are trivially handled today using the API. > > Therefore I think it would be a design mistake to do this. >
http://www.w3.org/html/wg/tracker/issues/105
For what it's worth: I don't believe the WebKit project would object to allowing image maps on <canvas>. However, we would likely suggest in that case that <area> should be extended with a new shape that can specify an arbitrary bezier path.
I disagree with the rejection response. Just because there are many complex cases to which image maps would be hard to apply does not mean there are not a plethora of simple cases for which image maps would be extremely handy. Using a mouse click to zoom in is a great example of where this would be handy. Since browser-interoperable mouse position determination is so incredibly complicated, an image map makes a nice, simple solution, especially where (as is likely the case) the precision of the click position need not be extremely precise. The only potentially convincing counterargument I can think of to adding image maps to canvas elements is that the same thing can be accomplished by overlaying transparent, absolutely-positioned anchors. That is, however, a very kludgey way to handle it, and does not trivially deal with non-rectangular areas.
(In reply to comment #6) > The only potentially convincing counterargument I can think of to adding image > maps to canvas elements is that the same thing can be accomplished by > overlaying transparent, absolutely-positioned anchors. That is, however, a > very kludgey way to handle it, and does not trivially deal with non-rectangular > areas. Yeah that has been bounced around. E.g. http://lists.w3.org/Archives/Public/public-html/2010Feb/0186.html
http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0124.html The bug triage sub-team believes the HTML A11Y TF should take up this bug. Additional notes may follow in a separate comment.
bug triage sub-team understands this is open for counter-proposals and needs no further tracking at TF level at this time
This bug has been escaleted in ISSUE 105
Comment via Rich Schwerdtfeger: We are not using this for canvas.