Draft minutes: 4 June 2013 call

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

-Thanks, ArtB

    [1]W3C

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

                                - DRAFT -

                    Pointer Events WG Voice Conference

04 Jun 2013

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2013/06/04-pointerevents-irc

Attendees

    Present
           Olli_Pettay, Rick_Byers, Asir_Vedamuthu, Scott_Gonzalez,
           Art_Barstow

    Regrets
    Chair
           Art

    Scribe
           Art

Contents

      * [4]Topics
          1. [5]Tweak agenda
          2. [6]Bug 21951
          3. [7]Answers to questions in new points.js polyfill
          4. [8]An update on the Chrome team's stance on
             implementing pointer events in Chrome
          5. [9]Justification for the touch-action processing model
          6. [10]Testing: status and plans;
          7. [11]Any other Business
      * [12]Summary of Action Items
      __________________________________________________________

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

Tweak agenda

    AB: I posted a draft agenda last Friday
    [13]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013AprJun/0164.html. Any change requests?
    ... would someone please scribe today's call? I think most of
    the topics are going to be relatively quick.

      [13] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0164.html.

Bug 21951

    AB: Bug 21951 is labeled "CR" and titled "pointermove
    dispatching when button state changes";
    [14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21951
    ... based on the text of the bug, it appears this will require
    a short clarification so probably nothing we need to discus but
    wanted to verify that.

      [14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21951

    RB: yes, I think it is just a minor clarification

    … that Jacob can handle

    AV: yes, agree it is a clarification

Answers to questions in new points.js polyfill

    AB: we have a thread about points.js and some other related
    libs and polyfills
    [15]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013AprJun/0148.html. It's good to see the interest
    ... is there anything we need to discuss today or any followup
    actions?

      [15] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0148.html.

    RB: I think I owe Rich a reply

    … we had a good discussion re tradeoffs

    … I think we have consensus on how to tradeoff performance on
    in/out semantics

    … preventDefault will be tricky, though

    … I need to think and experiment on that

    … I've had some other discussions about how we can test this

    … and trying to have one polyfill we can recommend

    … we should have design discussions on the list

    … I think implementers are ready to start hacking on this

    AV: yes, need to continue discussions

    … not sure if there are any issues that need WG attention

    … I don't think so

    RB: agree no WG attention needed

    … we need to get a high fidelity polyfilll

    … but I don't think we need any spec changes

    AV: ok, good; I haven't seen any issues that require spec
    changes

    RB: we could add some non-normative notes to the spec

    … it is good for the group to participate in the tradeoffs

    … and we should continue those on the list

    SG: jQuery is working on a polyfill

    … we'd rather not have to do so

    … but something is needed e.g. old IE

    … we have been working with MS Open Tech

    <smaug> (it can't be really polyfill, given that old IEs don't
    even have DOM events)

    … of all the events to polyfill, this is one of the hardest

    … hope we don't get random inconsistencies

    RB: shouldn't need jQuery specific parts for the polyfill

    SG: would prefer to just recommend something else

    … (and not create our own)

    … If we write our own, it will be jQuery specific

    RB: may be possible to work with other polyfills

    … e.g. Polymer

    … the Polymer pollyfill is separable

    … not aware of any technical issues why it couldn't support old
    IE

    … I'm sure they would appreciate help, if it doesn't create any
    perf issues

    … I could talke to Daniel Freedman

    SG: we've talked to him

    … the discussion kinda' died

    RB: I can help here, talking to Daniel

    … tough to invest when testing is hard

    AV: Scott, how did it go when you talked to MS Open Tech people

    SG: the conclusion was to create jQuery specific

    … ? hand.js ?

    AV: I can followup too

    <asir> You got the name right

    RB: is there a good addEventListener for old IE?

    SG: I'm not aware of any

    … not aware of a good polyfill for addEvListener for old IE

    AV: what version is "old IE"

    SG: jQuery UI is IE 7

    RB: so that could add significant complexity to polymer to go
    way back with IE

    … wondering about how far back the polyfills need to go

    SG: want to eventually stop using mouse events completely

    RB: in the short term, there will be some tradeoffs

    … going to be hard to polyfill everything and get good
    performance

    SG: two sides: people trying to use PE directly; people that
    are still using mouse events

    … want to get people to stop writing to mouse events

    RB: polyfill could have a switch re use touch events or not

    SG: things like preventDefault and touch-action will be tricky

    RB: ok, I'll reach out to the Polymer guys

    … worst case is we must have a separate IE6 polyfill

    … if we need that, we should work with MS Open Tech

    AV: yes, agree

An update on the Chrome team's stance on implementing pointer events
in Chrome

    AB: Rick provided an update re Chrome's PE implementation

    [16]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013AprJun/0155.html

      [16] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0155.html

    AB: there is also the video Rick and Boris Smus gave at G-IO
    <[17]http://www.youtube.com/watch?v=DujfpXOKUp8>.

      [17] http://www.youtube.com/watch?v=DujfpXOKUp8%3E.

    RB: we will need touch-action or something like

    … it is probably the hardest part of PE

    … want to get it working with TouchEvents (TE)

    … would make polyfills easier

    … I have a design doc for Chrome

    … ATM, I see this as experimental

    … May need a new property for compatibility with TE

    … I landed one CL and another is in progress (touch-action)

    … I think we have a couple of months ahead

    … before we can turn this on by default

    … I talked to Matt about our design and he thinks it is
    reasonable and applicable for FireFox

    … I reached out to Safari people and have to followup with them

    … Talking to Scott at MS Open Tech

    … Slow progress but it's moving forward

Justification for the touch-action processing model

    AB: this topic has a couple of threads, one is
    [18]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013AprJun/0163.html.
    ... there is also a thread titled "Is touch-action implicitly
    applied to any elements?"
    [19]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013AprJun/0156.html

      [18] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0163.html.
      [19] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0156.html

    <rbyers> By the way, to follow Chrome's touch-action support,
    follow crbug.com/241964

    AB: do we discuss now or keep discussions on the list?

    RB: I think using the list is fine

    … I've been getting Qs and I'm passing them on to the list

    AV: I think Jacob replied

    RB: he did and then I had a followup

    … I'm not arguing for a change but more trying to understand
    the "Whys" of the processing model

    … If/when I get a Q like "why is this so different than
    everything else?", I'd like to have some background and context
    to reply

    <rbyers> ... In particular, making sure my reasons for why I
    like the design as it is are consistent with the original
    design goals...

    AB: please continue the discussion on the list [Art notes Jacob
    wasn't on the call]

Testing: status and plans;

    AB: yesterday, Matt proposed a submission and approval process
    [20]http://lists.w3.org/Archives/Public/public-pointer-events/2
    013AprJun/0167.html and there has been quit

      [20] http://lists.w3.org/Archives/Public/public-pointer-events/2013AprJun/0167.html

    … quite a bit of followup on the list

    AB: he also indicated he is willing to move tests from hg into
    the GitHub PE directory
    [21]https://github.com/w3c/web-platform-tests/tree/master/point
    erevents

      [21] https://github.com/w3c/web-platform-tests/tree/master/pointerevents

    … and that's good

    AB: there a few sub-issues here ...
    ... one is, do we create our own repo or re-use the
    .../w3c/web-platform-tests/?

    SG: my comments were more about W3C policy

    … I think we should just follow the W3C policy

    … my comments were those driving W3C testing effort

    AB: ok, thanks for that clarification
    ... another is how to manage the "notification hell"

    … and since, Tobie replied and is gathering requirements on how
    to address that

    AB: we definitely need a solution to that issue

    AV: do we need a separate mailing list for testing?

    AB: good Q

    … my feel now is not yet

    AV: I would expect the set of tests to not be as large as other
    groups

    AB: I agree with your expectation
    ... any comments on Matt's proposal?

    AV: I want to thank Matt!

    … Matt asked about using the list to signal reviews

    … I like the idea to make that email mandatory

    … Re fixing/updating tests, how is that done?

    … I would expect a PR to be made

    … just like a submission

    OP: yes, agree

    AV: so need to be clear that test updates need to go through
    the same process

    … there front page is missing some information

    … e.g. copyrights, obligations, etc.

    AB: agree the update process should use the same mechanics as
    submissions

    … and if there is some missing documentation in the home page,
    then yes, we need to fix that

    … if have general OWP questions, issues, feedback, send to
    public-infr-test

    AV: I want to talk to my team about Matt's proposal

    AB: ok, sounds good

    AV: I think we all need to make a commitment to review the
    tests

    AB: yes, I definitely agree with that

    … and it's up to us to define the review and approval process

    AV: Matt suggested #2 be mandatory i.e. to notify the group of
    all submissions and ask for reviews

    AB: I agree we should use the list for explicit "call for
    reviews" of test cases
    ... anything else on testing for today?
    ... Scott, did you volunteer to help Matt manage the PE tests?

    SG: sure

    AB: OK, thanks Scott

Any other Business

    AB: any new Implementation status to share?

    OP: I need to talk to romaxa to get implementation status

    RB: Olli - if romaxa has feedback on my design doc, that would
    be great

    … could make sense for FF to implement touch-action first,
    independent of PE spec

    … that could facilitate a pollyfill experience

    AB: anything else for today?
    ... so we'll have the next call when we have sufficient topics

    … If you see a need for a call let me know

    AB: meeting adjourned

Summary of Action Items

    [End of minutes]

Received on Tuesday, 4 June 2013 15:59:14 UTC