16:00:21 <RRSAgent> RRSAgent has joined #pointerevents
16:00:21 <RRSAgent> logging to http://www.w3.org/2013/01/29-pointerevents-irc
16:00:21 <Zakim> +[Microsoft]
16:00:32 <ArtB> RRSAgent, make log public
16:00:44 <ArtB> ScribeNick: ArtB
16:00:48 <ArtB> Scribe: Art
16:00:54 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0043.html
16:00:54 <Zakim> +scott_gonzalez
16:01:01 <ArtB> Date: 29 January 2013
16:01:10 <ArtB> Chair: Art
16:01:18 <ArtB> Meeting: Pointer Events WG Voice Conference
16:01:28 <jrossi2> jrossi2 has joined #pointerevents
16:01:40 <Zakim> +Matt_Brubeck
16:01:46 <mbrubeck> Zakim, I am Matt_Brubeck
16:01:46 <Zakim> ok, mbrubeck, I now associate you with Matt_Brubeck
16:02:01 <mbrubeck> Zakim, who is here?
16:02:01 <Zakim> On the phone I see Art_Barstow, [Microsoft], scott_gonzalez, Matt_Brubeck
16:02:04 <Zakim> On IRC I see jrossi2, RRSAgent, Zakim, mbrubeck, smaug, AutomatedTester, scott_gonzalez, ArtB, shepazu, dfreedm, trackbot
16:02:09 <ArtB> Present: Art_Barstow, Jacob_Rossi, Scott_Gonzalez, Matt_Brubeck
16:02:59 <Zakim> +[Microsoft.a]
16:03:19 <ArtB> Present+ Asir_Vedamuthu
16:03:28 <ArtB> Regrets: Rick_Byers
16:03:45 <Cathy> Cathy has joined #pointerevents
16:03:55 <ArtB> Present+ Cathy_Chan
16:04:19 <ArtB> Topic: Getting started
16:04:24 <ArtB> AB: I submitted a Draft agenda a few days ago http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0043.html.
16:04:30 <ArtB> AB: one correction: agenda topic #2 is actually a thread started by Jacob (not Rick).
16:04:40 <ArtB> AB: without Rick, perhaps we should drop agenda items #3 since he started that discussion thread. Any objections to that?
16:05:10 <ArtB> JR: that's fair
16:05:16 <ArtB> AB: any other change requests?
16:05:29 <Zakim> +??P38
16:05:42 <ArtB> AV: during AoB, I'd like to talk about going to LC
16:05:49 <Cathy> zakim, ??P38 is me
16:05:49 <Zakim> +Cathy; got it
16:05:55 <asir> asir has joined #pointerevents
16:06:00 <ArtB> AB: so, we'll drop item #3
16:06:23 <ArtB> ScribeNick: mbrubeck
16:06:28 <ArtB> Scribe: Matt
16:06:48 <mbrubeck> Topic: Making click/contextmenu use Pointer Event interface
16:06:59 <mbrubeck> AB: Jacob started this thread at http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0024.html and Rick responded.
16:07:38 <mbrubeck> JR: The basic idea is, like we talked about with compatibility mouse events, is that the click event is being carried forward into the pointer event world.
16:07:50 <mbrubeck> ... Even if a browser did not implement mouse events, it would still want to implement "click."
16:08:04 <mbrubeck> ... It's not specific to mouse events; it's a non-hardware-specific "activation event."
16:08:26 <mbrubeck> ... We don't want to try to replace it; not enough traction for past efforts like the DOM Activated event
16:08:39 <Cathy> zakim, drop me
16:08:39 <Zakim> Cathy is being disconnected
16:08:41 <Zakim> -Cathy
16:08:45 <mbrubeck> ... Our implementation will even fire click events for non-primary pointers in multi-touch scenarios.
16:08:48 <Zakim> +Cathy
16:09:07 <mbrubeck> ... Based on that implementation, a primary piece of feedback is that developers want to know whether a click came from mouse, pen, touch.
16:09:19 <mbrubeck> ... and we got some similar feedback about the contextmenu event.
16:09:21 <smaug> (uh, skype is updating itself)
16:09:33 <mbrubeck> ... The right way to fix that is to make these events send PointerEvent objects instead of MouseEvent objects.
16:09:46 <mbrubeck> ... Rick responded and called out one expected catch.
16:09:51 <ArtB> … http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0040.html
16:09:57 <mbrubeck> ... There's a small (negligible?) compatibility impact from this change.
16:10:19 <mbrubeck> ... If someone specifically type-checks the object (e.g. using .constructor) then that could fail.
16:10:22 <Zakim> +[IPcaller]
16:10:23 <Zakim> +Doug_Schepers
16:10:32 <smaug> Zakim, [IPcaller] is Olli_Pettay
16:10:32 <Zakim> +Olli_Pettay; got it
16:10:38 <mbrubeck> ... I analyzed some compatibility data we have and found a very low rate of things that look like they examine MouseEvent types.
16:10:41 <smaug> Zakim, nick smaug is Olli_Pettay
16:10:41 <Zakim> ok, smaug, I now associate you with Olli_Pettay
16:10:42 <ArtB> Present+ Doug_Schepers, Olli_Pettay
16:10:56 <mbrubeck> ... So I can say with *reasonable* confidence that this change would not have tremendous fallout, and I think it would be a big win for developers.
16:11:26 <mbrubeck> ... I want feedback from this WG, but I don't think the PE spec is the right place to make this change.  We'd want it in DOM Events and/or HTML, where the "click" event is defined.
16:12:18 <mbrubeck> ... Any feedback here?
16:13:12 <mbrubeck> DS: I think the reason DOMActivate failed.  One is that the name is unwieldy.  It's a terrible name. :)
16:13:31 <mbrubeck> ... And at the time it was specified, we didn't have implementers.  Nobody had committed to implement it.
16:13:56 <mbrubeck> ... The third reason is that its relationship with "click" was too complicated and not well-specified.
16:14:16 <ArtB> … e.g. no fallback defined
16:14:24 <mbrubeck> ... The whole series of tactical errors around that led to it not being adopted.
16:14:37 <mbrubeck> Zakim, who is making noise?
16:14:47 <Zakim> mbrubeck, listening for 10 seconds I heard sound from the following: asir (17%), [Microsoft.a] (38%), Doug_Schepers (44%)
16:14:51 <sstewart6> sstewart6 has joined #pointerevents
16:15:02 <mbrubeck> JR: Certainly it's possible to create a new event.
16:15:19 <mbrubeck> ... but "click" has so much mind-share, and we're not offering new use cases for it.
16:15:37 <mbrubeck> ... Really developers just want a little added information on top of the event we are already using.
16:15:45 <mbrubeck> ... So the model ends up being better if we can keep the same event.
16:16:32 <mbrubeck> ... If we were going to fire it in different scenarios that would be one thing, but we are just adding new properties and firing it at the same time.
16:16:38 <mbrubeck> DS: What specific information are we adding?
16:16:58 <mbrubeck> JR: The main thing developers want is the pointerType field.  Some of the other PointerEvent fields could be useful too.
16:19:19 <mbrubeck> MB: An alternate solution, not as clean but avoiding the compatibility risk, is to move some fields like pointerType from PointerEvent up to MouseEvent.
16:19:36 <mbrubeck> ... We basically have this in Gecko except the field is called mozInputSource.
16:19:52 <mbrubeck> JR: Yes, that's a valid alternative. This really depends on how big the compatibility risk.
16:20:21 <mbrubeck> ... Based on my data, I really found very few things that would be broken by this.  Most of the ones flagged in my analysis turned out to be false positives on closer look.
16:20:49 <mbrubeck> MB: And just to clarify the compatibility issue... .prototype and .constructor and "typeof" would be broken, while "instanceof" would not, right?
16:20:51 <mbrubeck> JR: Right.
16:21:04 <mbrubeck> JR: Any other comments, or should we wait for Rick to have a chance to respond?
16:21:40 <smaug> mbrubeck: "we need to have click working everywhere"
16:22:19 <mbrubeck> AB: So, I think we want to queue this up for next week. Everyone please follow the thread.
16:22:53 <mbrubeck> SG: I just want to say I agree we should be using a click event here.
16:23:22 <mbrubeck> JR: Scott, I didn't see anything specific in jQuery that's affected here, but I'm just curious if you have any gut feeling about changing an object type like this.
16:24:10 <mbrubeck> SG: It won't break jQuery because we look at the name (event.type), not the object's constructor.  We once used typeof or instanceof checks; I should try to find why we stopped doing that.
16:24:37 <mbrubeck> JR: That would be very good data to have.  We have gotten burned before by older versions of jQuery still in the wild.  If those exist but aren't showing up in my data it would be good to know.
16:24:55 <mbrubeck> AB: If possible, can you get that information onto the mailing list?
16:25:40 <mbrubeck> Topic: Pointer Events Bugs <http://tinyurl.com/Bugs-PointerEvents>; Jacob to  lead discussion;
16:26:16 <mbrubeck> AB: We have two bugs, 20217 and 20222.
16:26:18 <jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217
16:26:38 <mbrubeck> JR: I'll start with 20217: Expand touch-action property to include more of the values implemented by IE
16:26:47 <mbrubeck> ... We had a resolution last week to add pan-x and pan-y.
16:27:25 <mbrubeck> ... I haven't added this to the spec yet; I realized I had to tweak our spec a bit to handle the case where you have e.g. pan-x on a child and pan-y on its parent.
16:27:50 <mbrubeck> ... We also discussed "zoom" last week.  To recap: IE10 has some gesture-specific zoom properties that are out-of-scope for this WG.
16:28:10 <mbrubeck> ... The question was, should we create a gesture-agnostic "zoom" value.  I took a look at use cases for our current zoom values.
16:28:25 <mbrubeck> ... The use cases I found were really about enabling specific gestures for use by content, not about disabling zoom.
16:28:46 <mbrubeck> ... Generally speaking, when you disable panning, you also want to disable zoom (because zooming in is not useful if you can't pan around).
16:29:06 <mbrubeck> ... So that's the one use case I found where you just want to disable zoom.
16:29:17 <mbrubeck> ... In summary, I'm not sure "zoom" adds enough benefit to be worth adding to the spec.
16:30:16 <mbrubeck> MB: Since CSS Device Adaptation (the @viewport / <meta name=viewport> rule already gives a way to disable zoom at the document level, I agree we don't have a strong need to tackle it here.
16:30:26 <mbrubeck> AB: Should we wait for feedback from Rick?
16:30:34 <mbrubeck> JR: Since this bug was filed by his team, I think we should.
16:31:27 <mbrubeck> JR: One approach to consider is documenting what we've said here as a resolution pending follow-up from Rick.
16:31:33 <mbrubeck> AB: That would be fine by me.
16:31:39 <mbrubeck> ... Any objections?
16:32:38 <mbrubeck> RESOLUTION: Pending feedback from Rick Byers, the group tentatively concludes that there is not a sufficient use case for adding a "zoom" value for the touch-action property.
16:33:11 <mbrubeck> AB: The other bug is https://www.w3.org/Bugs/Public/show_bug.cgi?id=20222 - Pointer events explicitly disallow compatbility with hover menus used by many web sites
16:33:17 <mbrubeck> JR: There's been some discussion on the list about this.
16:33:35 <mbrubeck> ... Since we don't have great consensus on how to solve the "hover menu" problem interoperably,
16:33:58 <mbrubeck> ... for this version of the spec it might just be appropriate for us to put some leeway into the compatibility mouse events section regarding mouseover/mouseout events.
16:34:23 <mbrubeck> ... like, "Implementations MAY do something different in specific cases like :hover menus"
16:34:39 <mbrubeck> ... and just make sure the spec is forward-compatible with changes we might make to address this in a future version.
16:34:50 <mbrubeck> AB: Any feedback on this proposal?
16:35:09 <mbrubeck> SG: I'm not aware of any issues with that.
16:36:12 <mbrubeck> MB: In Touch Events when we tried to leave things implementation-defined for compatibility with future changes, we ended up locked into specific behavior by content that targeted existing user agents.
16:37:18 <mbrubeck> JR: Does Touch Events address the hover menu case?
16:37:31 <mbrubeck> MB: No, but we had similar decisions in analagous cases.
16:38:01 <mbrubeck> AB: Rick had another thread he started this week about mapping hover for devices that don't support it.
16:38:42 <mbrubeck> ... any other ideas on how to proceed?
16:39:04 <mbrubeck> ... or other comments on 20222 for today?  If not, we'll hope Rick is here to provide feedback next week.
16:39:09 <mbrubeck> Topic: Any other business?
16:39:30 <mbrubeck> AB: Any news about implementation status?
16:40:16 <asir> q+
16:40:28 <mbrubeck> MB: Things are still quiet on the Gecko front; we want to move forward but we just don't have any resources assigned yet.
16:40:35 <shepazu> q+
16:41:47 <mbrubeck> Topic: Last Call
16:42:15 <mbrubeck> AV: We discussed going to LC before but wanted to wait on bug 20217.
16:42:27 <mbrubeck> ... Now that issue is nearing resolution, and so is our other remaining bug 20222.
16:42:39 <mbrubeck> ... We also talked about trying to reach Last Call in time for W3Conf
16:42:55 <mbrubeck> ... So I want to start a conversation about when is the right time, and what preparation we need.
16:43:44 <mbrubeck> q- asir
16:43:47 <mbrubeck> q- shepazu
16:44:10 <mbrubeck> DS: I think if we're going to talk about Pointer Events as Last Call (which I'm in favor of)
16:44:21 <mbrubeck> ... it might be efficient to also consider what version 2 is going to look like
16:44:40 <mbrubeck> ... so we can have a concrete plan to move forward immediately with a version 2, and we can figure out which issues we can put off for v2.
16:45:03 <mbrubeck> ... For example, some of the issues Rick and I have brought up might be fine to address in a v2, if we start work on v2 immediately.
16:45:29 <mbrubeck> ... I'd be willing to put off the transform calculation issue I brought up last week until v2 if people thought it was appropriate.
16:45:42 <mbrubeck> ... Does this make sense?
16:46:37 <ArtB> v2 UCs and Reqs: http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification
16:46:49 <mbrubeck> JR: Yes, I think this is a pretty standard step; there's always something more you want for the future.
16:46:59 <mbrubeck> MB: I think this strategy served us well in Touch Events.
16:47:20 <mbrubeck> DS: I think a key part of the Touch Events v2 strategy is that we were talking about additive features for v2, but not fundamental changes.
16:47:50 <mbrubeck> ... We've been working on this spec for just four months.  It would be impressive and a good signal to go to Last Call now.
16:48:35 <mbrubeck> SG: I think it's fine to go ahead... ideally I'd like consensus on the three items still under discussion (hover, touch-action, and click/contextmenu).
16:48:43 <mbrubeck> ... but it sounds like that may happen within the next week or two.
16:49:38 <mbrubeck> Zakim, who is talking?
16:49:48 <Zakim> mbrubeck, listening for 10 seconds I heard sound from the following: [Microsoft.a] (70%), Doug_Schepers (69%)
16:49:57 <ArtB> s/SG: I think it's fine/AB: I think it's fine/
16:50:07 <mbrubeck> DS: This is just a "first Last Call"
16:50:22 <mbrubeck> ... It will get attention from a lot of groups and probably generate a lot of feedback.
16:50:39 <mbrubeck> ... It would be good if we could start documenting our intentions for v2 to head off any feedback that's already known.
16:50:42 <asir> Good idea to maintain a V2 list
16:50:54 <mbrubeck> ... or even start the v2 branch, so we can also get people looking at the next version early.
16:51:35 <mbrubeck> JR: I'm not crazy about having two concurrent specs at once, but I like how I've seen it done in the past with a list of ideas on a wiki.
16:51:48 <mbrubeck> ... then we can focus editorial effort on the first spec and getting it to completion.
16:52:26 <mbrubeck> DS: In any case, until we have actual text we want to put into v2, it's a moot point.
16:52:48 <mbrubeck> ... If spec text does emerge that would resolve some issues that are out of scope for v1, then we can revisit the proposal.
16:54:20 <asir> Having any kind of data early in the process is always helpful
16:56:33 <mbrubeck> AB: I think we need to get closure on the three open items mentioned earlier; I can see us being there in the next two weeks.
16:57:00 <mbrubeck> DS: Do we have all those issues documented?
16:57:13 <mbrubeck> AB: We have two in Bugzilla, and the third came up in a mailing list thread.
16:57:25 <mbrubeck> JR: Those are the only issues I'm tracking now, and I expect to wrap them up shortly.
16:58:00 <mbrubeck> DS: Do we have a document in the wiki for known issues in v1 that are possibly in scope for v2?
16:58:36 <mbrubeck> AB: We do have some relevant stuff in the wiki on the Use Cases and Requirements page, and in Bugzilla we can mark bugs for v.next.
16:58:45 <mbrubeck> ... We can move the wiki stuff to a more specific "v2 features" list.
16:59:50 <mbrubeck> AB: I'll let Rick know we are waiting on his feedback on these issues.  See you all next week!
16:59:53 <Zakim> -Olli_Pettay
16:59:54 <Zakim> -[Microsoft.a]
16:59:54 <Zakim> -asir
16:59:55 <Zakim> -Doug_Schepers
16:59:56 <Zakim> -Cathy
17:00:00 <Zakim> -Art_Barstow
17:00:00 <Zakim> -scott_gonzalez
17:00:12 <Zakim> -Matt_Brubeck
17:00:14 <Zakim> RWC_PEWG()11:00AM has ended
17:00:14 <Zakim> Attendees were Art_Barstow, scott_gonzalez, Matt_Brubeck, Cathy, Doug_Schepers, Olli_Pettay, asir
17:00:20 <jrossi2> jrossi2 has left #pointerevents
17:50:27 <scott_gonzalez> I followed up on the ML with notes about what jQuery currently does and what we'd like to do.
17:50:46 <scott_gonzalez> The check we want to use is instanceof, so the change from MouseEvent to PointerEvent would be safe for us.
17:50:55 <scott_gonzalez> Though we're not currently using that check, and we haven't in the past.
17:51:21 <ArtB> RRSAgent, make minutes
17:51:21 <RRSAgent> I have made the request to generate http://www.w3.org/2013/01/29-pointerevents-minutes.html ArtB
17:51:26 <ArtB> zakim, bye
17:51:26 <Zakim> Zakim has left #pointerevents
17:58:16 <ArtB> thanks scott_gonzalez!
17:58:19 <ArtB> rrsagent, bye
17:58:19 <RRSAgent> I see no action items