IRC log of pointerevents on 2013-03-12

Timestamps are in UTC.

14:59:44 [RRSAgent]
RRSAgent has joined #pointerevents
14:59:44 [RRSAgent]
logging to
14:59:49 [Zakim]
RWC_PEWG()11:00AM has now started
14:59:54 [ArtB]
ScribeNick: ArtB
14:59:54 [ArtB]
Scribe: Art
14:59:54 [ArtB]
14:59:56 [Zakim]
+ +1.717.578.aaaa
14:59:58 [ArtB]
Chair: Art
15:00:00 [jrossi2]
jrossi2 has joined #pointerevents
15:00:03 [scott_gonzalez]
Zakim, aaaa is me
15:00:03 [Zakim]
+scott_gonzalez; got it
15:00:05 [ArtB]
Meeting: Pointer Events WG Voice Conference
15:00:53 [Zakim]
15:01:22 [Zakim]
15:01:38 [Cathy]
Cathy has joined #pointerevents
15:01:46 [ArtB]
Present: Art_Barstow, Scott_Gonzalez, Jacob_Rossi, Cathy_Chan
15:01:59 [ArtB]
Regrets: Doug_Schepers, Sangwhan_Moon
15:02:12 [rbyers_]
rbyers_ has joined #pointerevents
15:02:13 [Zakim]
+ +1.781.362.aabb
15:02:20 [Cathy]
zakim, aabb is me
15:02:20 [Zakim]
+Cathy; got it
15:02:30 [Zakim]
15:02:37 [ArtB]
Present+ Matt_Brubeck
15:02:56 [Zakim]
15:03:09 [ArtB]
Present+ Asir_Vedamuthu
15:03:34 [jrossi2]
zakim, Microsoft is jrossi2
15:03:34 [Zakim]
+jrossi2; got it
15:04:00 [Zakim]
15:04:00 [Zakim]
15:04:11 [ArtB]
Present+ Rick_Byers
15:04:28 [ArtB]
Topic: Getting started
15:04:33 [ArtB]
AB: I posted a draft agenda yesterday Any change requests? The main subject is to record the group's consensus on last call comments, assuming we have agreement on a comment. And thanks to Jacob for creating the comment list.
15:04:39 [beverloo]
Present+ Peter_Beverloo
15:04:54 [ArtB]
AB: Before we look at the comments, I will talk about the LC comment process.
15:05:16 [ArtB]
Topic: Last Call comment process
15:05:20 [ArtB]
AB: I want to make sure everyone understands the LC comment process and the various roles and responsibilities.
15:05:31 [ArtB]
AB: please note: the process requires the group "round-trip" all comments. This means the group is responsible for: replying to all comments; notifying the Commenter of the group's decision; asking the Commenter if they agree or not with the group's decision; and recording all of this communication. (See for example
15:06:17 [ArtB]
AB: if you have a Commenter role in this work flow, please make sure your reply to the group is recorded either via e-mail or via meeting minutes.
15:06:46 [ArtB]
Topic: pointerType Extensibility
15:06:51 [ArtB]
AB: based on previous discussions re pointerType extensibility e.g. and
15:07:04 [ArtB]
AB: I believe we have consensus to not do anything with this for v1
15:07:13 [ArtB]
AB: any objections to that?
15:07:28 [ArtB]
[ No ]
15:07:36 [Zakim]
15:07:43 [ArtB]
RESOLUTION: pointerType extensibility: no additional changes for  for v1
15:07:48 [ArtB]
AB: should this be added to the v.Next list?
15:08:06 [ArtB]
RB: yes, I think we should
15:08:14 [ArtB]
… but I am open to debate
15:08:24 [Zakim]
15:08:30 [ArtB]
… think we can deal with this better when we have a concrete suggestion
15:08:34 [ArtB]
JR: agree
15:08:38 [ArtB]
SG: agree too
15:08:45 [ArtB]
ACTION: barstow add pointerType extensibility to the PEv.Next feature list
15:08:45 [trackbot]
Created ACTION-24 - Add pointerType extensibility to the PEv.Next feature list [on Arthur Barstow - due 2013-03-19].
15:08:53 [ArtB]
Topic: add a rotation attribute on PointerEvent?
15:09:03 [ArtB]
AB: the question is if there a compelling reason to add? Most recent discussion is
15:09:12 [ArtB]
AB: the only followup was from Jacob. What do people think? Is this something to add to the v.Next feature list?
15:09:38 [ArtB]
AB: we can also defer to the list
15:09:50 [ArtB]
RB: we don't have immediate plans to add this
15:09:58 [ArtB]
… thus I see no need to address this now
15:10:07 [ArtB]
SG: I agree we can postpone this to v.Next
15:10:10 [asir]
asir has joined #pointerevents
15:10:24 [ArtB]
MB: doesn't IE10 support this?
15:10:38 [ArtB]
SG: yes it is but people don't build apps that rely on it
15:10:44 [smaug]
smaug has joined #pointerevents
15:10:50 [ArtB]
… there are some cases where it could be useful
15:10:58 [ArtB]
… but I don't see a lot of interest
15:11:16 [ArtB]
AB: any objections to resolving this as v.Next potential feature?
15:11:20 [mbrubeck]
15:11:25 [ArtB]
[ None ]
15:11:26 [jrossi2]
15:11:28 [asir]
zakim, [Microsoft] is me
15:11:28 [Zakim]
+asir; got it
15:11:34 [ArtB]
RESOLUTION: add a rotation attribute to PointerEvent?: group agrees "No", although add a related item to the v.Next feature list
15:11:55 [smaug]
15:11:55 [ArtB]
ACTION: barstow add rotation attribute to v.Next feature list
15:11:55 [trackbot]
Created ACTION-25 - Add rotation attribute to v.Next feature list [on Arthur Barstow - due 2013-03-19].
15:11:58 [smaug]
summer time
15:12:11 [smaug]
in US, but not in EU
15:12:11 [ArtB]
AV: from process perspective, do we need to add these to Bugzilla?
15:12:17 [ArtB]
AB: no, we don't have to
15:12:45 [ArtB]
… I would only add things to Bugzilla if we are going to make changes to the spec
15:13:09 [ArtB]
JR: if I have original comments, and Resolution, as well as replies, I can create the LC comment doc
15:13:24 [ArtB]
… and only add issues to Bugzilla if we agree to change the spec
15:13:41 [ArtB]
AB: any objections to proceeding that way (i.e. only use Bugzilla for spec changes)?
15:13:47 [ArtB]
15:13:59 [ArtB]
Topic: Should pointerId be an integer?
15:14:04 [ArtB]
AB: the discussion thread is  and we talked about this on Feb 26
15:14:10 [ArtB]
AB: it appears we have agreement the answer is "No", although we could add a non-normative note e.g. the following
15:14:22 [ArtB]
15:14:22 [ArtB]
The pointerId selection algorithm is implementation specific. Therefore authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, values are not guaranteed to be monotonically increasing.
15:14:22 [ArtB]
15:14:40 [jrossi2]
15:14:43 [ArtB]
RB: I think, no change i.e. keep it an integer
15:14:50 [ArtB]
AB: sorry, that is indeed what I meant
15:15:22 [ArtB]
… any objections to keeping pointerID as integer?
15:15:31 [ArtB]
RB: I'm ok with that provided we add that note
15:15:44 [ArtB]
AB: any objections to Jacob's proposed text?
15:15:47 [ArtB]
[ None ]
15:16:13 [ArtB]
RESOLUTION: pointerID should be integer?: group agrees to keep pointerID as Integer, and a related non-normative note will be added to the spec
15:16:23 [ArtB]
Topic: move examples to the front of the spec
15:16:27 [ArtB]
AB: Alex Russell suggested "The spec should lead with examples, i.e., move Section 9 to where Section 2 is now."
15:16:32 [ArtB]
AB: any objections?
15:16:38 [ArtB]
[ None ]
15:16:50 [ArtB]
RESOLUTION: examples will be moved to the front of the spec
15:16:59 [ArtB]
Topic: Change buttons field representation?
15:17:08 [ArtB]
AB: the relevant thread is
15:17:28 [ArtB]
AB: do we want any changes here?
15:18:13 [ArtB]
JR: there could be some benefits of adding some bitmasks
15:18:24 [ArtB]
… and hence have multiple models
15:18:33 [ArtB]
… but I think we should consider that for v.Next
15:18:48 [ArtB]
SG: I think sticking with Mouse Model is best
15:18:59 [ArtB]
… I think Alex acknowledged that in his comment
15:19:00 [rbyers]
I agree with Jacob's comments - compatibility with MouseEvent is key to the design
15:19:14 [ArtB]
AB any objections to staying with buttons as already specified?
15:19:20 [ArtB]
[ None ]
15:19:27 [rbyers]
zakim, who is noisy?
15:19:33 [ArtB]
AB: add this to v.Next list?
15:19:38 [Zakim]
rbyers, listening for 10 seconds I heard sound from the following: Art_Barstow (52%), asir (33%)
15:19:44 [ArtB]
… I think I'm hearing yes
15:19:54 [rbyers]
asir: looks like the echo is coming from your end again. Are you muted?
15:19:58 [ArtB]
RESOLUTION: change buttons field?: group agrees "No", although a related item will be added to v.Next list.
15:20:19 [ArtB]
ACTION: barstow add buttons field to v.Next list as a potential new feature
15:20:27 [trackbot]
Error creating new action - could not connect to Tracker. Please contact sysreq with the details of what happened.
15:20:28 [ArtB]
Topic: conceptual overlap of new touch-action CSS property and pointer-events property
15:20:38 [ArtB]
AB: The question is whether or not the new touch-action CSS property has sufficient conceptual overlap with the pointer-events property to consider merging them
15:20:46 [ArtB]
AB: some people (including Tab Atkins) recommended not merging them.
15:20:52 [ArtB]
AB: does anyone think they should be merged, or do we keep them separate?
15:21:07 [rbyers]
No, they're fundamentally different things in my opinion
15:21:22 [ArtB]
AB: anyone think they should be merged?
15:21:23 [asir]
agree they are different
15:21:26 [ArtB]
[ No one ]
15:21:34 [ArtB]
RESOLUTION: the touch-action CSS property will not be merged with CSS'  pointer-event property
15:21:45 [jrossi2]
one controls how hit testing works, the other controls what you do in response to a hit test -- so very different
15:21:47 [ArtB]
Topic: navigator.maxTouchPoints is touch-specific
15:21:53 [ArtB]
AB: Alex raised this question
15:21:59 [ArtB]
AB: what, if anything, do we want to do with this?
15:22:28 [ArtB]
RB: my concern is that I think we may want to add something in the future
15:22:34 [ArtB]
… e.g. some input device API
15:22:47 [ArtB]
… might want to ask a device a question about itself
15:23:01 [ArtB]
JR: I can see a potential to add something in the future
15:23:13 [ArtB]
RB: I don't have a concrete proposal now
15:23:19 [ArtB]
… need more experience
15:23:37 [ArtB]
JR: similar to pointerType issue in that we need more info
15:23:44 [ArtB]
… to decide the right-thing-to-do
15:24:17 [ArtB]
RESOLUTION: maxTouchPoints is touch-specific: the group agrees on no spec change needed but we should add this to v.Next
15:24:40 [ArtB]
ACTION: barstow add maxTouchPoints issue to v.Next list
15:24:41 [trackbot]
Created ACTION-26 - Add maxTouchPoints issue to v.Next list [on Arthur Barstow - due 2013-03-19].
15:24:47 [rbyers]
asir: that echo is really annoying when talking, can you try using a different phone? Eg. you can call Zakim using SIP...
15:25:00 [ArtB]
SG: re the name, what about maxPointers?
15:25:34 [ArtB]
RB: it would make it harder to pinpoint a definition
15:25:54 [ArtB]
SG: agree it could depend on OS and/or hardware
15:26:05 [ArtB]
RB: we don't have this in TouchEvents
15:26:26 [ArtB]
JR: one way to use this as touch hardware detection i.e. is touch possible
15:26:37 [ArtB]
… and then the UI could adapt accordingly
15:26:59 [ArtB]
RB: there could be overlap with pointer and hover MQs
15:27:11 [ArtB]
JR: the other UC is to know the specific number of devices
15:27:15 [rbyers]
asir: much better, thanks
15:27:24 [ArtB]
… app could then switch on number of devices
15:27:35 [asir]
Zakim-mute worked
15:27:54 [ArtB]
MB: may want it for single touch hardware
15:28:04 [ArtB]
… so may want to name it MaxTouchPoints
15:28:25 [ArtB]
RB: not clear if MQs is the right place or do we need a new API
15:28:41 [ArtB]
… could have touch-points MQ
15:28:50 [mbrubeck]
I think a media query would be good.
15:28:54 [ArtB]
… would be more consistent with pointer and hover MQs
15:29:15 [ArtB]
RB: but don't think this is critical to address (now)
15:29:27 [ArtB]
… could move this to v.Next
15:29:59 [ArtB]
… The UA needs a way to tell app it is on a touch screen
15:30:26 [ArtB]
JR: not opposed to pointer and hover
15:30:47 [ArtB]
RB: are there sites that rely on the number in practice?
15:31:06 [Zakim]
15:31:11 [ArtB]
JR: mostly seeing checks for >= 0
15:31:43 [ArtB]
AB: do we want to revisit the Resolution?
15:31:55 [ArtB]
RB: question about adding a redundant API
15:32:06 [ArtB]
SG: want to avoid duplicated APIs in the future
15:32:21 [ArtB]
RB: if we could get touch-points added as a MQ
15:32:47 [ArtB]
… then there would be no value in adding this API
15:33:02 [ArtB]
SG: that would be OK with me
15:33:15 [ArtB]
JR: there could be value in querying this from CSS
15:33:28 [ArtB]
… there is already some content using this so we need to keep it
15:33:42 [ArtB]
RB: understand but we wouldn't add it
15:34:17 [ArtB]
AB: so, despite the RESOLUTION, it appears we need some more time to talk about this
15:34:38 [ArtB]
JR: not sure how number of points supported is interesting from a view perspective
15:35:03 [ArtB]
… I'm open to adding a new MQ
15:35:24 [ArtB]
… not sure how that adds anymore than using maxTouchPoints
15:36:14 [ArtB]
RB: there could be some scenarios that only want to query from CSS
15:36:23 [ArtB]
… e.g. a map app and pinch/zoom
15:36:55 [ArtB]
RB: I don't object strongly but I don't like redundant APIs
15:37:37 [ArtB]
AB: so, looking at this from CanILiveWithItTest, is the resolution we agreed to earlier ok?
15:37:49 [ArtB]
RB: yes, I can live with it as spec'ed
15:37:52 [jrossi2]
Would prefer keeping as spec'ed
15:37:57 [ArtB]
SG: yeah, it's fine
15:38:09 [ArtB]
AB: so the maxTouchPoints RESOLUTION stands
15:38:37 [ArtB]
AB: so, there is the CR phase which is YA opportunity to gather data
15:39:07 [ArtB]
Topic: Clarifying the spec's positioning
15:39:17 [ArtB]
AB: Alex wrote "The pointer event spec does not require other device events be supported (e.g. mouse events, touch
15:39:17 [ArtB]
events, etc.)" in
15:39:30 [ArtB]
AB: what needs to be done here? Some additional non-normative text?
15:40:05 [rbyers]
One more point on the last topic: many media queries are already redundant with javascript APIs (eg. width, height), so from that perspective it's not terrible for navigator.maxTouchPoints to be largely redundant with the pointer media query.
15:40:06 [ArtB]
JR: as I said in my reply, I think this is conceptual.
15:40:21 [ArtB]
… if there is a need for some non-normative text, I can add it
15:40:57 [ArtB]
AB: any other comments or objections to adding a non-normative statement to address this issue?
15:41:00 [ArtB]
[ None ]
15:41:21 [ArtB]
RESOLUTION: group agrees some additional non-normative text re spec's "positioning" should be added.
15:41:27 [ArtB]
ACTION: Jacob propose text re the "spec's positioning" (see LC comment from Alex Russell)
15:41:28 [trackbot]
Created ACTION-27 - Propose text re the "spec's positioning" (see LC comment from Alex Russell) [on Jacob Rossi - due 2013-03-19].
15:41:42 [ArtB]
Topic: Click and contextmenu events
15:41:42 [rbyers]
jrossi2: probably not necessary to mute and unmute now - the problem was fixed by muting asir
15:41:55 [ArtB]
AB: this topic has raised by Rick in and discussed on Feb 26
15:42:07 [ArtB]
AB: where are we on this issue?
15:42:12 [jrossi2]
rbyers: cool, unmuted
15:42:44 [ArtB]
RB: Jacob agreed they are pretty much the same and should be treated the same
15:43:10 [ArtB]
JR: click is mentioned
15:43:24 [ArtB]
RB: some text in Section 8, non-normative
15:43:45 [ArtB]
[ JR reads relevant text … ]
15:44:14 [ArtB]
RB: yes, we should just expand the note
15:44:19 [ArtB]
… e.g. add double-click too
15:44:44 [ArtB]
RESOLUTION: group agrees to add some addtional text to Section 8
15:45:06 [ArtB]
ACTION: Jacob add text to Section 8 to address Rick's click and context menu issue
15:45:14 [trackbot]
Error creating new action - could not connect to Tracker. Please contact sysreq with the details of what happened.
15:45:37 [ArtB]
Topic: Test Assertions:
15:45:43 [ArtB]
AB: Cathy, do you have any status on test assertions to share?
15:46:06 [ArtB]
CC: no, not yet; should have something in the next couple of weeks
15:46:13 [ArtB]
AB: ok, thanks
15:46:21 [ArtB]
AB: if you can help with this effort, please contact Cathy via the list
15:46:46 [ArtB]
Topic: Any other Business
15:46:52 [ArtB]
AB: any new implementation status to share?
15:59:14 [rbyers]
Here's the bug tracking adding pointer events to chrome:
16:00:09 [rbyers]
Here's the text I wrote there:
16:00:10 [rbyers]
Pointer events offers a number of improvements, and solves important problems with touch events. However adding a new (largely redundant) input model to the web is not something we can take lightly. We're actively debating whether the benefits justify the conceptual complexity of having a new input model. I welcome any comments on this bug (especially from site/library developers using both touch and pointer events today).
16:01:07 [ArtB]
[ Scott talked about some TE / PE info in jQuery ]
16:01:21 [ArtB]
RB: would like to see a blog about that
16:01:32 [ArtB]
… there are two polyfills for PE now
16:01:40 [ArtB]
… Msft has one
16:01:51 [ArtB]
… and Google has one
16:01:55 [ArtB]
16:02:03 [jrossi2]
16:02:06 [rbyers]
Google one:
16:02:15 [ArtB]
… the pollyfills are tricky, especially for performance reasons
16:02:40 [ArtB]
RB: touch-action CSS property in particular is problematic
16:02:48 [ArtB]
AB: thanks for adding those
16:02:51 [scott_gonzalez]
16:02:51 [rbyers]
Not perfect (Eg. relies on a touch-action html attribute, instead of trying to parse CSS like hand.js)
16:02:59 [ArtB]
SG: there is another polyfill from Boris Smus
16:03:20 [ArtB]
RB: yeah, but Boris' isn't as complete so I recommend the Google one I mentioned above
16:03:54 [ArtB]
… pointer.js is worth looking at but it isn't complete
16:04:37 [ArtB]
SG: we still have some issues we are discussing
16:04:53 [ArtB]
RB: are those design discussion done in public?
16:05:16 [ArtB]
SG: yes; a lot are in IRC; others are in pull requests
16:05:35 [ArtB]
RB: when jQuery makes important decisions, would love to hear about it
16:05:43 [ArtB]
SG: I can send that info to the list
16:05:57 [ArtB]
AB: on March 19 I have a conflict and will not be available. We will have a meeting if Doug can Chair it.
16:06:13 [ArtB]
AB: regardless, please continue to use the list
16:06:23 [asir]
Good progress today in closing issues!!!
16:06:31 [ArtB]
AB: anything else?
16:06:35 [rbyers]
Yes, thank you Art!
16:06:41 [ArtB]
AB: meeting adjourned
16:06:46 [Zakim]
16:06:48 [asir]
Thank you Art!!!
16:06:48 [Zakim]
16:06:50 [Zakim]
16:06:51 [Zakim]
16:06:53 [Zakim]
16:06:54 [ArtB]
RRSAgent, make minutes
16:06:54 [RRSAgent]
I have made the request to generate ArtB
16:06:57 [Zakim]
16:07:00 [jrossi2]
jrossi2 has left #pointerevents
16:07:30 [ArtB]
RRSAgent, make log Public
16:07:36 [ArtB]
RRSAgent, make minutes
16:07:36 [RRSAgent]
I have made the request to generate ArtB
16:11:58 [Zakim]
disconnecting the lone participant, asir, in RWC_PEWG()11:00AM
16:11:59 [Zakim]
RWC_PEWG()11:00AM has ended
16:11:59 [Zakim]
Attendees were +1.717.578.aaaa, scott_gonzalez, Art_Barstow, +1.781.362.aabb, Cathy, Matt_Brubeck, jrossi2, [GVoice], asir
16:12:19 [ArtB]
zakim, bye
16:12:19 [Zakim]
Zakim has left #pointerevents
16:38:01 [ArtB]
rrsagent, bye
16:38:01 [RRSAgent]
I see 6 open action items saved in :
16:38:01 [RRSAgent]
ACTION: barstow add pointerType extensibility to the PEv.Next feature list [1]
16:38:01 [RRSAgent]
recorded in
16:38:01 [RRSAgent]
ACTION: barstow add rotation attribute to v.Next feature list [2]
16:38:01 [RRSAgent]
recorded in
16:38:01 [RRSAgent]
ACTION: barstow add buttons field to v.Next list as a potential new feature [3]
16:38:01 [RRSAgent]
recorded in
16:38:01 [RRSAgent]
ACTION: barstow add maxTouchPoints issue to v.Next list [4]
16:38:01 [RRSAgent]
recorded in
16:38:01 [RRSAgent]
ACTION: Jacob propose text re the "spec's positioning" (see LC comment from Alex Russell) [5]
16:38:01 [RRSAgent]
recorded in
16:38:01 [RRSAgent]
ACTION: Jacob add text to Section 8 to address Rick's click and context menu issue [6]
16:38:01 [RRSAgent]
recorded in