21:22:23 RRSAgent has joined #html-a11y
21:22:23 logging to http://www.w3.org/2014/04/14-html-a11y-irc
21:22:25 RRSAgent, make logs world
21:22:25 Zakim has joined #html-a11y
21:22:27 Zakim, this will be 2119
21:22:27 ok, trackbot; I see WAI_HTML AT()6:00PM scheduled to start in 38 minutes
21:22:28 Meeting: HTML Accessibility Task Force Teleconference
21:22:28 Date: 14 April 2014
21:22:45 agenda?
21:22:51 agenda+ Update from Mark
21:22:51 agenda+ W3C/WHAT WG diff analysis (for cherry picking and bug filing)
21:22:51 agenda+ Mouse Events
21:22:51 agenda+ Consensus for taking to Last Call
21:22:52 agenda+ Next Meeting
21:56:30 WAI_HTML AT()6:00PM has now started
21:56:37 +Mark_Sadecki
21:57:04 zakim, drop agenda item 3
21:57:04 I don't understand 'drop agenda item 3', MarkS
21:57:10 zakim, drop item 3
21:57:10 agendum 3, Mouse Events, dropped
21:57:34 agenda+ Mouse event (re)targeting
21:57:39 zakim, agenda?
21:57:39 I see 5 items remaining on the agenda:
21:57:40 1. Update from Mark [from MarkS]
21:57:40 2. W3C/WHAT WG diff analysis (for cherry picking and bug filing) [from MarkS]
21:57:40 4. Consensus for taking to Last Call [from MarkS]
21:57:40 5. Next Meeting [from MarkS]
21:57:40 6. Mouse event (re)targeting [from MarkS]
21:57:51 zakim, agenda order is 1,2,6,4,5
21:57:51 ok, MarkS
21:57:55 agenda?
21:58:00 jaymunro has joined #html-a11y
21:58:51 plh has joined #html-a11y
21:58:56 +Plh
21:59:25 gaphrod has joined #html-a11y
21:59:59 +??P1
22:00:14 zakim, ??P1 is me
22:00:14 +janina; got it
22:01:12 +[IPcaller]
22:01:47 zakim, [IPc is me
22:01:47 +cabanier__; got it
22:01:58 +[Microsoft]
22:02:03 zakim, microsoft has me
22:02:03 +jaymunro; got it
22:02:57 doesn't look muted on this end, let me call in again
22:03:04 -[Microsoft]
22:03:39 +[Microsoft]
22:03:45 zakim, take up next item
22:03:45 agendum 1. "Update from Mark" taken up [from MarkS]
22:03:48 zakim, microsoft has me
22:03:48 +jaymunro; got it
22:06:16 zakim, take up next item
22:06:16 agendum 2. "W3C/WHAT WG diff analysis (for cherry picking and bug filing)" taken up [from MarkS]
22:06:25 http://lists.w3.org/Archives/Public/public-canvas-api/2014AprJun/att-0011/14-canvas_diff_analysis.html
22:08:25 Added method clearHitRegions() http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions
22:12:10 RC: WHAT WG already said they will not be making the change from pixels to paths.
22:13:05 ...WHAT WG has a process for using a scratch bitmap to manage regions. We are using paths for that
22:14:20 ...clearRect has the same effect as clearHitRegions()
22:14:46 "Clear regions that cover the pixels in pixels in the canvas element."
22:15:21 JM: clearRect is still in ours as well
22:15:37 MS: clearHitRegions is a more elegant way of clearing hit regions.
22:16:21 PLH: comparing clearRect and clearHitRegions. Why the difference re garbage collection
22:16:42 "Garbage-collect the regions of the canvas element."
22:16:53 http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearhitregions
22:17:12 http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#dom-context-2d-clearrect
22:18:05 PLH: think we should take out the ref to garbage collection in clearHitREgions
22:18:09 AGREED
22:19:06 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region
22:24:22 RC: I don't think we need to add WHAT WG step 4 (control represented by a region). covered by our step 3.
22:25:08 AGREED
22:25:21 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#clear-regions-that-cover-the-pixels
22:26:36 RC: We have a list of paths, so we don't need such an algorithm
22:27:14 AGREED
22:28:13 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-addhitregion
22:30:26 RC: we use paths, so this rule doesn't apply to our spec
22:32:11 MS: Clipping regions
22:32:22 RC: That must have been added in the last couple weeks
22:32:32 ...it makes sense. Not sure how we would implement this.
22:33:42 ...a hit region can be clipped
22:34:18 ...i think we should add this to our spec but reword it so that it deals with path and not pixels
22:34:57 ..."remove from specified path..."
22:35:41 PLH: how will you clip pixels if you are working with path
22:35:55 RC: Clipping area is already based on path
22:36:07 ...test the hit region and all their clipping paths
22:36:59 ...unless we change addHitRegion to combine the clipping region with the current path
22:38:05 JM: the path resolves to pixels in our spec, so the wording can be similar
22:38:14 ...just not refer to fillRule
22:38:40 http://www.w3.org/html/wg/drafts/2dcontext/html5_canvas_CR/#the-region-for-a-pixel
22:38:48 to be added "Remove from specified pixels any pixels not contained within the clipping region."
22:40:17 JM: I think path would work there.
22:43:01 RC: I don't think this needs to change
22:43:20 JM: should we remove the underscore
22:44:35 RC: I actually think we should change this to path. Link it to path
22:45:29 zakim, take up next item
22:45:29 agendum 6. "Mouse event (re)targeting" taken up [from MarkS]
22:46:28 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-mouseevent-region
22:47:55 PLH: not sure if its easy to change the target of an event before its dispatched
22:48:03 RC: This would be really tricky to implement
22:48:14 ...in FF it would be a tremendous amount of work
22:48:21 PLH: Why exactly would that be?
22:48:52 RC: browsers default behavior, its done in C++
22:49:05 ...have to teach source algorithms about canvas
22:49:18 ...probably won't have an implementation in 6 months
22:49:36 ...makes sense to do it this way, but it would take a while to get it implemented
22:50:41 PLH: WHAT WG attempts to do this without modifying DOM event spec
22:50:52 ...no magic here
22:51:00 ...other way would be to dispatch event, then when you hit canvas, dispatch a new event.
22:51:41 ...or, once you reach canvas, change the target. that is like magic, not specified anywhere
22:52:00 JM: Jatinder said we would need to talk to ?? Jacob
22:52:55 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
22:53:02 RC: it bubbles up until it gets captured
22:53:16 ...as you are moving over it, the event target changes.
22:53:32 ...event retargeting is not as simple as it seems
22:54:01 ...previously we considered not sending it to fallback contact, just send it to canvas and let the developer manage
22:54:12 ...that might still be forward compatible.
22:54:27 PLH: i think we would have to add a method
22:54:32 ...to help the developer
22:54:59 RC: it would be the region ID
22:55:01 ...would be filled in automatically
22:55:18 JM: They would get the mouse event from canvas and if the ID matches a control, there is a region
22:55:36 RC: Rich said he wanted to see mouse enter and leave
22:56:14 PLH: what was wrong with not retargeting the event?
22:56:33 RC: That would work for me
22:58:44 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
22:59:59 ...doesn't change the target during mouse move. that is a win for me
23:00:53 ...do we want session id or control
23:01:12 RC: I think just the ID is enough
23:01:32 PLH: is there a case where dev would be interested in region ID and not the control
23:02:35 JM: in L1, it sounds like that would work. In L2, that might now work
23:05:31 PLH: might be worth it to add a note saying that we won't be adding support event re-routing
23:05:41 ...just support for region id
23:06:35 -Plh
23:06:37 -Mark_Sadecki
23:06:38 -cabanier__
23:06:38 -janina
23:06:41 -[Microsoft]
23:06:42 WAI_HTML AT()6:00PM has ended
23:06:42 Attendees were Mark_Sadecki, Plh, janina, [IPcaller], cabanier__, jaymunro
23:11:02 rrsagent, make minutes
23:11:02 I have made the request to generate http://www.w3.org/2014/04/14-html-a11y-minutes.html MarkS