Pointer Events WG Voice Conference -- 29 Jan 2013

<ArtB> ScribeNick: ArtB

<scribe> Scribe: Art

Date: 29 January 2013

Getting started

AB: I submitted a Draft agenda a few days ago http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0043.html.
... one correction: agenda topic #2 is actually a thread started by Jacob (not Rick).
... without Rick, perhaps we should drop agenda items #3 since he started that discussion thread. Any objections to that?

JR: that's fair

AB: any other change requests?

AV: during AoB, I'd like to talk about going to LC

AB: so, we'll drop item #3

<scribe> ScribeNick: mbrubeck

<ArtB> Scribe: Matt

Making click/contextmenu use Pointer Event interface

AB: Jacob started this thread at http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0024.html and Rick responded.

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.
... Even if a browser did not implement mouse events, it would still want to implement "click."
... It's not specific to mouse events; it's a non-hardware-specific "activation event."
... We don't want to try to replace it; not enough traction for past efforts like the DOM Activated event
... Our implementation will even fire click events for non-primary pointers in multi-touch scenarios.
... Based on that implementation, a primary piece of feedback is that developers want to know whether a click came from mouse, pen, touch.
... and we got some similar feedback about the contextmenu event.

<smaug> (uh, skype is updating itself)

JR: The right way to fix that is to make these events send PointerEvent objects instead of MouseEvent objects.
... Rick responded and called out one expected catch.

<ArtB> … http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0040.html

JR: There's a small (negligible?) compatibility impact from this change.
... If someone specifically type-checks the object (e.g. using .constructor) then that could fail.
... I analyzed some compatibility data we have and found a very low rate of things that look like they examine MouseEvent types.
... 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.
... 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.
... Any feedback here?

DS: I think the reason DOMActivate failed. One is that the name is unwieldy. It's a terrible name. :)
... And at the time it was specified, we didn't have implementers. Nobody had committed to implement it.
... The third reason is that its relationship with "click" was too complicated and not well-specified.

<ArtB> … e.g. no fallback defined

DS: The whole series of tactical errors around that led to it not being adopted.

JR: Certainly it's possible to create a new event.
... but "click" has so much mind-share, and we're not offering new use cases for it.
... Really developers just want a little added information on top of the event we are already using.
... So the model ends up being better if we can keep the same event.
... 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.

DS: What specific information are we adding?

JR: The main thing developers want is the pointerType field. Some of the other PointerEvent fields could be useful too.

MB: An alternate solution, not as clean but avoiding the compatibility risk, is to move some fields like pointerType from PointerEvent up to MouseEvent.
... We basically have this in Gecko except the field is called mozInputSource.

JR: Yes, that's a valid alternative. This really depends on how big the compatibility risk.
... 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.

MB: And just to clarify the compatibility issue... .prototype and .constructor and "typeof" would be broken, while "instanceof" would not, right?

JR: Right.
... Any other comments, or should we wait for Rick to have a chance to respond?

<smaug> mbrubeck: "we need to have click working everywhere"

AB: So, I think we want to queue this up for next week. Everyone please follow the thread.

SG: I just want to say I agree we should be using a click event here.

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.

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.

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.

AB: If possible, can you get that information onto the mailing list?

Pointer Events Bugs <http://tinyurl.com/Bugs-PointerEvents>; Jacob to lead discussion;

AB: We have two bugs, 20217 and 20222.

<jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217

JR: I'll start with 20217: Expand touch-action property to include more of the values implemented by IE
... We had a resolution last week to add pan-x and pan-y.
... 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.
... We also discussed "zoom" last week. To recap: IE10 has some gesture-specific zoom properties that are out-of-scope for this WG.
... The question was, should we create a gesture-agnostic "zoom" value. I took a look at use cases for our current zoom values.
... The use cases I found were really about enabling specific gestures for use by content, not about disabling zoom.
... Generally speaking, when you disable panning, you also want to disable zoom (because zooming in is not useful if you can't pan around).
... So that's the one use case I found where you just want to disable zoom.
... In summary, I'm not sure "zoom" adds enough benefit to be worth adding to the spec.

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.

AB: Should we wait for feedback from Rick?

JR: Since this bug was filed by his team, I think we should.
... One approach to consider is documenting what we've said here as a resolution pending follow-up from Rick.

AB: That would be fine by me.
... Any objections?

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.

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

JR: There's been some discussion on the list about this.
... Since we don't have great consensus on how to solve the "hover menu" problem interoperably,
... 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.
... like, "Implementations MAY do something different in specific cases like :hover menus"
... and just make sure the spec is forward-compatible with changes we might make to address this in a future version.

AB: Any feedback on this proposal?

SG: I'm not aware of any issues with that.

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.

JR: Does Touch Events address the hover menu case?

MB: No, but we had similar decisions in analagous cases.

AB: Rick had another thread he started this week about mapping hover for devices that don't support it.
... any other ideas on how to proceed?
... or other comments on 20222 for today? If not, we'll hope Rick is here to provide feedback next week.

Any other business?

AB: Any news about implementation status?

MB: Things are still quiet on the Gecko front; we want to move forward but we just don't have any resources assigned yet.

Last Call

AV: We discussed going to LC before but wanted to wait on bug 20217.
... Now that issue is nearing resolution, and so is our other remaining bug 20222.
... We also talked about trying to reach Last Call in time for W3Conf
... So I want to start a conversation about when is the right time, and what preparation we need.

DS: I think if we're going to talk about Pointer Events as Last Call (which I'm in favor of)
... it might be efficient to also consider what version 2 is going to look like
... 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.
... 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.
... I'd be willing to put off the transform calculation issue I brought up last week until v2 if people thought it was appropriate.
... Does this make sense?

<ArtB> v2 UCs and Reqs: http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements#Requirements:_Pointer_Events_v.Next_Specification

JR: Yes, I think this is a pretty standard step; there's always something more you want for the future.

MB: I think this strategy served us well in Touch Events.

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.
... 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.

AB: 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).
... but it sounds like that may happen within the next week or two.

DS: This is just a "first Last Call"
... It will get attention from a lot of groups and probably generate a lot of feedback.
... It would be good if we could start documenting our intentions for v2 to head off any feedback that's already known.

<asir> Good idea to maintain a V2 list

DS: or even start the v2 branch, so we can also get people looking at the next version early.

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.
... then we can focus editorial effort on the first spec and getting it to completion.

DS: In any case, until we have actual text we want to put into v2, it's a moot point.
... If spec text does emerge that would resolve some issues that are out of scope for v1, then we can revisit the proposal.

<asir> Having any kind of data early in the process is always helpful

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.

DS: Do we have all those issues documented?

AB: We have two in Bugzilla, and the third came up in a mailing list thread.

JR: Those are the only issues I'm tracking now, and I expect to wrap them up shortly.

DS: Do we have a document in the wiki for known issues in v1 that are possibly in scope for v2?

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.
... We can move the wiki stuff to a more specific "v2 features" list.
... I'll let Rick know we are waiting on his feedback on these issues. See you all next week!

<scott_gonzalez> I followed up on the ML with notes about what jQuery currently does and what we'd like to do.

<scott_gonzalez> The check we want to use is instanceof, so the change from MouseEvent to PointerEvent would be safe for us.

<scott_gonzalez> Though we're not currently using that check, and we haven't in the past.

- DRAFT -

Pointer Events WG Voice Conference

29 Jan 2013

Attendees

Contents

Getting started

Making click/contextmenu use Pointer Event interface

Pointer Events Bugs <http://tinyurl.com/Bugs-PointerEvents>; Jacob to lead discussion;

Any other business?

Last Call

Summary of Action Items

Scribe.perl diagnostic output