W3C home > Mailing lists > Public > public-pointer-events@w3.org > April to June 2013

Draft minutes: 4 June 2013 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 04 Jun 2013 11:58:43 -0400
Message-ID: <51AE0EB3.7020102@nokia.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
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] http://www.w3.org/

                                - DRAFT -

                    Pointer Events WG Voice Conference

04 Jun 2013


       [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


           Olli_Pettay, Rick_Byers, Asir_Vedamuthu, Scott_Gonzalez,




      * [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
    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";
    ... 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
    013AprJun/0148.html. It's good to see the interest
    ... is there anything we need to discuss today or any followup

      [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

    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

     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

    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/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%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
    ... there is also a thread titled "Is touch-action implicitly
    applied to any elements?"

      [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
    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/pointerevents

     and that's good

    AB: there a few sub-issues here ...
    ... one is, do we create our own repo or re-use the

    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

    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

     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

    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

    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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC