See also: IRC log
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 29 January 2013
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
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?
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.
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.
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.
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/SG: I think it's fine/AB: I think it's fine/ Found ScribeNick: ArtB Found Scribe: Art Found ScribeNick: mbrubeck Found Scribe: Matt Scribes: Art, Matt ScribeNicks: ArtB, mbrubeck Default Present: Art_Barstow, scott_gonzalez, Matt_Brubeck, Cathy, Doug_Schepers, Olli_Pettay, asir Present: Art_Barstow Jacob_Rossi Scott_Gonzalez Matt_Brubeck Asir_Vedamuthu Cathy_Chan Doug_Schepers Olli_Pettay Regrets: Rick_Byers Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0043.html Found Date: 29 Jan 2013 Guessing minutes URL: http://www.w3.org/2013/01/29-pointerevents-minutes.html People with action items:[End of scribe.perl diagnostic output]