Draft minutes: 29 January 2013 call

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.



       [1] http://www.w3.org/

                                - DRAFT -

                    Pointer Events WG Voice Conference

29 Jan 2013


       [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


           Art_Barstow, Jacob_Rossi, Scott_Gonzalez, Matt_Brubeck,
           Asir_Vedamuthu, Cathy_Chan, Doug_Schepers, Olli_Pettay



           Art, Matt


      * [4]Topics
          1. [5]Getting started
          2. [6]Making click/contextmenu use Pointer Event
          3. [7]Pointer Events Bugs
             <http://tinyurl.com/Bugs-PointerEvents>; Jacob to lead
          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
    ... 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
    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

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


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

    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

    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

    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

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

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.


      [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
    ... The question was, should we create a gesture-agnostic
    "zoom" value. I took a look at use cases for our current zoom
    ... 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
    ... 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
    ... 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
    ... I'd be willing to put off the transform calculation issue I
    brought up last week until v2 if people thought it was
    ... Does this make sense?

    <ArtB> v2 UCs and Reqs:

      [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

    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

    <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

    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

    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
    ... We can move the wiki stuff to a more specific "v2 features"
    ... 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