Draft minutes: 2014 April 15 call

The draft minutes from the April 15 voice conference are available at 
the following and copied below:


WG Members - if you have any comments, corrections, etc., please send 
them to the public-pointer-events mail list before April 22. 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

15 Apr 2014


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

    See also: [3]IRC log

       [3] http://www.w3.org/2014/04/15-pointerevents-irc


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

           Sangwhan_Moon, Patrick_Lauke




      * [4]Topics
          1. [5]Tweak agenda
          2. [6]Bug 24971 - Should got/lostpointercapture be
             dispatched asynchronously or synchronously
          3. [7]Bug 25147 - What should happen when
             element.setPointerCapture is called while the pointer
             is already being captured?
          4. [8]Bug 21749 - Setting a capture on an offshore
          5. [9]Feedback on pointer events from Anne
          6. [10]Testing: status of PR324
          7. [11]CR implementation updates
          8. [12]Polymer Pointer Events PSA and Impact of pointer
             capture on hit testing requirements
          9. [13]AoB
      * [14]Summary of Action Items

    <smaug> just a sec

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

Tweak agenda

    AB: since I submitted the draft agenda yesterday
    014AprJun/0004.html, Jacob did quite a bit of work on related
    actions so we need to reflect that.
    ... in particular, per Jacob's request, we'll skip Bug 24923
    and take bug 24971 first and then 21749.
    ... Patrick's regrets means will skip #6 Editorial bugs and
    assume Patrick and Jacob will work out mutually agreeable
    solutions we can all review.
    ... how about hit testing?

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

    RB: yes, as well as the polymer change

    AB: ok; any other changes?

Bug 24971 - Should got/lostpointercapture be dispatched
asynchronously or synchronously

    AB: yesterday Jacob completed Action-99 re Bug
    Jacob by submitting comment #5
    ... This bug was originally submitted by Olli and discussed
    during our last call

      [16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971.
      [17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971#c5.
      [18] http://www.w3.org/2014/03/25-pointerevents-minutes.html#item03

    JR: my c5 matches IE impl

     this gets rid of the ambiguous async nature

     and builds process into firing events

     calling set/release capture sets pending capture

     this algo solves another bug 25147

    RB: does IE defer this indefinitely?

    JR: yes

    RB: seems reasonable; seems simpler

    [ Rick and Jacob discuss various scenarios of the event stack 

    JR: when queue a task, goes on end

    RB: I trust what IE shipped here is ok

     so we need to spec what they implemented

     before we decide wording, we need to understand what IE does

    JR: we don't do what Olli described

    OP: that feels a bit odd

     could be timing issues with multiple pointer events

    JR: we could add an additional step

    RB: seems reasonable; gives better performance

    OP: need to know when to do the hit testing

     for consistency pe's should always go to the capture node

    JR: I'll need to think how to spec this

     re the specific steps for these scenarios

    AB: what's the next step?

    JR: I can update the spec based on today's discussion

    <scribe> ACTION: jacob submit a changeset for bug 24971 based
    on 2014-Apr-15 discussions [recorded in

    <trackbot> Created ACTION-102 - Submit a changeset for bug
    24971 based on 2014-apr-15 discussions [on Jacob Rossi - due

Bug 25147 - What should happen when element.setPointerCapture is
called while the pointer is already being captured?

    AB: Olli submitted this bug on March 25
    Yesterday, Jacob suggested this bug could be addressed via his
    proposal in comment #5 of Bug 24971

      [20] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25147.
      [21] https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971#c5

    JR: I think the reso to 24971 solves this. Correct Olli?

    OP: yes

    RESOLUTION: bug 25147 closed via agreement to 24971

Bug 21749 - Setting a capture on an offshore element

    AB: yesterday Jacob completed action-94 for this bug by making
    an explicit proposal in comment #5
    [22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749#c5 and
    he replied to Francois
    014AprJun/0010.html. Other than waiting for Francois' feedback,
    is there anything else on this?

      [22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749#c5
      [23] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0010.html.

    JR: my proposal is what we discussed on a previous call

    AB: Jacob if you don't get any feedback from Francois in a few
    days, perhaps you should go ahead and implement your proposal.

    JR: ok

Feedback on pointer events from Anne

    AB: Jacob followed up yesterday
    014AprJun/0011.html and Anne replied
    ... it might be helpful to look at each response

      [24] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0011.html
      [25] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html.

     not sure what we want to do

    JR: don't think this group should need to define mouse events

    AB: I agree

    RB: if we had a world with no mouse events and only pe's, then
    we might have to spec things differently

    JR: well, but we have to deal with mouse events

     similar to having to deal with touch events

    RB: we could define default behavior for pointerdown

    JR: there are lots of difference though

     and I don't think we should do that

    RB: yes, I understand

    JR: we had similar conversations in the context of D3E

    DS: I can understand what AvK is saying

     and also sympathetic to what Jacob is saying

     can't define all possibilites here

     for all default actions for all events for input types

     We would need more info about the use cases and to define a
    general architecture but not clear developers need that

    JR: not sure it would be good to define that detail

     need to know where to draw the line re UI and behavior

     want to make sure UAs can do the right thing for their
    platform without the spec being overly prescriptive

    DS: yes, I agree; a UA could define what it's default behavior

     we can define appropriate hooks but agree don't want to get
    overly prescriptive

     Need to know what UCs need to be solved

    JR: I think we are in rough agreement here

    <scribe> ACTION: Jacob address Q's from
    014AprJun/0012.html [recorded in

      [26] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html

    <trackbot> Created ACTION-103 - Address q's from
    014aprjun/0012.html [on Jacob Rossi - due 2014-04-22].

      [28] http://lists.w3.org/archives/public/public-pointer-events/2014aprjun/0012.html

    JR: I think Q#4 needs some clarification

     but I can make a proposal

    AB: ok great

Testing: status of PR324

    AB: what's the status of PR324
    ... are some reviews pending?

      [29] https://github.com/w3c/web-platform-tests/pull/324/?

    RB: yes, I still have some reviews

    AB: Cathy are you done your reviews?

    CC: still working on them

     also looking at the new tests

    AB: thanks for that update and for reviewing my tests!

    MB: I need to do my reviews and plan to finish this week

    JR: I haven't used "critic" before

     a little difficult to use

    MB: I use critic for my day job

     is nice wrt marking comments as resolved

     thus makes a todo list

     The down side with critic is tracking complicated PRs with
    merges, changes and such

    AB: I haven't used critic that much

CR implementation updates

    AB: anything new to report?

    CC: going back to tests review, there are about 15 test cases
    that have not been reviewed

    AB: so the Q is do we have some holes in the reviews?

    MB: I'll look into that

    CC: ok, thanks

Polymer Pointer Events PSA and Impact of pointer capture on hit
testing requirements

    AB: Rick mentioned this

      [30] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0005.html

    RB: blink and polymer teams working together

     and focusing on mobile

     performance is really important (60ms budget per frame)

     now looking at the sum of little changes

     one prob is polymer uses PE polyfill

     Shadow DOM creates problems

     and magnifies the cost of hit testing

     If there are non-native impls of PE, can't use polyfill

     This brings up why PE has this property

     Different behavior on Android and iOS

     because of PE vs TouchEvents

     I've been talking to Jacob about what to do

     Need some more concrete data

     Don't think we can change PE to support the other model

     This is now one argument against swithing from TEs to PEs

    JR: one Q is if transition events are useful and if so, need
    hit testing

    RB: I don't think people are arguing it isn't useful

     the argument is if it should be on by default and opt-in

     we can't do hit testing by default to get acceptable

    JR: when there is a mobile perf problem, typically look for
    layout solutions

     don't think we want to make model more complicated for more
    common usages

    SG: this is related to Shadow DOM and nested ShadowDOM?

     which case is the .4ms hit?

    RB: native (to Scott)

    JR: perf issues with ShadowDOM are only issues for polyfills
    and not native impls

    RB: I continue to push for consensus on PE

     f.ex. long term commitment for PE

     somewhat minor but performance is very important

    OP: this sounds a bit like an impl issue for blink

     if this only a prob with one impl, shouldn't necessarily
    change the spec just for it

    JR: not all native platforms behave as Rick suggested

     f.ex. Silverlight on WPhones is ok perf

    JR: PEs used on mobile, silverlights, XAML, etc.

     not just Web

     and we get ok result

     Web's prob with mobile is mainly complex layout

    RB: when we compare against Android, there are lots of small
    things we are looking at

    JR: a similar arg could be made re Web Components; won't make
    things faster; will add complexity

     anything that affects layout and rendering will affect perf

    RB: touch-driven affects aren't necessarily layout

    SG: so you have some specific scenarios that are driving this?

    RB: yes, and I should be able to share at least some of those

    SG: great, thanks

    AB: thanks for raising this although a bit sobering

    DS: yes thanks and we understanding the trying circumstances

     I'm hearing similar conversations in other groups

    <smaug> I think Zakim kicked me out

    <smaug> yes

    RB: we talk about a lot of this in the Public and focus on
    making the Web better

    MB: re implementations, I have a Gecko update

     we will not ship FF for Metro as an official release

     but since impl is nearly completed, expect the _community_ to
    complete the impl and testing

     We will submit test results when there is a Call for Test

    DS: great

    AB: thanks and by "nearly complete" what do you mean?

    MB: passing about 94% of the tests in the repo including Msft's
    submitted tests

     and devs are working on fixes for the other tests

    AB: ok, that's good data


    AB: meeting adjourned

Summary of Action Items

    [NEW] ACTION: Jacob address Q's from
    014AprJun/0012.html [recorded in
    [NEW] ACTION: jacob submit a changeset for bug 24971 based on
    2014-Apr-15 discussions [recorded in

      [31] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html

    [End of minutes]

Received on Tuesday, 15 April 2014 16:21:27 UTC