- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 15 Apr 2014 12:20:44 -0400
- To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the April 15 voice conference are available at the following and copied below: <http://www.w3.org/2014/04/15-pointerevents-minutes.html> 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]W3C [1] http://www.w3.org/ - DRAFT - Pointer Events WG Voice Conference 15 Apr 2014 [2]Agenda [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 Attendees Present Art_Barstow, Cathy_Chan, Doug_Schepers, Matt_Brubeck, Scott_Gonzalez, Olli_Pettay, Rick_Byers, Asir_Vedamuthu, Jacob_Rossi Regrets Sangwhan_Moon, Patrick_Lauke Chair Art Scribe Art Contents * [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 element 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 [15]http://lists.w3.org/Archives/Public/public-pointer-events/2 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 24971[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971. Jacob by submitting comment #5 [17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971#c5. ... This bug was originally submitted by Olli and discussed during our last call [18]http://www.w3.org/2014/03/25-pointerevents-minutes.html#ite m03 [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 [19]http://www.w3.org/2014/04/15-pointerevents-minutes.html#act ion01] <trackbot> Created ACTION-102 - Submit a changeset for bug 24971 based on 2014-apr-15 discussions [on Jacob Rossi - due 2014-04-22]. 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 [20]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25147. Yesterday, Jacob suggested this bug could be addressed via his proposal in comment #5 of Bug 24971 [21]https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971#c5 [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 [23]http://lists.w3.org/Archives/Public/public-pointer-events/2 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 [24]http://lists.w3.org/Archives/Public/public-pointer-events/2 014AprJun/0011.html and Anne replied [25]http://lists.w3.org/Archives/Public/public-pointer-events/2 014AprJun/0012.html. ... 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 is … 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 [26]http://lists.w3.org/Archives/Public/public-pointer-events/2 014AprJun/0012.html [recorded in [27]http://www.w3.org/2014/04/15-pointerevents-minutes.html#act ion02] [26] http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html <trackbot> Created ACTION-103 - Address q's from [28]http://lists.w3.org/archives/public/public-pointer-events/2 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 [29]https://github.com/w3c/web-platform-tests/pull/324/? ... 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/2 014AprJun/0005.html [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 performance 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 Results 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 AoB AB: meeting adjourned Summary of Action Items [NEW] ACTION: Jacob address Q's from [31]http://lists.w3.org/Archives/Public/public-pointer-events/2 014AprJun/0012.html [recorded in [32]http://www.w3.org/2014/04/15-pointerevents-minutes.html#act ion02] [NEW] ACTION: jacob submit a changeset for bug 24971 based on 2014-Apr-15 discussions [recorded in [33]http://www.w3.org/2014/04/15-pointerevents-minutes.html#act ion01] [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