See also: IRC log
<smaug> just a sec
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
AB: since I submitted the draft
agenda yesterday
http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/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?
RB: yes, as well as the polymer change
AB: ok; any other changes?
AB: yesterday Jacob completed
Action-99 re Bug 24971https://www.w3.org/Bugs/Public/show_bug.cgi?id=24971.
Jacob by submitting comment #5 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
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 http://www.w3.org/2014/04/15-pointerevents-minutes.html#action01]
<trackbot> Created ACTION-102 - Submit a changeset for bug 24971 based on 2014-apr-15 discussions [on Jacob Rossi - due 2014-04-22].
AB: Olli submitted this bug on March 25 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 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
AB: yesterday Jacob completed action-94 for this bug by making an explicit proposal in comment #5 https://www.w3.org/Bugs/Public/show_bug.cgi?id=21749#c5 and he replied to Francois http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0010.html. Other than waiting for Francois' feedback, is there anything else on this?
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
AB: Jacob followed up yesterday
http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0011.html
and Anne replied
http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html.
... it might be helpful to look at each response
… 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 http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html [recorded in http://www.w3.org/2014/04/15-pointerevents-minutes.html#action02]
<trackbot> Created ACTION-103 - Address q's from http://lists.w3.org/archives/public/public-pointer-events/2014aprjun/0012.html [on Jacob Rossi - due 2014-04-22].
JR: I think Q#4 needs some clarification
… but I can make a proposal
AB: ok great
AB: what's the status of PR324
https://github.com/w3c/web-platform-tests/pull/324/?
... are some reviews pending?
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
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
AB: Rick mentioned this 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
AB: meeting adjourned
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Topic: Polymer Pointer Events PSA/Topic: Polymer Pointer Events PSA and Impact of pointer capture on hit testing requirements/ Succeeded: s/4ms/.4ms/ Succeeded: s/SD/ShadowDOM/g Found ScribeNick: ArtB Found Scribe: Art Present: Art_Barstow Cathy_Chan Doug_Schepers Matt_Brubeck Scott_Gonzalez Olli_Pettay Rick_Byers Asir_Vedamuthu Jacob_Rossi Regrets: Sangwhan_Moon Patrick_Lauke Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0004.html Got date from IRC log name: 15 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/15-pointerevents-minutes.html People with action items: jacob WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]