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