W3C

Canvas Accessibility Sub-Group Teleconference

14 Apr 2014

See also: IRC log

Attendees

Present
Mark Sadecki, PLH, Janina, Rik Cabanier, Jay Munro
Regrets
Rich Schwerdtfeger
Chair
Mark Sadecki
Scribe
Mark Sadecki

Contents


<trackbot> Date: 14 April 2014

Update from Mark

W3C/WHAT WG diff analysis (for cherry picking and bug filing)

http://lists.w3.org/Archives/Public/public-canvas-api/2014AprJun/att-0011/14-canvas_diff_analysis.html

Added method clearHitRegions() http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions

RC: WHAT WG already said they will not be making the change from pixels to paths.
... WHAT WG has a process for using a scratch bitmap to manage regions. We are using paths for that
... clearRect has the same effect as clearHitRegions()

<plh> "Clear regions that cover the pixels in pixels in the canvas element."

JM: clearRect is still in ours as well

MS: clearHitRegions is a more elegant way of clearing hit regions.

PLH: comparing clearRect and clearHitRegions. Why the difference re garbage collection

<plh> "Garbage-collect the regions of the canvas element."

<plh> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions

<plh> http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearrect

PLH: think we should take out the ref to garbage collection in clearHitREgions

AGREED

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region

RC: I don't think we need to add WHAT WG step 4 (control represented by a region). covered by our step 3.

AGREED

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#clear-regions-that-cover-the-pixels

RC: We have a list of paths, so we don't need such an algorithm

AGREED

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-addhitregion

RC: we use paths, so this rule doesn't apply to our spec

MS: Clipping regions

RC: That must have been added in the last couple weeks
... it makes sense. Not sure how we would implement this.
... a hit region can be clipped
... i think we should add this to our spec but reword it so that it deals with path and not pixels
... "remove from specified path..."

PLH: how will you clip pixels if you are working with path

RC: Clipping area is already based on path
... test the hit region and all their clipping paths
... unless we change addHitRegion to combine the clipping region with the current path

JM: the path resolves to pixels in our spec, so the wording can be similar
... just not refer to fillRule

http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#the-region-for-a-pixel

<plh> to be added "Remove from specified pixels any pixels not contained within the clipping region."

JM: I think path would work there.

RC: I don't think this needs to change

JM: should we remove the underscore

RC: I actually think we should change this to path. Link it to path

Mouse event (re)targeting

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-mouseevent-region

PLH: not sure if its easy to change the target of an event before its dispatched

RC: This would be really tricky to implement
... in FF it would be a tremendous amount of work

PLH: Why exactly would that be?

RC: browsers default behavior, its done in C++
... have to teach source algorithms about canvas
... probably won't have an implementation in 6 months
... makes sense to do it this way, but it would take a while to get it implemented

PLH: WHAT WG attempts to do this without modifying DOM event spec
... no magic here
... other way would be to dispatch event, then when you hit canvas, dispatch a new event.
... or, once you reach canvas, change the target. that is like magic, not specified anywhere

JM: Jatinder said we would need to talk to ?? Jacob

PLH: if we move the mouse over a region, which has a control, now I don't target that to canvas, it targets the control

RC: it bubbles up until it gets captured
... as you are moving over it, the event target changes.
... event retargeting is not as simple as it seems
... previously we considered not sending it to fallback contact, just send it to canvas and let the developer manage
... that might still be forward compatible.

PLH: i think we would have to add a method
... to help the developer

RC: it would be the region ID
... would be filled in automatically

JM: They would get the mouse event from canvas and if the ID matches a control, there is a region

RC: Rich said he wanted to see mouse enter and leave

PLH: what was wrong with not retargeting the event?

RC: That would work for me

PLH: i say we do it this way and get feedback from implementers. sounds like this would be easier and the burden on authors is not that much
... doesn't change the target during mouse move. that is a win for me
... do we want session id or control

RC: I think just the ID is enough

PLH: is there a case where dev would be interested in region ID and not the control

JM: in L1, it sounds like that would work. In L2, that might now work

PLH: might be worth it to add a note saying that we won't be adding support event re-routing
... just support for region id

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-04-15 15:03:49 $