16:00:41 <RRSAgent> RRSAgent has joined #pointerevents
16:00:41 <RRSAgent> logging to http://www.w3.org/2014/01/07-pointerevents-irc
16:00:47 <ArtB> RRSAgent, make log public
16:00:55 <ArtB> ScribeNick: ArtB
16:00:56 <ArtB> Scribe: Art
16:00:56 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0001.html
16:00:56 <ArtB> Chair: Art
16:00:56 <ArtB> Meeting: Pointer Events WG Voice Conference
16:01:00 <Zakim> +rbyers
16:01:02 <jrossi2> * realized I don't have a mic .. brb
16:01:10 <Zakim> +Cathy
16:01:46 <Zakim> +Art_Barstow
16:01:59 <ArtB> zakim, who's here
16:01:59 <Zakim> ArtB, you need to end that query with '?'
16:02:14 <Zakim> +[Microsoft]
16:03:02 <Zakim> +[IPcaller]
16:03:13 <ArtB> Present: Art_Barstow, Doug_Schepers, Cathy_Chan, Rick_Byers, Jacob_Rossi, Olli_Pettay
16:03:21 <smaug> Zakim, [IPcaller] is Olli_Pettay
16:03:21 <Zakim> +Olli_Pettay; got it
16:03:43 <Zakim> +[Microsoft.a]
16:03:47 <smaug> Zakim, nick smaug is Olli_Pettay
16:03:47 <Zakim> ok, smaug, I now associate you with Olli_Pettay
16:03:56 <ArtB> Present+ Asir_Vedamuthu
16:04:06 <asir> asir has joined #pointerevents
16:04:37 <ArtB> Topic: Tweak agenda
16:04:42 <ArtB> AB: Happy New Year everyone!
16:04:47 <ArtB> AB: I posted a draft agenda a few days ago http://lists.w3.org/Archives/Public/public-pointer-events/2014JanMar/0001.html.
16:04:56 <ArtB> AB: without Sangwhan present, perhaps we should postpone the "Compatibility Events" topic.
16:05:10 <ArtB> ... any objections to that?
16:05:15 <ArtB> [ None ]
16:05:20 <ArtB> AB: any other change requests?
16:05:30 <ArtB> [ None ]
16:05:31 <ArtB> AB: anyone want to Scribe today's call?
16:05:54 <ArtB> RB: I'll do it
16:06:01 <ArtB> Scribe+ Rick
16:06:06 <ArtB> ScribeNick: rbyers
16:06:50 <rbyers> Topic: Bug 21749 Setting a capture on an offshore element AB: Jacob filed 21749 on 19-Apr-2013; <https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749>
16:07:09 <rbyers> zakim, who is noisy?
16:07:19 <Zakim> rbyers, listening for 10 seconds I heard sound from the following: Art_Barstow (75%), [Microsoft] (9%), [Microsoft.a] (42%)
16:07:47 <rbyers> AB: Originally based on input from Francois Remy
16:08:03 <ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0084.html -> Francois Remy
16:08:46 <rbyers> JR: Mail is longer than what I pasted into the bug
16:09:11 <rbyers> JR: It's possible this is an IE bug
16:09:41 <rbyers> JR: This is a good test case nonetheless - scenario requires some discussion
16:09:56 <rbyers> JR: Scenario: element not in the DOM - can you setCapture to that, let alone receive pointer events
16:10:14 <rbyers> JR: generally we avoid firing input events to elements that aren't in the DOM
16:11:00 <rbyers> JR: if you create an element (without putting it in the DOM) and call setPointerCapture, what should happen?
16:11:20 <rbyers> JR: Normally you'd only use setCapture on an element in the tree
16:11:31 <rbyers> JR: IE throws an exception but that's not written in the spec
16:11:32 <scott_gonzalez> scott_gonzalez has joined #pointerevents
16:11:42 <Zakim> +Scott_Gonzalez
16:12:03 <rbyers> ... either could see fixing IE to make it not throw
16:12:07 <rbyers> ... or update the spec to make it throw
16:12:21 <ArtB> Present+ Scott_Gonzalez
16:12:31 <rbyers> ... but open to discussion
16:12:45 <rbyers> RB: There's no scenario where an element not in the tree would receive a real input event, right?
16:13:05 <rbyers> JR: Right.  Closest is an input sync - but could just be in the tree
16:13:38 <rbyers> AB: If there are no other comments, Jacob should propose spec change to the list
16:14:06 <rbyers> OP: Agree we should throw some exception.  And for consistency if capture is on some element and then element is removed from the document, we should also release capture.
16:14:14 <rbyers> JR: Good point, we should capture that as well
16:15:43 <rbyers> DS: Trying to think of scenarios
16:16:07 <rbyers> SG: Scenarios where an element is removed and re-added elsewhere
16:16:20 <rbyers> ... as far as the user is concerned it's just moving, not being removed
16:17:20 <rbyers> ... not sure it needs to receive events while not in the tree, but should after it's re-inserted
16:17:58 <rbyers> RB: What does IE do when an element that has capture is removed from the DOM
16:18:15 <rbyers> JR: Just checking - believe it's released and get lostcapture event - good edge case we need to document
16:19:31 <rbyers> DS: Need to ensure event is rebased onto the right element
16:19:40 <rbyers> JR: Happens naturally as a result of hit-testing
16:20:54 <rbyers> RB: IE's behavior makes sense to me and ti seems quite edge-case since capture is always explicit (unlike touch events).
16:21:24 <rbyers> ... Assuming IE hasn't got complaints, I think we should just spec what IE does here.
16:21:35 <rbyers> DS: Are there developers using pointer events extensively today?
16:22:00 <rbyers> JR: Yes - tons.  Google maps, Bing maps, flipboard, all windows 8 apps, etc.
16:22:11 <rbyers> ... we get lots of feedback from developers
16:22:58 <rbyers> DS: What I meant is is there someone we know using pointer events we could ask for their input?
16:23:25 <rbyers> RB: Did Francois express an opinion on whether IE's behavior was reasonable?
16:24:00 <rbyers> JR: Sounds like he's leaning towards IE behavior
16:24:16 <rbyers> DS: What about shadow DOM?  Is that considered in the dom?
16:24:32 <rbyers> JR: Yes - just a different mechanism for how events propagate
16:26:10 <rbyers> JR: Test in IE shows that an element that has capture that is removed and re-added still receives events.
16:26:45 <ArtB> ACTION: Jacob propose text to address bug 21749; confirm change with Francois Remy
16:26:45 <trackbot> Created ACTION-57 - Propose text to address bug 21749; confirm change with francois remy [on Jacob Rossi - due 2014-01-14].
16:27:09 <rbyers> RB: How about Jacob confirms IE's behavior here (eg. what happens to the events while the capture element is out of the DOM)
16:27:19 <rbyers> Topic: Bug 21951 - [CR] pointermove dispatching when button state changes;
16:27:29 <ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0134.html -> comment from Scott
16:28:21 <ArtB> http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0141.html -> Jacob's reply to Scott
16:28:36 <rbyers> JR: Not clear in the spec that pointermove doesn't have to fire if the button change is captured by another event.
16:28:47 <rbyers> ... Eg. putting the pointer down doesn't need to ALSO fire a pointermove.
16:28:58 <rbyers> SG: Right
16:28:59 <jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21951
16:29:09 <rbyers> JR: Looks like we already agreed to add a sentence
16:29:43 <ArtB> ACTION: Jacob propose text to address bug 21951
16:29:44 <trackbot> Created ACTION-58 - Propose text to address bug 21951 [on Jacob Rossi - due 2014-01-14].
16:30:01 <rbyers> RESOLUTION: Clarify pointermove does not fire for button change described by other events
16:30:25 <rbyers> Topic: Add non-normative example section to mouse compatibility event mapping? Raised by Rick and Patrick Lauke on 10-Dec-2013
16:30:30 <rbyers> http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0067.html
16:31:03 <ArtB> http://www.w3.org/TR/2013/CR-pointerevents-20130509/#compatibility-mapping-with-mouse-events -> Mouse Interop
16:31:58 <rbyers> Details: http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0068.html
16:32:20 <rbyers> JR: Yes, adding an example and some clarifying text sounds like it would address his concerns.
16:32:37 <rbyers> ... would be relatively straight forward but helpful
16:32:45 <rbyers> ... all included in the algorithm, but requires the reader to trace the algorithm
16:32:52 <rbyers> ... would be helpful to have such examples
16:33:16 <ArtB> ACTION: Jacob propose text re "Add non-normative example section to mouse compat event mapping"; get confirmation from Patrick
16:33:16 <trackbot> Created ACTION-59 - Propose text re "add non-normative example section to mouse compat event mapping"; get confirmation from patrick [on Jacob Rossi - due 2014-01-14].
16:33:19 <rbyers> DS: Agree - suggest Jacob proposes some text for this
16:33:29 <rbyers> Topic: "List of Pointer Events" table default actions; raised by Patrick Lauke on 10-Dec-2013;
16:33:36 <rbyers> http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0069.html
16:33:49 <rbyers> DS: Currently no replies on the list
16:34:41 <rbyers> JR: Yes I discussed this with him over Twitter
16:35:21 <rbyers> ... confusion over word 'dispatch' isn't really the issue here
16:35:43 <rbyers> ... The table reads as only pointerdown dispatches compatibility mouse events
16:36:26 <rbyers> ... Not sure what the right wording is here
16:36:48 <rbyers> DS: Take discussion to the list or any other thoughts?
16:36:59 <ArtB> ACTION: Jacob reply to Patrick's "List of Pointer Events" ... thread
16:36:59 <trackbot> Created ACTION-60 - Reply to patrick's "list of pointer events" ... thread [on Jacob Rossi - due 2014-01-14].
16:37:03 <ArtB> ACTION: Rick reply to Patrick's "List of Pointer Events" ... thread
16:37:03 <trackbot> Created ACTION-61 - Reply to patrick's "list of pointer events" ... thread [on Rick Byers - due 2014-01-14].
16:37:06 <rbyers> ... Will get Rick and Jacob to reply to patrick
16:37:17 <rbyers> Topic: Sub-pixel coordinate granularity; filed by Rick on 17-Dec-2013;
16:37:26 <rbyers> http://lists.w3.org/Archives/Public/public-pointer-events/2013OctDec/0074.html
16:40:10 <rbyers> RB: CSS px unit as an integer is increasingly lossly - eg. scrolling by CSS px on mobile devices is quite jumpy
16:40:37 <rbyers> ... 1 CSS px is typically 2 or 3 hardware pixels on mobile devices
16:40:52 <rbyers> JR: Agree that any issues should be taken to CSS OM spec
16:41:08 <rbyers> ... believe we already do this when user zoom is applied
16:41:43 <rbyers> ... think we hit some website compatibility issues preventing doing this in all cases
16:42:03 <rbyers> DS: Any other feedback?  Important topic but doesn't directly affect pointer event spec
16:42:39 <rbyers> JR: Yes I think the pointer event spec - doesn't assume co-ordinates are integers
16:42:48 <rbyers> ... just a messy inter-spec dependency
16:43:20 <rbyers> ... we link to DOM3 events spec, but that may not document relationship with CSS OM.
16:43:41 <rbyers> RB: Any harm in us having some text that refers to CSS OM?
16:43:57 <rbyers> JR: It's been a slow-moving spec - don't want to take a hard dependency on it
16:44:11 <rbyers> DS: If the text was non-normative it would be OK
16:44:22 <rbyers> s/DS/AB
16:44:52 <rbyers> s/DS/AB/
16:45:20 <rbyers> JR: Yes, there's a normative reference to DOM3 mouse events, we could add a non-normative note that CSSOM extends it.
16:45:23 <rbyers> DS: Seems fine to me
16:45:56 <rbyers> DS: We could always change later - functionally the dependencies don't really matter in my opinion
16:46:02 <rbyers> ... we should do most pragmatic thing for now
16:46:39 <rbyers> ... can always change last minute
16:46:48 <rbyers> AB: So Jacob and Rick should propose text to address issue
16:47:11 <rbyers> RB: I think what Jacob just proposed is perfect
16:47:16 <rbyers> AB: Sounds find, any objections?
16:47:41 <rbyers> RESOLUTION: Add non-normative note that CSSOM extends mouse events
16:47:54 <ArtB> ACTION: jacob add a non-normative note that CSSOM extends mouse events
16:47:54 <trackbot> Created ACTION-62 - Add a non-normative note that cssom extends mouse events [on Jacob Rossi - due 2014-01-14].
16:47:56 <rbyers> Topic: Testing
16:47:59 <ArtB> Topic: Status of PR324 (touch-action tests)
16:48:03 <rbyers> Topic: Status of PR324 (touch-action tests)
16:48:28 <rbyers> AB: There were actions for Cathy and Rick to review
16:49:41 <rbyers> RB: I added comments back in Nov, but failed to send my summary notes to the list (found it tedious due to all the copy/past)
16:49:47 <rbyers> ... sent those comments to the list this morning
16:50:08 <rbyers> CC: Agree with Rick.  I reviewed them as well.
16:50:14 <rbyers> ... but was very tedious
16:50:46 <rbyers> AB: Do we consider PR closed then?
16:50:58 <rbyers> JR: We've seen the feedback but haven't updated the test cases yet
16:51:08 <rbyers> ... we should continue to iterate, and accept once everyone is happy
16:51:14 <rbyers> OP: Yes that makes it more clean
16:51:25 <rbyers> AB: So we'll get a notification from MS when comments are addressed
16:52:25 <rbyers> RB: I think someone (Scott) said they'd merge the tests
16:53:19 <rbyers> JR: We have a submissions branch - we'd want to accept the PR first, then let Scott do the refactoring
16:53:28 <rbyers> AB: Makes sense to me
16:53:33 <rbyers> RB: Yep, that's fine
16:53:41 <rbyers> JR: Otherwise we'll get into conflicts
16:53:44 <rbyers> SG: Makes sense to me
17:00:15 <rbyers> JR: Rick, can you help contributing your scenarios?
17:00:48 <rbyers> ... lots of discussion about the architecture of the tests
17:02:16 <scott_gonzalez> I need to join another call.
17:02:32 <Zakim> -Scott_Gonzalez
17:02:46 <rbyers> Here's an exmaple of one of my blink tests: http://www.rbyers.net/touch-action-pan.html
17:05:55 <rbyers> Also if it's helpful, here are some others:
17:05:56 <rbyers> http://www.rbyers.net/touch-action-overflow.html
17:06:03 <Zakim> -Cathy
17:06:12 <rbyers> http://www.rbyers.net/touch-action-shadow-dom.html
17:06:25 <rbyers> http://www.rbyers.net/touch-action-simple.html
17:06:28 <rbyers> Topic: implementation status
17:06:55 <rbyers> AS: We're making progress on firefox, no specific update to report
17:09:00 <Zakim> -Olli_Pettay
17:09:02 <smaug> grr
17:09:04 <smaug> skype
17:09:18 <smaug> rbyers: do you implement also your proposed touch-action-delay property?
17:10:53 <smaug> and Zakim doesn't let me to re-call
17:11:04 <rbyers> RB: We've decided in chrome to ship touch-action support ahead of my proposed touch-action-delay.
17:11:19 <rbyers> ... touch-action support is tracked here: https://code.google.com/p/chromium/issues/detail?id=241964 and over the holidays I got it essentially functionally complete
17:11:34 <rbyers> ... so it's now available in Chrome canary builds by running with the --enable-experimental-web-platform-features flag
17:12:19 <rbyers> ... there are some outstanding bugs / limitations with it, but the plan is to have those fixed in time to ship with Chrome 35 or sooner - i.e. on by default in daily builds by the end of March at the latest.
17:12:41 <rbyers> ... Then we'll revisit the touch-action-delay vs. full pointer event debate
17:13:06 <rbyers> smaug: We're continuing major re-architecture to make touch-action-delay possible but don't have anything that is useful end-to-end yet
17:13:07 <ArtB> RRSAgent, make minutes
17:13:07 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/07-pointerevents-minutes.html ArtB
17:13:29 <ArtB> RRSAgent, make minutes Public
17:13:29 <RRSAgent> I'm logging. I don't understand 'make minutes Public', ArtB.  Try /msg RRSAgent help
17:13:40 <ArtB> RRSAgent, make log Public
17:13:42 <rbyers> DS: How receptive is FireFox to pointer events work?
17:14:03 <smaug> rbyers: is it documented somewhere how touch-action and touchevents work together ?
17:14:13 <rbyers> AS: We're working with the community, will have more details next time
17:14:17 <smaug> in Chromium impl
17:15:18 <rbyers> smaug: With just touch-action (not touch-action-delay) there really isn't much interaction at all.  Details are (burried) here: https://docs.google.com/a/chromium.org/document/d/1CV2AXyrdPdGSRypAQcfGrgQVuWYi50EzTmVsMLWgRPM/edit
17:18:28 <smaug> rbyers: but do you always dispatch touch events then?
17:18:39 <smaug> or only if there are listeners?
17:18:45 <smaug> touch-action is effectively opt-in
17:25:11 <mbrubeck_> hey guys -- sorry, I'm traveling and lost track of time zones
17:25:17 <mbrubeck_> looking for somewhere I can use a phone
17:25:32 <mbrubeck_> oh, looks like you are finished.  oops
17:27:53 <rbyers> smaug: touch-action: auto doesn't change behavior at all.  Yes we always send touch events - the question is just when our 'touchcancel on scoll' behavior kicks in.
17:28:30 <Zakim> -Art_Barstow
17:28:31 <Zakim> -rbyers
17:28:32 <Zakim> -[Microsoft.a]
17:28:35 <Zakim> -Doug_Schepers
17:28:36 <Zakim> -[Microsoft]
17:28:38 <Zakim> RWC_PEWG()11:00AM has ended
17:28:38 <Zakim> Attendees were Doug_Schepers, rbyers, Cathy, Art_Barstow, [Microsoft], Olli_Pettay, Scott_Gonzalez
17:28:41 <jrossi2> jrossi2 has left #pointerevents
17:29:43 <ArtB> RRSAgent, make minutes
17:29:43 <RRSAgent> I have made the request to generate http://www.w3.org/2014/01/07-pointerevents-minutes.html ArtB
17:38:17 <rbyers> rbyers has joined #pointerevents
18:25:42 <Zakim> Zakim has left #pointerevents
18:28:02 <ArtB> rrsagent, bye
18:28:02 <RRSAgent> I see 6 open action items saved in http://www.w3.org/2014/01/07-pointerevents-actions.rdf :
18:28:02 <RRSAgent> ACTION: Jacob propose text to address bug 21749; confirm change with Francois Remy [1]
18:28:02 <RRSAgent>   recorded in http://www.w3.org/2014/01/07-pointerevents-irc#T16-26-45
18:28:02 <RRSAgent> ACTION: Jacob propose text to address bug 21951 [2]
18:28:02 <RRSAgent>   recorded in http://www.w3.org/2014/01/07-pointerevents-irc#T16-29-43
18:28:02 <RRSAgent> ACTION: Jacob propose text re "Add non-normative example section to mouse compat event mapping"; get confirmation from Patrick [3]
18:28:02 <RRSAgent>   recorded in http://www.w3.org/2014/01/07-pointerevents-irc#T16-33-16
18:28:02 <RRSAgent> ACTION: Jacob reply to Patrick's "List of Pointer Events" ... thread [4]
18:28:02 <RRSAgent>   recorded in http://www.w3.org/2014/01/07-pointerevents-irc#T16-36-59
18:28:02 <RRSAgent> ACTION: Rick reply to Patrick's "List of Pointer Events" ... thread [5]
18:28:02 <RRSAgent>   recorded in http://www.w3.org/2014/01/07-pointerevents-irc#T16-37-03
18:28:02 <RRSAgent> ACTION: jacob add a non-normative note that CSSOM extends mouse events [6]
18:28:02 <RRSAgent>   recorded in http://www.w3.org/2014/01/07-pointerevents-irc#T16-47-54
18:28:14 <ArtB> ArtB has changed the topic to: Pointer Events Working Group