- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 29 Jan 2013 12:56:55 -0500
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the January 29 voice conference are available at
<http://www.w3.org/2013/01/29-pointerevents-minutes.html> and copied below.
WG Members - if you have any comments, corrections, etc., please send
them to the public-pointer-events mail list before 05 February 2013. In
the absence of any changes, these minutes will be considered approved.
Thanks to Matt for Scribing this meeting.
-AB
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Pointer Events WG Voice Conference
29 Jan 2013
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0043.html
See also: [3]IRC log
[3] http://www.w3.org/2013/01/29-pointerevents-irc
Attendees
Present
Art_Barstow, Jacob_Rossi, Scott_Gonzalez, Matt_Brubeck,
Asir_Vedamuthu, Cathy_Chan, Doug_Schepers, Olli_Pettay
Regrets
Rick_Byers
Chair
Art
Scribe
Art, Matt
Contents
* [4]Topics
1. [5]Getting started
2. [6]Making click/contextmenu use Pointer Event
interface
3. [7]Pointer Events Bugs
<http://tinyurl.com/Bugs-PointerEvents>; Jacob to lead
discussion;
4. [8]Any other business?
5. [9]Last Call
* [10]Summary of Action Items
__________________________________________________________
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 29 January 2013
Getting started
AB: I submitted a Draft agenda a few days ago
[11]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/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?
[11] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0043.html.
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
[12]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0024.html and Rick responded.
[12] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0024.html
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> …
[13]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0040.html
[13] 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 <[14]http://tinyurl.com/Bugs-PointerEvents>;
Jacob to lead discussion;
[14] http://tinyurl.com/Bugs-PointerEvents%3E;
AB: We have two bugs, 20217 and 20222.
<jrossi2>
[15]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217
[15] 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
[16]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] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20222
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:
[17]http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirement
s#Requirements:_Pointer_Events_v.Next_Specification
[17] 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.
Summary of Action Items
[End of minutes]
Received on Tuesday, 29 January 2013 17:57:24 UTC