IRC log of html-a11y on 2014-04-14

Timestamps are in UTC.

21:22:23 [RRSAgent]
RRSAgent has joined #html-a11y
21:22:23 [RRSAgent]
logging to
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]
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]
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]
21:58:00 [jaymunro]
jaymunro has joined #html-a11y
21:58:51 [plh]
plh has joined #html-a11y
21:58:56 [Zakim]
21:59:25 [gaphrod]
gaphrod has joined #html-a11y
21:59:59 [Zakim]
22:00:14 [janina]
zakim, ??P1 is me
22:00:14 [Zakim]
+janina; got it
22:01:12 [Zakim]
22:01:47 [cabanier__]
zakim, [IPc is me
22:01:47 [Zakim]
+cabanier__; got it
22:01:58 [Zakim]
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]
22:03:39 [Zakim]
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]
22:08:25 [MarkS]
Added method 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]
22:17:12 [plh]
22:18:05 [MarkS]
PLH: think we should take out the ref to garbage collection in clearHitREgions
22:18:09 [MarkS]
22:19:06 [MarkS]
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]
22:25:21 [MarkS]
22:26:36 [MarkS]
RC: We have a list of paths, so we don't need such an algorithm
22:27:14 [MarkS]
22:28:13 [MarkS]
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] 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]
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]
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] 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] 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] 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] 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] 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]
23:06:37 [Zakim]
23:06:38 [Zakim]
23:06:38 [Zakim]
23:06:41 [Zakim]
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 MarkS