- 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