Draft minutes: 12 March 2013 call

The draft minutes from the March 12 voice conference are available at 
<http://www.w3.org/2013/03/12-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 19 March 2013. In the 
absence of any changes, these minutes will be considered approved.

-Thanks, Art


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

                                - DRAFT -

                    Pointer Events WG Voice Conference

12 Mar 2013


       [2] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0173.html

    See also: [3]IRC log

       [3] http://www.w3.org/2013/03/12-pointerevents-irc


           Art_Barstow, Scott_Gonzalez, Jacob_Rossi, Cathy_Chan,
           Matt_Brubeck, Asir_Vedamuthu, Rick_Byers, Peter_Beverloo

           Doug_Schepers, Sangwhan_Moon




      * [4]Topics
          1. [5]Getting started
          2. [6]Last Call comment process
          3. [7]pointerType Extensibility
          4. [8]add a rotation attribute on PointerEvent?
          5. [9]Should pointerId be an integer?
          6. [10]move examples to the front of the spec
          7. [11]Change buttons field representation?
          8. [12]conceptual overlap of new touch-action CSS
             property and pointer-events property
          9. [13]navigator.maxTouchPoints is touch-specific
         10. [14]Clarifying the spec's positioning
         11. [15]Click and contextmenu events
         12. [16]Test Assertions:
         13. [17]Any other Business
      * [18]Summary of Action Items

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

Getting started

    AB: I posted a draft agenda yesterday
    013JanMar/0173.html. Any change requests? The main subject is
    to record the group's consensus on last call comments, assuming
    we have agreement on a comment. And thanks to Jacob for
    creating the comment list.
    ... Before we look at the comments, I will talk about the LC
    comment process.

      [19] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0173.html.

Last Call comment process

    AB: I want to make sure everyone understands the LC comment
    process and the various roles and responsibilities.
    ... please note: the process requires the group "round-trip"
    all comments. This means the group is responsible for: replying
    to all comments; notifying the Commenter of the group's
    decision; asking the Commenter if they agree or not with the
    group's decision; and recording all of this communication. (See
    for example
    ... if you have a Commenter role in this work flow, please make
    sure your reply to the group is recorded either via e-mail or
    via meeting minutes.

      [20] http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-Jan-2013.)

pointerType Extensibility

    AB: based on previous discussions re pointerType extensibility
    013JanMar/0172.html and
    ... I believe we have consensus to not do anything with this
    for v1
    ... any objections to that?

      [21] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0172.html
      [22] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item04.

    [ No ]

    RESOLUTION: pointerType extensibility: no additional changes
    for  for v1

    AB: should this be added to the v.Next list?

    RB: yes, I think we should

     but I am open to debate

     think we can deal with this better when we have a concrete

    JR: agree

    SG: agree too

    <scribe> ACTION: barstow add pointerType extensibility to the
    PEv.Next feature list [recorded in

    <trackbot> Created ACTION-24 - Add pointerType extensibility to
    the PEv.Next feature list [on Arthur Barstow - due 2013-03-19].

add a rotation attribute on PointerEvent?

    AB: the question is if there a compelling reason to add? Most
    recent discussion is
    ... the only followup was from Jacob. What do people think? Is
    this something to add to the v.Next feature list?
    ... we can also defer to the list

      [24] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0171.html

    RB: we don't have immediate plans to add this

     thus I see no need to address this now

    SG: I agree we can postpone this to v.Next

    MB: doesn't IE10 support this?

    SG: yes it is but people don't build apps that rely on it

     there are some cases where it could be useful

     but I don't see a lot of interest

    AB: any objections to resolving this as v.Next potential

    <mbrubeck> Nope.

    [ None ]

    <jrossi2> No

    RESOLUTION: add a rotation attribute to PointerEvent?: group
    agrees "No", although add a related item to the v.Next feature

    <smaug> argh

    <scribe> ACTION: barstow add rotation attribute to v.Next
    feature list [recorded in

    <trackbot> Created ACTION-25 - Add rotation attribute to v.Next
    feature list [on Arthur Barstow - due 2013-03-19].

    <smaug> summer time

    <smaug> in US, but not in EU

    AV: from process perspective, do we need to add these to

    AB: no, we don't have to

     I would only add things to Bugzilla if we are going to make
    changes to the spec

    JR: if I have original comments, and Resolution, as well as
    replies, I can create the LC comment doc

     and only add issues to Bugzilla if we agree to change the

    AB: any objections to proceeding that way (i.e. only use
    Bugzilla for spec changes)?

    AV: OK

Should pointerId be an integer?

    AB: the discussion thread is
    013JanMar/0170.html.  and we talked about this on Feb 26
    ... it appears we have agreement the answer is "No", although
    we could add a non-normative note e.g. the following

      [26] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0170.html.
      [27] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item05.)


    The pointerId selection algorithm is implementation specific.
    Therefore authors cannot assume values convey any particular
    meaning other than an identifier for the pointer that is unique
    from all other active pointers. As an example, values are not
    guaranteed to be monotonically increasing.


    <jrossi2> Correct

    RB: I think, no change i.e. keep it an integer

    AB: sorry, that is indeed what I meant

     any objections to keeping pointerID as integer?

    RB: I'm ok with that provided we add that note

    AB: any objections to Jacob's proposed text?

    [ None ]

    RESOLUTION: pointerID should be integer?: group agrees to keep
    pointerID as Integer, and a related non-normative note will be
    added to the spec

move examples to the front of the spec

    AB: Alex Russell suggested "The spec should lead with examples,
    i.e., move Section 9 to where Section 2 is now."
    ... any objections?

      [28] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html

    [ None ]

    RESOLUTION: examples will be moved to the front of the spec

Change buttons field representation?

    AB: the relevant thread is
    ... do we want any changes here?

      [29] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html

    JR: there could be some benefits of adding some bitmasks

     and hence have multiple models

     but I think we should consider that for v.Next

    SG: I think sticking with Mouse Model is best

     I think Alex acknowledged that in his comment

    <rbyers> I agree with Jacob's comments - compatibility with
    MouseEvent is key to the design

    AB any objections to staying with buttons as already specified?

    [ None ]

    AB: add this to v.Next list?

     I think I'm hearing yes

    <rbyers> asir: looks like the echo is coming from your end
    again. Are you muted?

    RESOLUTION: change buttons field?: group agrees "No", although
    a related item will be added to v.Next list.

    <scribe> ACTION: barstow add buttons field to v.Next list as a
    potential new feature [recorded in

    <trackbot> Error creating new action - could not connect to
    Tracker. Please contact sysreq with the details of what

conceptual overlap of new touch-action CSS property and
pointer-events property

    AB: The question is whether or not the new touch-action CSS
    property has sufficient conceptual overlap with the
    pointer-events property to consider merging them
    ... some people (including Tab Atkins) recommended not merging
    ... does anyone think they should be merged, or do we keep them

      [31] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html.

    <rbyers> No, they're fundamentally different things in my

    AB: anyone think they should be merged?

    <asir> agree they are different

    [ No one ]

    RESOLUTION: the touch-action CSS property will not be merged
    with CSS'  pointer-event property

    <jrossi2> one controls how hit testing works, the other
    controls what you do in response to a hit test -- so very

navigator.maxTouchPoints is touch-specific

    AB: Alex raised this question
    ... what, if anything, do we want to do with this?

      [32] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html

    RB: my concern is that I think we may want to add something in
    the future

     e.g. some input device API

     might want to ask a device a question about itself

    JR: I can see a potential to add something in the future

    RB: I don't have a concrete proposal now

     need more experience

    JR: similar to pointerType issue in that we need more info

     to decide the right-thing-to-do

    RESOLUTION: maxTouchPoints is touch-specific: the group agrees
    on no spec change needed but we should add this to v.Next

    <scribe> ACTION: barstow add maxTouchPoints issue to v.Next
    list [recorded in

    <trackbot> Created ACTION-26 - Add maxTouchPoints issue to
    v.Next list [on Arthur Barstow - due 2013-03-19].

    <rbyers> asir: that echo is really annoying when talking, can
    you try using a different phone? Eg. you can call Zakim using

    SG: re the name, what about maxPointers?

    RB: it would make it harder to pinpoint a definition

    SG: agree it could depend on OS and/or hardware

    RB: we don't have this in TouchEvents

    JR: one way to use this as touch hardware detection i.e. is
    touch possible

     and then the UI could adapt accordingly

    RB: there could be overlap with pointer and hover MQs

    JR: the other UC is to know the specific number of devices

    <rbyers> asir: much better, thanks

     app could then switch on number of devices

    <asir> Zakim-mute worked

    MB: may want it for single touch hardware

     so may want to name it MaxTouchPoints

    RB: not clear if MQs is the right place or do we need a new API

     could have touch-points MQ

    <mbrubeck> I think a media query would be good.

     would be more consistent with pointer and hover MQs

    RB: but don't think this is critical to address (now)

     could move this to v.Next

     The UA needs a way to tell app it is on a touch screen

    JR: not opposed to pointer and hover

    RB: are there sites that rely on the number in practice?

    JR: mostly seeing checks for >= 0

    AB: do we want to revisit the Resolution?

    RB: question about adding a redundant API

    SG: want to avoid duplicated APIs in the future

    RB: if we could get touch-points added as a MQ

     then there would be no value in adding this API

    SG: that would be OK with me

    JR: there could be value in querying this from CSS

     there is already some content using this so we need to keep

    RB: understand but we wouldn't add it

    AB: so, despite the RESOLUTION, it appears we need some more
    time to talk about this

    JR: not sure how number of points supported is interesting from
    a view perspective

     I'm open to adding a new MQ

     not sure how that adds anymore than using maxTouchPoints

    RB: there could be some scenarios that only want to query from

     e.g. a map app and pinch/zoom

    RB: I don't object strongly but I don't like redundant APIs

    AB: so, looking at this from CanILiveWithItTest, is the
    resolution we agreed to earlier ok?

    RB: yes, I can live with it as spec'ed

    <jrossi2> Would prefer keeping as spec'ed

    SG: yeah, it's fine

    AB: so the maxTouchPoints RESOLUTION stands
    ... so, there is the CR phase which is YA opportunity to gather

Clarifying the spec's positioning

    AB: Alex wrote "The pointer event spec does not require other
    device events be supported (e.g. mouse events, touch

    events, etc.)" in

      [34] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0169.html.

    AB: what needs to be done here? Some additional non-normative

    <rbyers> One more point on the last topic: many media queries
    are already redundant with javascript APIs (eg. width, height),
    so from that perspective it's not terrible for
    navigator.maxTouchPoints to be largely redundant with the
    pointer media query.

    JR: as I said in my reply, I think this is conceptual.

     if there is a need for some non-normative text, I can add it

    AB: any other comments or objections to adding a non-normative
    statement to address this issue?

    [ None ]

    RESOLUTION: group agrees some additional non-normative text re
    spec's "positioning" should be added.

    <scribe> ACTION: Jacob propose text re the "spec's positioning"
    (see LC comment from Alex Russell) [recorded in

    <trackbot> Created ACTION-27 - Propose text re the "spec's
    positioning" (see LC comment from Alex Russell) [on Jacob Rossi
    - due 2013-03-19].

Click and contextmenu events

    <rbyers> jrossi2: probably not necessary to mute and unmute now
    - the problem was fixed by muting asir

    AB: this topic has raised by Rick in
    013JanMar/0163.html and discussed on Feb 26
    ... where are we on this issue?

      [36] http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0163.html
      [37] http://www.w3.org/2013/02/26-pointerevents-minutes.html#item06.

    <jrossi2> rbyers: cool, unmuted

    RB: Jacob agreed they are pretty much the same and should be
    treated the same

    JR: click is mentioned

    RB: some text in Section 8, non-normative

    [ JR reads relevant text  ]

    RB: yes, we should just expand the note

     e.g. add double-click too

    RESOLUTION: group agrees to add some addtional text to Section

    <scribe> ACTION: Jacob add text to Section 8 to address Rick's
    click and context menu issue [recorded in

    <trackbot> Error creating new action - could not connect to
    Tracker. Please contact sysreq with the details of what

Test Assertions:

    AB: Cathy, do you have any status on test assertions to share?

    CC: no, not yet; should have something in the next couple of

    AB: ok, thanks
    ... if you can help with this effort, please contact Cathy via
    the list

Any other Business

    AB: any new implementation status to share?

    <rbyers> Here's the bug tracking adding pointer events to

      [39] https://code.google.com/p/chromium/issues/detail?id=162757

    <rbyers> Here's the text I wrote there:

    <rbyers> Pointer events offers a number of improvements, and
    solves important problems with touch events. However adding a
    new (largely redundant) input model to the web is not something
    we can take lightly. We're actively debating whether the
    benefits justify the conceptual complexity of having a new
    input model. I welcome any comments on this bug (especially
    from site/library developers using both touch and pointer
    events today).

    [ Scott talked about some TE / PE info in jQuery ]

    RB: would like to see a blog about that

     there are two polyfills for PE now

     Microsoft has one

     and Google has one

    <jrossi2> [40]http://aka.ms/handjs

      [40] http://aka.ms/handjs

    <rbyers> Google one:

      [41] https://github.com/toolkitchen/PointerEvents

     the pollyfills are tricky, especially for performance reasons

    RB: touch-action CSS property in particular is problematic

    AB: thanks for adding those

    <scott_gonzalez> [42]https://github.com/borismus/pointer.js

      [42] https://github.com/borismus/pointer.js

    <rbyers> Not perfect (Eg. relies on a touch-action html
    attribute, instead of trying to parse CSS like hand.js)

    SG: there is another polyfill from Boris Smus

    RB: yeah, but Boris' isn't as complete so I recommend the
    Google one I mentioned above

     pointer.js is worth looking at but it isn't complete

    SG: we still have some issues we are discussing

    RB: are those design discussion done in public?

    SG: yes; a lot are in IRC; others are in pull requests

    RB: when jQuery makes important decisions, would love to hear
    about it

    SG: I can send that info to the list

    AB: on March 19 I have a conflict and will not be available. We
    will have a meeting if Doug can Chair it.
    ... regardless, please continue to use the list

    <asir> Good progress today in closing issues!!!

    AB: anything else?

    <rbyers> Yes, thank you Art!

    AB: meeting adjourned

    <asir> Thank you Art!!!

Summary of Action Items

    [NEW] ACTION: barstow add buttons field to v.Next list as a
    potential new feature [recorded in
    [NEW] ACTION: barstow add maxTouchPoints issue to v.Next list
    [recorded in
    [NEW] ACTION: barstow add pointerType extensibility to the
    PEv.Next feature list [recorded in
    [NEW] ACTION: barstow add rotation attribute to v.Next feature
    list [recorded in
    [NEW] ACTION: Jacob add text to Section 8 to address Rick's
    click and context menu issue [recorded in
    [NEW] ACTION: Jacob propose text re the "spec's positioning"
    (see LC comment from Alex Russell) [recorded in

    [End of minutes]

Received on Tuesday, 12 March 2013 16:12:43 UTC