This is an annoying problem with canvas. You have to have to apply keyboard and and mouse handlers on entirely different objects. The keyboard handler can be applied to a fallback content element that it belongs to, yet the pointing device handlers have to be applied to an entirely different element <canvas> for all the drawing objects in canvas.
This could be addressed by creating defining drawing paths in canvas and binding them to canvas fallback content that they are associated with. The pointing device events could be dispatched to the fallback content element in response to a hit. If the drawing paths were assigned a z-order a simple pointInPath() call could be used to assess the hit. If no path is hit the event would pass down to the canvas element just as it does today.
See the related bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13176
Didn't see this. Promoting to P1 for the same reason as bug 13176 comment 3.
mass-move component to LC1
Do you have a URL to a page showing this problem?
This bug was marked as P1 over 30 days ago, and still hasn't been RESOLVED.
Editors: please RESOLVE it ASAP. NEEDSINFO and WONTFIX are valid resolutions
for this part of the process. We simply want to get this bug to a state where
we are prepared to accept change proposals should anybody be inclined to
We had an agreement for 1 month turn around for P1 bugs, and this is well past that point. As such, if anybody wishes to escalate this, they can do so at this time.
Ian, the only way to add a mouse handler in canvas is to bind it to the canvas element. However, keyboard events do go to the actual fallback content itself as representations of objects that are drawn on canvas. At this stage I can't:
place three buttons in fallback content, and
place them in the keyboard navigation order, and
produce three corresponding drawing objects on canvas, and
place a on click handler on the individual buttons in fallback content and receive the events when a click occurs on those buttons renderings on canvas directy.
Rather I would have to place the onclick handler on the canvas element and perform the hit testing to dispatch the onclick to the fallback content elements. That is why the bug is filed.
You don't have to write an example to prove it.
Sam, if you feel it is necessary to escalate this please let me know. As far as I can tell this has not been closed or reopened. It is marked new.
(In reply to comment #6)
> Sam, if you feel it is necessary to escalate this please let me know. As far as
> I can tell this has not been closed or reopened. It is marked new.
If it is not a priority at this time, consider dropping the priority. If it is a priority, consider writing a Change Proposal.
Note: I spoke with David Bolter at Mozilla this week and he stated that they plan on implementing a solution for this by Q1 2012. That includes defect:
I'll speak with David about what he had in mind.
(In reply to comment #9)
> I'll speak with David about what he had in mind.
It would be best for all stakeholders if discussion occurs on a public mailing list not in secret
Reminder: a failure to escalate this bug by January 14th, 2012 will result in this bug no longer being treated as a last call comment:
BTW, it would be helpful if this wiki page (or another but with the same
structure) could be filled in documenting precisely what it is that needs
See also bug 13176.
Provide location information to assistive technology.
Issue Title: Provide canvas location and hit testing capability to fallback content
Issue text: Provide a facility to assign location information for rendered child of fallback content and provide a way to do hit testing within the location of the rendered child such that pointer events may be dispatched to the rendered child. The dimensions defining the location may be provided to an assistive technology, such as a magnifier, to determine the objects location on the screen.
Both bugs 13181 and 13176 must be associated with this issue.
Changed status per: http://lists.w3.org/Archives/Public/public-html/2012Jan/0087.html
Additional information for the editor: http://wiki.whatwg.org/wiki/Canvas#Limitations_of_real-world_use_cases
Reclosing since this is marked TrackerIssue, but note that I intend to address
this very shortly in a pretty comprehensive manner. See
http://wiki.whatwg.org/wiki/Canvas#Regions for details.
Comment via Rich Schwerdtfeger:
We have a hit testing proposal that includes paths that have been applied to canvas under the section Hit Regions. This allows an author to route mouse events to fallback content where the fallback element is bound to a closed path on canvas. Specifically, the addHitRegion has a control argument which refers to a fallback content element to which the events would be routed.