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

Draft minutes: 9 April 2013 call

From: Arthur Barstow <art.barstow@nokia.com>
Date: Tue, 09 Apr 2013 12:33:36 -0400
Message-ID: <516442E0.1090704@nokia.com>
To: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
The draft minutes from the April 9 voice conference are available at 
<http://www.w3.org/2013/04/09-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 April 16. In the 
absence of any changes, these minutes will be considered approved.

-Thanks, ArtB


[1] http://www.w3.org/


Pointer Events WG Voice Conference

09 Apr 2013



See also: [3]IRC log

[3] http://www.w3.org/2013/04/09-pointerevents-irc


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





* [4]Topics
1. [5]Getting started: tweak agenda; determine scribe
2. [6]Last Call comment processing
3. [7]Sergey's Comments
4. [8]Mose Bottacini's comments
5. [9]Constructor question and mouseEvents compat
6. [10]Boris Zbarsky comments on April 5 .
7. [11]Benoit's comment
8. [12]Moving Pointer Events spec to Candidate
9. [13]Testing: status, need volunteers for test
10. [14]Any other Business: implementation status
* [15]Summary of Action Items

<scribe> ScribeNick: ArtB

<scribe> Scribe: Art

Getting started: tweak agenda; determine scribe

AB: I posted the draft agenda yesterday
... One addition I propose is the "Constructor question and
mouseEvents compat" thread started by Mozilla's Wesley Johnston
013AprJun/0009.html since Matt indicated a spec change might be
needed to address this comment.
... any objections to including that during the LC comment
processing discussion?



AB: any other change requests?

<smaug> ArtB: sorry, I can't as I said here few minutes ago

<smaug> I'm in a train



DS: I think we should add Benoit's comment


AB: any objections to that?

[ None ]

Last Call comment processing

AB: the comment tracking document is
... Jacob, I think it would be useful, especially if/when there
is a CR transition call, if each issue that resulted in a
change includes a link to the related changeset(s). Can you
please add that?

[20] https://dvcs.w3.org/hg/pointerevents/raw-file/tip/dc.html.

<scribe> ACTION: Jacob add links to changesets for LC comments
that resulted in changes [recorded in

<trackbot> Created ACTION-33 - Add links to changesets for LC
comments that resulted in changes [on Jacob Rossi - due

AB: Jacob, you will also need to include changes since LC
publication in the Revision History Appendix.

JR: ok, will do

Sergey's Comments

AB: Sergey's response to the group's resolution to Yanex's 5
comments is in
013AprJun/0019.html. He replies to #1, #2, #3 and #5,
presumably he is OK with our response to #4 (tiltX/tiltY).
... during the March 26 call we agreed to not make any changes
although we did add #1 (#17 in LC tracking doc) and #2 (#16) to
the v.next list
... in
013AprJun/0022.html indicates he doesn't object to Sangwhan's
reasoning re #2 so I think we are OK there.
... regarding the other comments, I'm not sure that much new
information is being added such that people are convinced to
change or move their position. This isn't an especially good
situation but not uncommon either.
... I do note that Sergey has not formally Objected to the
group's decision
... my gut feel here is that best way to proceed is to move to
the implementation phase where we can then get feedback from
not only implementers of the spec but developers too.
... let's break this up into two parts: 1) detailed comments
regarding Sergey's comments; 2) more general comments on how we
... any detailed comments or thoughts on Sergey's comments?

[23] http://www.w3.org/wiki/PointerEvents/UseCasesAndRequirements.

RB: setPointerCapture gives us the ability to emulate touch
event better

 so it can actually be essential with processing iframes

 which cannot be done with touch events

AB: does anyone think we need to change to our previously
agreed resolutions on Yandex's comments?

JR: no, I don't think there is any new evidence to reopen our
previous decisions

RB: I agree but want to add that pointerCapture is something
that is worth debating

 I hope we can continue to encourage discussion and get
feedback from devs

 especially wrt composition

JR: yes, I agree we need more feedback, especially from
framework people

 and that's true for lots of other APIs in the platform e.g.
Web Components

 It could be that Web Components helps with the capture issues

<smaug> hmm, does the spec say how pointer events work with

RB: this is a bit diff for propagation
... stopImmediatePropagation

 we need to watch for composition scenarios that may be

 e.g. embedded maps

 This is a subtle and important class of problems that we need
to get right

JR: for single canvas element should be able to set capture to

 and then if lost can be determined

 think we have some tools

SG: nested widgets means inner widget needs to be able to say
I'll handle this

 and now there is no way to do that

 i.e. say "I handled this event"

 with jQuery have to handle bubbling differences with special

 but there are problems when adding new libs

 The innermost thing that wants to handle should handle it

DS: concerned our rationale is being discussed among ourselves

 and not directly to Sergey

 I think we should invite him to a telco

 It could help smooth out some differences

MB: we should also consider that most devs won't make the
effort that Sergey did

 i.e. they won't read the spec and send comments

 they will get something that doesn't work and then just back
to iOS

<smaug> (most devs use script libraries which probably get
things right)

 so agree we need to do more outreach to devs

DS: yes, could put some doc in webplatform.org, MDN, etc.

 need some tutorial info

 think talking directly could help with the dialogue

DS: do people agree with a call

<mbrubeck> +1 on inviting Sergey to participate in the telcon

JR: he certainly represents a class of scenarios

 and we need to reach out to them

 not sure if a telco will help

 but think documenting/marketing these scenarios is justified

AB: I don't object to it, but I don't think we should
necessarily block on such a call

DS: sure

<scribe> ACTION: shepazu invite Sergey to a call [recorded in

<trackbot> Created ACTION-34 - Invite Sergey to a call [on Doug
Schepers - due 2013-04-16].

AB: so it seems like we could record a resolution like:
RESOLUTION: the group's previous decisions on Yandex's comments
stands (see
ml for details)
... any objections to such a resolution?

[26] https://dvcs.w3.org/hg/pointerevents/raw-file/default/dc.html

[ None ]

RESOLUTION: the group's previous decisions on Yandex's comments
stands (see
ml for details)

[27] https://dvcs.w3.org/hg/pointerevents/raw-file/default/dc.html

Mose Bottacini's comments

AB: Asir asked Mose to reply to his response by April 8. It
appears we still have no response from him
... I believe re already recorded a Resolution that the group
agrees with Asir's reply so I think the comment tracking should
reflect that we contacted him, we got no response and that we
won't block on this.
... does anyone object to not blocking on this comment?


[ None ]

RESOLUTION: the group's previous decision on Mose's comment
stands (no change to the spec)

Constructor question and mouseEvents compat

AB: Wesley's comment is
013AprJun/0009.html. There were replies by Jacob
013AprJun/0017.html and Matt
... Jacob already checked in a non-substantive fix for comment
#1. What, if anything, do we want to do here re comment #2?


MB: issue #2 had 2 parts

 some confusing wording re primary pointers

 second issues is spec does not make it clear whether more
than one simul pointer creates compat events

 I haven't tested this yet on IE

JR: the behavior here is that multiple pointers are fighting
for the mouse cursor

 we think our behavior is compatible

 we looked at more arbitration scenarios

 they get pretty complex

 Some form factors may benefit from diff arbitration rules

MB: from the user perspective, then just use one mouse

 (if don't like jumping around)

 Perhaps the sec 8 algorithms can be then be left as is

 and arbitration is done at a separate level

 and we can just change the text to make it more clear

 re primary pointer

JR: yes, adding some clarity would be fine

MB: if you search for primary pointer there are a couple of
other places that need clarification

JR: can you do that Matt?

MB: yes

RB: thanks Matt

<scribe> ACTION: Matt update the spec to reflect primary
pointer clarification [recorded in

<trackbot> Created ACTION-35 - Update the spec to reflect
primary pointer clarification [on Matt Brubeck - due

Boris Zbarsky comments on April 5 .

AB: Boris submitted some comments on April 5
013AprJun/0016.html. For those that don't know Boris, he works
for Mozilla.
... the good news is that he didn't identify any WebIDL issues.
However, he made two other comments and no one has replied to
them yet. I think we should treat his comments like LC comment.


JR: I didn't reply yet

<asir> do we need to record a resolution for the previous

 but I did make a slight change re his first comment

<asir> okay - thank you

RESOLUTION: to address Wesley's comment, Matt will update the
spec with some non-substantive changes

JR: the events are already marked as async in the table

 I need to update some text too

 I'll reply to that 1st comment

 Re the 2nd comment

 there is some performance implications with blocks

 want to be able to do the processing off thread

 inline elements are more challenging

 Based on the scenarios we looked at, most are block level

 for canvas and svg where you may have an interactive game,
those are also block level

 In practice, we have not seen scenarios for inline elements

 I think if it was supported, the UX would be poor

 So mostly this way for performance reasons

DS: is the rationale documented?

JR: not in the spec

DS: think it would be useful

JR: I can propose something in my reply to Boris

DS: to overcome this perceived limitation, an author can make
it block level with CSS, just in time

RB: there are some UCs where you wouldn't want to do that

 [ missed the scenario ]

 But I agree with Jacob - let's keep it simple for now

 and if that changes, we revisit

JR: at this point, I think it would go counter to our
performance goals

RB: I don't think this is important enough to delay

<scribe> ACTION: jacob reply to Boris [recorded in

<trackbot> Created ACTION-36 - Reply to Boris [on Jacob Rossi -
due 2013-04-16].

AB: is there consensus to address this by non-normative text?

DS: we need to include rationale

JR: yes, and that would be non-normative

DS: we need to add it

<rbyers> The scenario I described was an inline image inside of
text (maybe even a button) which wants to have special touch
handling. I said an inline image carousel, but more realistic
is probably an inline button (eg. footnote) which wants to have
some special touch behavior (eg. swipe to open) without
changing scrolling behavior on the text...

AB: proposed RESOLUTION: re Boris' comment, we will add
non-normative rationale to the spec

RESOLUTION: re Boris' comment, we will add non-normative
rationale to the spec

Benoit's comment



DS: Jacob replied

 I would characterize them as v2

 is that fair?

JR: yes, we have previously discussed these and agreed v2

DS: have he received a reply yet?

JR: no

DS: he is writing a framework

 this is good input

 we should have a roadmap to deal with things like pointer

JR: pointer lists is on the v2 list
... once we start to spec this, there could be broader device
query API needed

DS: yeah, we had related comments with D3E

 OK, I'm satisfied

AB: is there consensus to not change the spec and these
features are for v2?

JR: yes

<rbyers> sounds right to me

 sustaining previous resolutions

RESOUTION: re Benoit's comments, we consider those feature
requests as part of v2

<scribe> ACTION: jacob reply to Benoit re the group's
9-Apr-2013 decision [recorded in

<trackbot> Created ACTION-37 - Reply to Benoit re the group's
9-Apr-2013 decision [on Jacob Rossi - due 2013-04-16].

RB: I think there is also a bit of confusion re "same time" for

 it could be worthwhile to say we think there is no real
problem for this but we can look into it for v2

 but it would be good to make sure his concerns are clear

<scribe> ACTION: rick reply to Benoit re clarity for his
concerns [recorded in

<trackbot> Created ACTION-38 - Reply to Benoit re clarity for
his concerns [on Rick Byers - due 2013-04-16].

[ I missed your comment Scott - sorry about that! Please add
them here ]

JR: there are devices that give effectively parallel input

 moves can happen within 1/100 of a second

 and they can be "simultaneous" moves

RB: and pinch may not necessarily be two touches at the same

JR: if Rick is going to reply to Benoit, then I don't have to

RB: ok, that's fiine

Moving Pointer Events spec to Candidate Recommendation

AB: we still have a few things to do before we can determine if
we have consensus to publish a CR.
... the main open actions followups
... if we can get closure on comments real soon, we should be a
position to have a CfC during our next call on April 16.

<scott_gonzalez> For tracking "framed" touches, you can use
requestAnimationFrame() or similar and manually track the
events that occur between frames.

AB: does that sound about right?

JR: yes

AB: I think it is time to agree to something like "We're done
with LC comments. All new comments will be considered during

JR: yes, I agree

RB: yes

AB: proposed RESOLUTION: the group agreed that any new comments
for Pointer Events v1 will be consider CR comments
... any objections?

<asir> Closing Last Call issues list makes sense

<jrossi21> ACTION: jrossi to update comment doc to reflect
these last comments [recorded in

<trackbot> Created ACTION-39 - Update comment doc to reflect
these last comments [on Jacob Rossi - due 2013-04-16].

[ None ]

RESOLUTION: the group agreed that any new comments for Pointer
Events v1 will be consider CR comments

Testing: status, need volunteers for test submissions;

AB: Cathy did a lot of work on the Test Assertions since our
last meeting, so thanks Cathy for that!
... Scott checked in some tests yesterday, so thanks Scott!
... there are still lots of holes so please review the TA
tables and pick some.

[39] http://www.w3.org/wiki/PointerEvents/TestAssertions.

JR: there is the TTF event by Microsoft and Adobe on Friday and

 please come if you can

 Matt and I will be there

<mbrubeck> Not sure if I'm coming yet, but will try

SG: someone from jQ will be there

AB: that's excellent!

JR: some groups have a separate list for tests?

AB: I don't think that's necessary

<mbrubeck> I agree it's not needed for this group.

 and if we have probs, we can revisit

Any other Business: implementation status

AB: any new implementation status to share?

RB: re the WebKit/Blink fork

<mbrubeck> Wes Johnston at Mozilla is in early stages of
implementation work.

 If anyone has Qs or concerns, I'm happy to talk about that

MB: on Gecko side, Wes Johnston has started some implementation

 it's a bit of a side project but hopefully more people will
get involved

DS: are you aware of any PE issues wrt Blink?

RB: at Google I/O I am giving a talk and hope to report some

<asir> I think you cannot hear me for some reason

AB: next call is April 16.
... meeting adjourned

Summary of Action Items

[NEW] ACTION: Jacob add links to changesets for LC comments
that resulted in changes [recorded in
[NEW] ACTION: jacob reply to Benoit re the group's 9-Apr-2013
decision [recorded in
[NEW] ACTION: jacob reply to Boris [recorded in
[NEW] ACTION: jrossi to update comment doc to reflect these
last comments [recorded in
[NEW] ACTION: Matt update the spec to reflect primary pointer
clarification [recorded in
[NEW] ACTION: rick reply to Benoit re clarity for his concerns
[recorded in
[NEW] ACTION: shepazu invite Sergey to a call [recorded in

[End of minutes]
Received on Tuesday, 9 April 2013 16:34:04 UTC

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