14:59:19 RRSAgent has joined #pointerevents 14:59:19 logging to http://www.w3.org/2013/04/16-pointerevents-irc 14:59:54 + +1.717.578.aabb 14:59:59 Zakim, aabb is me 15:00:00 +scott_gonzalez; got it 15:00:06 zakim, who is here? 15:00:06 On the phone I see +1.519.513.aaaa, scott_gonzalez 15:00:08 On IRC I see RRSAgent, Zakim, AutomatedTester, jrossi2, scott_gonzalez, ArtB, smaug, shepazu, chaals, rbyers, sangwhan, ArtB_, slightlyoff, dfreedm, trackbot 15:00:12 zakim, aaaa is me 15:00:14 +rbyers; got it 15:00:16 +Art_Barstow 15:00:37 RRSAgent, make log public 15:00:45 ScribeNick: ArtB 15:00:51 Scribe: Art 15:00:57 Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0087.html 15:01:00 Chair: Art 15:01:11 Meeting: Pointer Events WG Voice Conference 15:01:17 RRSAgent, make minutes 15:01:17 I have made the request to generate http://www.w3.org/2013/04/16-pointerevents-minutes.html ArtB 15:01:39 RRSAgent, make log Public 15:01:58 +[IPcaller] 15:02:26 +[Microsoft] 15:02:29 Zakim, [IPcaller] is Olli_Pettay 15:02:30 +Olli_Pettay; got it 15:02:40 Zakim, nick smaug is Olli_Pettay 15:02:40 ok, smaug, I now associate you with Olli_Pettay 15:03:01 +Doug_Schepers 15:03:08 Present: Art_Barstow, Rick_Byers, Asir_Vedamuthu, Olli_Pettay, Scott_González, Doug_Schepers 15:03:27 Regrets: Cathy_Chan(until_July) 15:04:28 phone issues....calling 15:04:41 +[Microsoft.a] 15:04:53 Present+ Jacob_Rossi 15:05:07 Topic: Getting started 15:05:12 AB: I posted a draft agenda yesterday http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0087.html. 15:05:19 AB: it may make sense to move topic #2 (LC comment processing) after #3, #4 and #5. Is that OK? 15:05:40 [ Yes'es ] 15:05:43 AB: any other change requests? 15:05:52 AB: can I get a volunteer to scribe today's meeting? Scribe "cheat sheet" is http://www.w3.org/wiki/PointerEvents/Meetings#Meeting_Scribes. 15:06:34 Topic: proposal to remove requirement that pointer ID 1 is reserve for mouse 15:06:53 ScribeNick: rbyers 15:06:55 http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0072.html 15:07:03 asir has joined #pointerevents 15:07:09 Feb 26 Alex argued pointerID should be opaque http://www.w3.org/2013/02/26-pointerevents-minutes.html#item05 15:07:25 March 12 we agreed to add a non-normative note that the id is implementation specific http://www.w3.org/2013/03/12-pointerevents-minutes.html 15:07:54 AB: but we've got some people in WG that feel we should drop this requirement 15:08:09 ... Jacob, you argued it had some good use cases, right? 15:08:33 JR: Two separate issues: 1) whether it's an integer or not - that has use cases and general agreement that integer is sometimes usefull 15:08:39 ... 2) whether or not mouse is 1 15:08:44 ... no specific use cases 15:09:27 RB: I think last time we discussed, many agreed it seemed wrong, but we applied 'can we live with it' test 15:09:44 AB: Jacob, do you object to removing it? 15:10:10 JR: I agree it's not the best design, but IE may not be able to change.... 15:10:25 ... what's the right way forward? Can we mark it as at-risk in the CR spec? 15:10:42 SG: IE implementation wouldn't have to change, spec just shouldn't force that behavior 15:10:47 [lurking: Does the proposal say mouse MUST not be 1 ?] 15:11:29 JR: if we decide IE can't change, then it means there's a compat burden that other browsers might feel compelled to work with. 15:11:39 ... so then it should be in the spec 15:11:49 ... but I'm not opposed to removing this, I doubt there's much compat burden 15:12:04 ... I just don't wouldn't want to reset last call for thiswant to reset last call 15:12:21 AB: I think this could be considered a non-substantive bug fix 15:12:53 DS: we can mark it as at-risk 15:12:58 [Which is what I thought, and which would not break IE conformance, right?] 15:13:09 JR: can we just remove it as non-substative? 15:13:22 ... view it as removing a contradiction in the spec 15:13:42 DS: I think it's border line. Substantive -> would it change an implementation? 15:13:54 ... would it change someone's review of the specification? 15:14:11 ... an implementation might change, but wouldn't force them to change 15:14:19 ... is that fair? 15:14:29 JR/AB: yes, agree 15:14:35 DS: I think we could get away with a change before CR here 15:16:08 OP: Should we explicitly say that implementations should choose randomly for mouse? Eg. so Gecko doesn't implement the same pattern as IE 15:16:09 [[ 15:16:10 The pointerId selection algorithm is implementation specific. Therefore authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, values are not guaranteed to be monotonically increasing. 15:16:12 ]] 15:16:28 AB: Is this note sufficient? 15:17:44 for example, pointerType has changed from int to string....developers *will* have to change substantially when IE updates to spec 15:17:56 OP: Right now problem is that IE is the only implementation, easy for everyone to copy this 15:18:12 ... I think the spec should say that it's a random integer 15:18:50 SG: seem's this is an artificial problem, there's already an explicit way to test for mouse - seems unlikely people would rely on '1' 15:18:59 could s/implementation specific/implementation specific e.g. random/ 15:19:14 JR: spec doesn't say random, but it implies developers must treat it as random 15:19:17 DS: I agree 15:19:43 OP: I'd hope this could be codified as a requirement for implementations 15:20:24 DS: If we can get agreement on dropping, then during CR we can see if there's a real problem with hard-wiring 1 15:20:31 ... we'll learn a lot more during CR phase 15:20:40 s/DS/AB/ 15:21:52 AB: Does anyone consider dropping pointer ID 1 as a substantive change? 15:22:10 RB: I think it would be if we did what Oli suggests and require random, otherwise no 15:22:21 Hearing no-one 15:22:31 AB: Does anyone object to deleting these two sentences? 15:22:35 None 15:22:53 RESOLUTION: Remove sentences requiring mouse to have pointerID 1 as a non-substantive change 15:23:09 AB: anything else? 15:23:29 AB: Sregey felt strongly about this 15:24:19 Topic: Email from Francois - setting a cpature on offshore element 15:24:22 http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0084.html 15:24:33 AB: no response yet 15:24:48 ... should we address now, or consider as CR comment? 15:25:03 JR: inline with discussion last week, this would be a CR comment 15:25:06 ... this is brand new 15:25:11 AB: any objections? 15:25:15 none 15:25:44 SG: are we going to discuss the other part (capture pointer on event) separately? 15:26:05 DS: I thought we'd consider the entire comment as a CR comment, did you want to deal with part of it now? 15:26:11 SG: What happens if it's CR comment? 15:26:16 DS: We deal with it after CR published 15:26:31 ... changes could bring us back to last call 15:27:14 SG: One thing that seemed to come out of comments Sergey had was that allowing arbitrary pointer capture does seem kind of dangerous 15:27:27 s/DS: I thought/AB: I thought/ 15:27:36 ... for the common cases, there doesn't seem to be any disadvantage to always capture on the event target 15:27:39 s/DS: We deal/AB: We deal/ 15:28:03 Damn, sorry Art - not sure what's wrong with me today - I blame a cold... 15:28:43 JR: First I think there's a ton of interest in the topics we've slated for v2, I suspect folks will want to start that quickly 15:28:49 ... not worried about v2 being years and years down the road 15:29:07 ... Secondly, I think there's multiple ways to handle this problem - don't think it's as bad as what's being described on the list. 15:29:32 ... Do we hold back what's currently in the spec to fix the issue? I'd say it's more important to deliver the spec as it is. 15:29:59 .... We haven't in practice hit this issue, eg. the java script library included with windows 8 apps uses pointer capture heavily, and I haven't heard any feedback that it's an issue 15:30:19 ... I think it's interesting to continue a discussion on, just doesn't seem sufficiently critical to hold back the rest of the spec 15:30:28 SG: Makes sense. Does the win8 library only capture to the event target? 15:30:50 JR: No, the sometimes capture to other elements, and they don't always take capture so they can be exposed to scenarios where apps steal capture from them 15:31:09 ... one idea for dealing with this is that an event fires when someone steals capture away from you 15:31:16 SG: I'm fine waiting, considering this a CR comment 15:32:02 AB: How to track these? 15:32:16 JR: How about I open up bugzilla bugs for each change and resolve them so we have one place? 15:32:25 AB: Fine with me, so how do we make sure we come back to it? 15:32:37 JR: Just don't resolve the bug, use milestone field or something 15:32:46 ... tag it as CR as some way 15:32:58 action: jrossi to open up CR bug for pointer capture issues 15:32:58 Created ACTION-40 - Open up CR bug for pointer capture issues [on Jacob Rossi - due 2013-04-23]. 15:33:01 DS: Anything else on Francois comment? 15:33:33 ... need resolution or is bug good enough? 15:34:21 RESOLUTION: Not going to block last call on Francois issue setting capture on offshore element 15:34:52 Topic: Bug Pointer out firing before pointer cancel 15:35:00 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21686 15:35:23 https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#the-pointercancel-event 15:35:38 JR: Spec says that when you fire pointercancel, UA must fire pointerout AFTER the cancel 15:36:02 ... feedback was firing pointerout before hand would make more sense (odd to get event after cancel) 15:36:11 ... the wrote a test case and found IE10 behaves this way already 15:36:35 ... so either IE10 doesn't match or we change the spec 15:36:46 ... don't have a strong preference, don't view it as being too important 15:37:29 DS: You might want to know why the pointer was out - you'd want the cancel event first 15:37:50 SG: Nice having parity between pointerup and pointercancel 15:37:57 JR: Yeah this is the way up works 15:38:29 AB: So is there agreement that the spec needs to change? 15:38:33 JR: Leaning towards not changing this 15:38:54 SG: the way the spec is worded, pointercancel behaves exactly the same as pointerup, and code would likely to be written this way 15:39:16 ... easy to argue both ways 15:39:25 ... having the parity with up makes it simple to reason about 15:39:34 ... hard to come up with cases where one or the other will cause a problem 15:39:51 ... unless there's some important reason that MS had for going the other way 15:40:02 JR: No, I don't think there is. I think this could end up being an issue for us 15:40:44 ... could be an issue (unrelated to pointer events) - delaying click event for double-tap to zoom, and sites adding click handler on over and removing on out 15:40:51 ... could see a similar problem here 15:41:04 RB: I agree 15:41:11 AB: Any objections to a resolution to leave as is? 15:41:30 JR: Already opened bug on current IE10 behavior 15:42:05 RESOLUTION: Pointer out firing after pointer cancel is intended design, resolve spec bug as an IE bug 15:42:32 AB: Revision history / last call comments needed in spec 15:42:49 JR: rev history already there, will get last call comments via bugs - will ping you later today 15:42:56 Topic: moving pointer events spec to CR 15:43:11 AB: Does anyone object to asking the director to publish CR of PointerEvents v1? 15:43:19 ... or support? 15:43:27 No, Microsoft supports publishing CR 15:43:30 AB: Nokia supports it 15:43:46 RB: I support it 15:44:00 DS: From w3C perspective, seems like everyone was followed appropriately, I support going to CR 15:44:06 Asir: I support as well 15:44:33 That was Scott G 15:44:45 SG: I support as well 15:45:05 OP: No objections 15:45:32 RESOLUTION: Group agrees to publish CR of PointerEvents v1 15:45:41 Topic: testing 15:46:05 AB: pointer events was a topic for last weekends test the web forward in Seattle. Jacob was there. 15:46:24 ... got test assertions and test cases from some of the attendees 15:46:49 Asir: do we need to discuss CR exit criteria first? 15:46:51 AB: Yes 15:47:00 Topic: CR exit criteria 15:47:14 AB: We need to define the CR exit criteria and the time period 15:47:51 DS: I don't think we have to say anything about what we think the duration will be. 15:47:58 ... we can say what we hope 15:48:13 http://www.w3.org/TR/2011/CR-touch-events-20111215/ 15:48:23 [[ 15:48:24 AB: Can say 'we don't expect to advance to proposed recommendation before ....' 15:48:26 During the Candidate Recommendation period, the WG will complete its http://dvcs.w3.org/hg/webevents/ and two or more independent implementations must pass each test before the specification exits Candidate Recommendation. The group will also create an Implementation Report. 15:48:27 ]] 15:48:38 DS: Right, we can do that 15:49:38 ... criteria: at least 2 (preferably more) interoperable implementations 15:51:01 AB: So what I wrote in IRC above? 15:51:22 DS: Yes, that's exactly how I would have phrased it [sorry, don't have access to IRC right now] 15:51:32 [[ 15:51:34 This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 15 March 2012. All feedback is welcome. 15:51:35 ]] 15:51:35 ... could give a range - not before and targeting sometime before 15:51:51 AB: Above is from touch events 15:51:57 chaals has joined #pointerevents 15:52:01 ... 3 months 15:52:14 DS: But didn't say aiming at 15:52:17 3 months is reasonable 15:53:03 ... would be nice to set expectations in community, goal for implementations, and expectations when to start adressing issues for v2 15:53:10 ... we don't have to do this, but would be a nice touch 15:53:24 AB: I think it would be a good idea 15:53:36 AB: Any objections to re-using the same language for criteria? 15:54:10 JR: Is each implementation required to pass every test? 15:54:33 .. eg. no-one passes all of CSS 2.1 15:54:41 DS: We decide what the fundamental tests are 15:54:56 Should amend the language as 'must pass each feature' 15:54:58 JR: I think there's value in having tests that aren't considered part of the criteria 15:55:24 ... more testing is great for implementors, but we should be able to mark some as lower priority 15:55:37 DS: We could change language form 'tests' to 'features' 15:56:06 AB: Ok with me. Intent is not that each implementation must pass 100% of every test/feature, it was that each test/feature has two passing implementations 15:56:47 DS: eg. of 100 tests, 3 browsers might each pass 90 of them, with each test passing on at least 2 implementations 15:56:59 ... we're not testing compatibility, we're testing implementibility 15:57:46 JR: Eg. if there's only gecko and IE but IE still has the pointercancel/pointerout bug - seems like that shouldn't block us 15:57:59 DS: I disagree - that's not the spirit 15:58:23 JR: is a feature every normative statement in the spec? 15:58:27 DS: Yes 15:58:44 ... pragmatic reason: we need to improve interoperability 15:59:26 ... also could have political / process implications 16:00:21 JR: I think this is fine, it also means we must be deliberate about tests that we accept into the official test suite 16:00:49 DS: Yes we do need to be selective - ensuring we test normative statements, but not going beyond with too much detail beyond what we need 16:00:53 Zakim, who is noisy? 16:01:03 AB: My expectation is WG will agree on set of tests 16:01:04 rbyers, listening for 10 seconds I heard sound from the following: Art_Barstow (14%) 16:01:36 AB: Jacob, do you have enough to enter exit criteria into the document? 16:02:04 JR: Will use sentences from above, update comment document, prep CR ... yep 16:02:12 "This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 15 March 2012. All feedback is welcome." 16:02:33 AB: Can't give fixed date yet 16:02:53 AB: Agreement that we should add something like this? Second, what's the duration? 16:03:11 that is fine to include 16:03:50 RB: Doug was arguing we should include a statement about when we should target? 16:03:58 DS: Yes 16:04:30 DS: What's the earliest we think this could be passing? 16:04:37 OP: Do nightly builds count? 16:04:50 JR: For the purposes of test suites, I thought nightly builds count 16:04:59 ... think we even used IE platform preview in the past 16:05:07 DS: Yes, I think so 16:05:20 AB: I support including nightly builds, did that with web storage and touch events 16:05:39 DS: Olli, how quickly could it get into a nightly build? 16:05:46 OP: Not up to me, but something like 3 months 16:06:10 DS: Ok, no sooner than 3 months 16:06:23 ... aim for 5 months? 16:07:20 DS: Would phrase something like 'This candidate recommendation is expected to advance to Proposed Recommendation no early than 15 July 2013 and no later than 1 Oct 2013." 16:07:30 AB: I don't object but I'd personally stop after the first date. 16:08:21 DS: Maybe this isn't the time to be this agressive 16:08:43 ... why don't we stick to what we have for now, and think about it after LC transition - we could make a statement then 16:09:35 AB: So just include the one date? 16:09:45 ... any objections? 16:10:16 RESOLUTION: Use exit criteria and timeframe wording as above (from touch events) with a date of July 15th 2013 16:10:23 AB: Over time, move testing to next week? 16:10:44 ... I support us moving to GitHub, but will take comments on the list 16:10:59 Topic: testing 16:11:07 JR: Quick summary of test the web forward 16:11:28 ... pointer events group gave both html5 and css quite the competition - as a measure of interest it was pretty cool. 15 or more tests. 16:11:34 ... and a couple assertions added 16:12:01 ... we used github, but I intend to port to mercurial along with other tests 16:12:19 ... I'd prefer we stick with mercurial as our main place so we're not duplicating 16:12:38 ... did create pointer events folder in web platform github 16:13:01 AB: Ok, will start thread - don't feel strongly on test location 16:13:05 Zakim, who is noisy? 16:13:13 Topic: any other business 16:13:16 rbyers, listening for 10 seconds I heard sound from the following: Art_Barstow (54%), [Microsoft] (20%) 16:13:35 AB: Doesn't look like we'll need a call next week 16:13:49 zakim, [microsoft] is me 16:13:49 +asir; got it 16:14:23 AB: Hope CR publication will be May 7 or May 9 16:14:35 -asir 16:14:36 -Art_Barstow 16:14:37 -rbyers 16:14:38 -Olli_Pettay 16:14:38 -scott_gonzalez 16:14:39 -[Microsoft.a] 16:15:12 -Doug_Schepers 16:15:13 RWC_PEWG()11:00AM has ended 16:15:13 Attendees were +1.519.513.aaaa, +1.717.578.aabb, scott_gonzalez, rbyers, Art_Barstow, Olli_Pettay, Doug_Schepers, asir 16:16:00 RRSAgent, make minutes 16:16:00 I have made the request to generate http://www.w3.org/2013/04/16-pointerevents-minutes.html ArtB 16:16:20 rbyers - I'm happy to send the minutes to the list if you'd like 16:40:21 chaals has joined #pointerevents 17:15:00 jrossi21 has joined #pointerevents 18:53:12 Zakim has left #pointerevents