15:00:57 RRSAgent has joined #pointerevents 15:00:57 logging to http://www.w3.org/2013/03/26-pointerevents-irc 15:01:02 RRSAgent, make log public 15:01:03 +[IPcaller] 15:01:08 ScribeNick: ArtB 15:01:13 Scribe: Art 15:01:18 Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0212.html 15:01:23 Chair: Art 15:01:23 Meeting: Pointer Events WG Voice Conference 15:01:24 Zakim, [IPcaller] is Olli_Pettay 15:01:24 +Olli_Pettay; got it 15:01:33 Zakim, nick smaug is Olli_Pettay 15:01:33 ok, smaug, I now associate you with Olli_Pettay 15:01:41 jrossi2 has joined #pointerevents 15:01:48 Regrets: Doug_Schepers, Cathy_Chan 15:01:53 present+ 15:02:16 +[Microsoft.a] 15:02:33 Present+ Art_Barstow, Rick_Byers, Jacob_Rossi, Olli_Pettay, Scott_Gonzalez, Asir_Vedamuthu 15:02:49 Topic: Getting started 15:02:55 AB: I posted a draft agenda a few days ago http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0212.html. The main subject is to discuss the LC comments for which we have no recorded resolution regarding what, if anything, should be done about the comments. 15:03:13 AB: any change requests? 15:03:34 JR: + extensions to Element interface 15:03:38 AB: OK 15:03:46 AB: would someone please agree to scribe with the proviso others will help fill any gaps and make corrections? 15:04:18 Scribe: Rick 15:04:24 ScribeNick: rbyers 15:04:40 Topic: Pointer event behavior across windows 15:04:45 AB: Rick Byers submitted this comment http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0180.html 15:04:53 AB: it appears an IE bug was identified but not clear if the spec needs to be changed e.g. a non-normative note about PEs across windows. 15:05:25 RB: probably outside the scope of the spec 15:05:43 JR: also discussed similar issue on Dom3 events and didn't do anything there 15:06:17 RESOLUTION: Cross-window issues are out of scope for this spec 15:06:20 Topic: 3D Pointers 15:06:21 OP: Agree, out of scope 15:06:26 AB: Bill Fisher submitted this comment http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0185.html 15:06:35 AB: we discussed this feature request before more generally in the context of the pointerType extensibility thread and agreed we need more experience before adding normative text. 15:06:59 AB: Jacob replied as such in http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0189.html. Bill's reply to Jacob, he mentions the need for a z-coordinate http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0200.html 15:07:09 asir has joined #pointerevents 15:07:20 zakim, [microsoft] is me 15:07:20 +asir; got it 15:07:46 JR: Intriguing discussion, tempting to just jump and support. But this is a tricky point in the specs lifetime - need to resist the temptation. 15:07:58 .. We're probably going to want to have a long discussion, don't think it's as simple as he describes 15:08:06 .. It will be awhile before we see implementations 15:08:12 .. If we rush this into V1 we'll probably get something wrong 15:09:19 RB: Seems like if we get extensibility right, this should be successful being implementation-specific first before being standardized 15:09:30 ... To what extent are his concerns here justified? 15:09:49 JR: LeapMotion has shown that prototypes are reasonable 15:09:51 AutomatedTester has joined #pointerevents 15:10:12 ... not beyond the realm of posibility to extend the interface with additional properties for experimentation 15:10:42 AB: Tend to agree that without more experimentation, this would end up blocking going to candidate 15:10:55 ... Feels like the right thing to do is to do it in V2 15:11:18 SG: I don't think this is necessary in v1. Better to start close to mouse (what we have now), then once we have people on pointer we can focus more on how we handle other newer types of input. 15:11:20 OP: I agree 15:11:58 RESOLUTION: 3d pointers are out of scope for Pointer Events v1, but will consider for v2 when we have more experimentation 15:12:27 Topic: Last Call comments from Yandex 15:12:37 AB: Chaals' comments are in http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0184.html. The comments are from "people at Yandex who implemented Pointer Events for our services". (BTW, Yandex joined the PEWG a few days ago.) 15:12:57 AB: Yandex has joined this working group 15:13:12 AB: the e-mail raises 3-4 different issues 15:13:23 AB: Jacob's reply to Chaals/Sergey http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0197.html and Sergey's reply http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0199.html. 15:14:56 rbyers: first issue raised is that they prefer preventDefault() over touch-action 15:15:05 rbyers: we've talked several times 15:15:19 rbyers: jacob commented on the reasoning 15:15:29 rbyers: yandex asked about other browser vendors 15:15:41 rbyers: I replied with links to a test page and G+ post about it 15:15:53 rbyers: at this point, no way we're going to change PE to use preventDefault() model 15:16:40 Agree with Rick's position 15:16:42 AB: Agree this isn't something we should be considering changing 15:16:46 OP: Agree 15:17:36 RESOLUTION: declarative-only control over browser default action (touch-action property) will remain the only mechanism for now 15:17:59 AB: "Tilt angles are very difficult to work with, why not use standard 15:17:59 spherical coordinates?" 15:18:20 Gist from Jacob's response: Tilt angles. This is based on USB standard 15:18:41 AB: Jacob responded pointing at USB documentation 15:19:18 RB: Not a significant issue, good as is 15:19:29 RESOLUTION: keep tiltX/tiltY units as defined 15:20:06 AB: next issue - "pointer capture doesn't add any value, artifact of ie6" 15:20:56 RB: is there a compelling reason why capture needs to be in v1? 15:21:45 ... JR: a substantial difference between these APIs and the capture APIs in IE5/6 is that these handle multi-touch 15:22:05 ... using the capturing phase it's tricky to track specific pointers to specific elements 15:22:49 ... could imagine slider scenario extended to mixing board with multiple sliders, each capturing a pointer 15:22:56 ... setCapture makes this easier 15:23:21 ... latest comment saying this makes it problematic for component author: 15:23:26 ... don't really buy this for 2 reasons: 15:23:38 ... 1) there are got/lost events that will let them know when this happens 15:23:56 ... 2) there are a million other scenarios where it could be effected 15:24:08 ... multi-touch is the primary place this is useful 15:24:51 RB: I'd like to run this API by our folks working on Web components 15:24:58 ... any encapsulation issues here 15:25:03 JR: Agree we want to make sure it plays well there 15:25:35 RB: sounds like worst case and we decided we wanted to think about this a little longer, it's not a big deal if we wanted to pull from v1 15:26:08 JR: main concern is that it could affect someone's review of the spec - that it would reset things in the last call process 15:26:40 AB: If we decided we didn't want to include section 9 then we would have to go back to last call 15:27:25 ACTION: rbyers to follow-up on web component implications of pointer capture 15:27:26 Created ACTION-28 - Follow-up on web component implications of pointer capture [on Rick Byers - due 2013-04-02]. 15:28:01 JR: for folks wanting a more straight forward migration from touch events, this is simpler 15:28:12 ... lets you emulate implicit capture model of touch events 15:28:15 RB: agree 15:29:04 ... but not sure how important this is in practice - often implicit capture causes problems 15:29:26 OP: why does the API take pointerId and not a PointerEvent as it's parameter? 15:29:49 JR: not necessary to pass the entire object - just need to identify the pointer 15:29:59 OP: is the ability to capture a random number a problem? 15:30:25 JR: if it's a valid pointer id then it will get captured (can setcapture outside of a pointer event_ 15:30:35 ... if it's not valid then it throws an exception 15:31:17 AB: any other feedback? If Rick doesn't come up with any large issues with leaving it defined, then we'll leave it in. 15:31:21 OP: agree 15:31:37 OP: this is kind of related to pointer lock, but only designed for mouse events 15:31:45 ... assume we'd want support for pointer events at some point 15:31:59 https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html 15:32:05 JR: pointer lock is a lot different than just capture, it also hides the cursor, gives you deltas, etc. 15:32:18 OP: yes it does more, but at some point we need to think about pointer lock for pointer events 15:32:38 JR: agree, that's probably pointerlock v2. There's nothing in PointerEvent spec preventing a 'pointersLock" 15:32:52 also, there are some sites already using pointer capture APIs I believe 15:33:02 AB: "Why should the mouse have pointerId == 1? There is no need for this, since we have a pointerType for detecting input device type, and it makes it impossible to use two mouse devices simultaneously." 15:33:16 jrossi2: If you could provide a specific example of a site using it, that might be helpful... 15:33:38 JR: we've talked about this before 15:33:46 ... generally mouse is persistent 15:34:06 ... felt it simplest to reserve a pointer id for the mouse 15:34:32 ... multi-mouse is possible with the spec, but it's not a scenario most implementers are going after 15:34:39 ... don't see this becoming an important thing 15:35:49 RB: does code special-casing 1 protect us or hurt us if we add multi-mouse in the future? 15:36:28 SG: seems strange to say write for multiple pointers for touch, but there can only ever be one mouse 15:37:05 RB: also strange to say that pointer Id is an opaque integer, don't interpret it in any way ... unless it has the value 1 15:37:29 JR: for multi-mouse we'd have to define which pointer fires mouse events 15:37:47 AB: seems like this may not be the perfect model, but meets the "I can live with it" test 15:38:31 RB: Alex Russel brought this up 15:38:57 the WG discussed on Mar 3 and Mar 12 15:40:22 RESOLUTION: supporting multi-mouse is out of scope for v1, will tackle in v2. The primary mouse having id 1 won't prevent this. 15:41:09 AB: Last comment on the thread ... 15:41:25 JR: Multi-touch handling and the convenience of having a touch list 15:42:28 RB: there's good reason to encourage more thought on the right way to do a pointer list API 15:42:37 ... has security implications (IE originally had one and it was removed) 15:42:45 AutomatedTester has joined #pointerevents 15:43:01 AB: let's add this comment to the thread 15:43:14 JR: have get pointer list API on v2 list 15:43:46 RESOLUTION: an API to return active pointers is out of scope for v1, but will be tackled in v2 15:45:14 AutomatedTester has joined #pointerevents 15:45:54 Topic: Distinguishing input from multiple users 15:46:00 AB: Sangwhan Moon submitted this comment on March 24 http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0210.html 15:46:08 AB: first, there is a bit of procedural issue here. Since the LC comment period ended March 19 and Sangwhan's input was submitted on March 24, strictly speaking we _could_ say this isn't a LC comment. 15:46:29 AB: however, I recommend against that i.e. I think we should consider Sangwhan's comment as a LC comment. 15:46:45 AB: I say this for a couple of reasons but mainly because we have what I will call a "social contract" with the Public. We should always welcome feedback at any time in the process and then on a case-by-case basis decide what, if anything, to do about the feedback. 15:47:12 AB: any comments on the process-related aspects (separately, we will talk about the technical nature of Sangwhan's comments)? 15:47:20 Agree this should be a Last Call comment 15:47:40 JR: no objections, I have one of my own... 15:47:49 RB: agree 15:48:22 JR: want a way to associate pointers with a particular device (or 'user') 15:48:41 ... eg. multiple users interacting with the same content [via multiple input devices] 15:48:50 ... one example is the Wii browser 15:49:10 ... specific proposal: add a deviceId member to PointerEvent 15:49:27 ... is the issue clear to everyone? 15:49:29 AB: I think so 15:49:58 JR: it's not clear to me that pointer events are the only type of input you want to differentiate 15:50:11 ... don't have anything wrong with the approach in principle 15:50:24 ... but probably belongs on UIEvent, not on PointerEvent. Eg. to support multiple keyboards. 15:51:19 ... Secondly, we want to make sure we're not exposing a unique identifier for users (something that persists across pages). needs to be generic, reset for each page, no guarantees that you get the same ID for each device after a navigation 15:51:28 ... prefer this would be in the scope of the UI Events spec 15:51:31 OP: Fully agree 15:52:20 AB: should we propose to WebApps working group that this get added there? 15:52:23 RB: seems reasonable 15:52:38 JR: I can reply on the thread and see what Sangwhan thinks 15:54:04 ACTION: Barstow reply to Yandex comments (Chaals) and include link to 26-Mar-2013 minutes 15:54:04 Created ACTION-29 - Reply to Yandex comments (Chaals) and include link to 26-Mar-2013 minutes [on Arthur Barstow - due 2013-04-02]. 15:54:44 action: jrossi2 to reply to Sangwhan on the list 15:54:45 Created ACTION-30 - Reply to Sangwhan on the list [on Jacob Rossi - due 2013-04-02]. 15:55:55 action: jacob to reply to 3D pointer thread 15:55:56 Created ACTION-31 - Reply to 3D pointer thread [on Jacob Rossi - due 2013-04-02]. 15:56:50 Topic: extensions to the element interface 15:57:16 JR: a glaring omission from the spec here 15:57:40 ... section 6 defines extensions to the Element interface, but they should also be on Window and Document 15:58:02 ... wish we would have caught this earlier, don't expect objections 15:58:10 ... pretty obvious that's what the model should have been 15:58:23 ... but think it's something we'd want to fix 15:58:29 sort of like a documentation issue 15:58:36 RB: agree, I was assuming that too 15:59:03 AB: consider this a bug in the IDL personally 15:59:18 OP: Definitely they should be on document and window too 15:59:54 RESOLUTION: Update spec to add all Element extensions to Document and Window as well 16:00:05 Topic: Testing: status, plans 16:00:21 AB: Matt agreed to be test facilitator, but he's not here today 16:00:28 ... Cathy has done preliminary work on assertions 16:00:31 http://www.w3.org/wiki/PointerEvents/TestAssertions 16:01:14 Topic: Any other Business 16:01:15 ... standing action for the group to review and contribute to these assertions 16:01:22 AB: does anyone have any new implementation status to share? 16:01:47 RB: no change on Google side to report this week 16:02:17 AB: Jacob, do you have last call tracking doc? 16:02:31 JR: Yes, I'll add to it for this week and will check it in 16:03:45 JR: see change for element extensions as not a substantial change, right? 16:03:51 AB: Yes, non-substantive 16:03:56 ... just a bug in the IDL 16:04:29 AB: None of the changes we've discussed so far result in substantive changes 16:04:40 ... everyone agree? 16:04:52 Yes 16:05:01 AB: We will have a call next week 16:05:22 RB: I also agree, no substantive changes 16:05:23 yes 16:05:29 no substantive changes 16:05:40 -Olli_Pettay 16:05:41 -[Microsoft.a] 16:05:41 -Art_Barstow 16:05:46 -scott_gonzalez 16:05:56 jrossi2 has left #pointerevents 16:06:10 RRSAgent, make minutes 16:06:11 I have made the request to generate http://www.w3.org/2013/03/26-pointerevents-minutes.html ArtB 16:06:21 -rbyers 16:06:33 RRSAgent, make log Public 16:07:00 RRSAgent, make minutes 16:07:00 I have made the request to generate http://www.w3.org/2013/03/26-pointerevents-minutes.html ArtB 16:09:34 RRSAgent, make log public 16:09:41 rrsagent, make minutes 16:09:41 I have made the request to generate http://www.w3.org/2013/03/26-pointerevents-minutes.html ArtB 16:11:22 disconnecting the lone participant, asir, in RWC_PEWG()11:00AM 16:11:24 RWC_PEWG()11:00AM has ended 16:11:24 Attendees were Art_Barstow, rbyers, scott_gonzalez, Olli_Pettay, asir 16:30:23 shepazu has joined #pointerevents 17:11:03 chaals1 has joined #pointerevents 17:11:13 rrsagent, make log public 17:11:39 worky ArtB 17:13:03 rrsagent, bye 17:13:03 I see 4 open action items saved in http://www.w3.org/2013/03/26-pointerevents-actions.rdf : 17:13:03 ACTION: rbyers to follow-up on web component implications of pointer capture [1] 17:13:03 recorded in http://www.w3.org/2013/03/26-pointerevents-irc#T15-27-25 17:13:03 ACTION: Barstow reply to Yandex comments (Chaals) and include link to 26-Mar-2013 minutes [2] 17:13:03 recorded in http://www.w3.org/2013/03/26-pointerevents-irc#T15-54-04 17:13:03 ACTION: jrossi2 to reply to Sangwhan on the list [3] 17:13:03 recorded in http://www.w3.org/2013/03/26-pointerevents-irc#T15-54-44 17:13:03 ACTION: jacob to reply to 3D pointer thread [4] 17:13:03 recorded in http://www.w3.org/2013/03/26-pointerevents-irc#T15-55-55 17:13:09 thanks chaals1