IRC log of pointerevents on 2012-12-04

Timestamps are in UTC.

16:02:32 [RRSAgent]
RRSAgent has joined #pointerevents
16:02:32 [RRSAgent]
logging to
16:02:36 [smaug]
Zakim, nick smaug is Olli_Pettay
16:02:36 [Zakim]
ok, smaug, I now associate you with Olli_Pettay
16:02:40 [ArtB]
RRSAgent, make logs Public
16:02:48 [ArtB]
Scribe: Art
16:02:52 [Zakim]
16:02:53 [ArtB]
ScribeNick: ArtB
16:02:55 [Zakim]
+ +1.519.513.aacc
16:03:04 [ArtB]
16:03:09 [ArtB]
Date: 4 December 2012
16:03:13 [ArtB]
Chair: Art
16:03:19 [ArtB]
Meeting: Pointer Events WG Voice Conference
16:03:22 [smaug]
hmm, is it possible to teach Zakim to bind certain nick always to the right person
16:03:56 [Zakim]
16:04:09 [ArtB]
Present: Art_Barstow, Olli_Pettay, Jacob_Rossi, Rick_Byers, Asir_Vedamuthu, Scott_González, Doug_Schepers
16:04:24 [smaug]
mbrubeck: ping
16:04:38 [ArtB]
Topic: Getting started
16:04:44 [ArtB]
AB: need a scribe (cheat sheet <>)
16:04:49 [ArtB]
Present+ Matt_Brubeck
16:05:25 [Zakim]
16:05:46 [ArtB]
RB: I can take it today but want someone else to help in the future
16:05:52 [ArtB]
AB: thanks Rick
16:05:59 [ArtB]
ScribeNick: rbyers
16:06:03 [ArtB]
Scribe+ Rick
16:06:44 [rbyers]
Jacob: we should rotate scribe according the bugs
16:07:17 [rbyers]
16:08:07 [rbyers]
Topic: announcements?
16:08:23 [rbyers]
Topic: CfC to publish first public working draft
16:08:44 [rbyers]
Art: proposal is to go ahead and publish it
16:08:56 [rbyers]
... but Jacob is free to update the doc, eg. to reflect any decisions made today
16:08:59 [rbyers]
... any objections?
16:09:02 [rbyers]
16:09:14 [ArtB]
RESOLUTION: the group agrees to publish a FPWD of Pointer Events
16:09:27 [ArtB]
ACTION: Jacob prepare a FPWD and notify Art when it is ready (see
16:09:27 [trackbot]
Created ACTION-6 - Prepare a FPWD and notify Art when it is ready (see [on Jacob Rossi - due 2012-12-11].
16:10:31 [rbyers]
Art: guess is doc will be published a week from today, or ... <missed>
16:10:43 [rbyers]
Art: last date to publish this year is Dec 13
16:10:55 [Asir]
Asir has joined #pointerevents
16:11:22 [rbyers]
Jacob: is there a CfC period?
16:11:33 [rbyers]
Art: No, resolution is good enough for you to start
16:11:41 [rbyers]
Jacob: Think I can get it in sometime this week
16:12:38 [ArtB]
ACTION: barstow send Transition Request for FPWD of Pointer Events
16:12:39 [trackbot]
Created ACTION-7 - Send Transition Request for FPWD of Pointer Events [on Arthur Barstow - due 2012-12-11].
16:13:01 [rbyers]
Topic: bugs
16:14:37 [rbyers]
Jacob: for new bugs, suggest we wait for some discussion on the list
16:15:05 [rbyers]
Topic: bug 20107 - Pointer events should indicate stylus eraser/inversion
16:15:17 [ArtB]
16:15:40 [rbyers]
Jacob: current spec doesn't expose erase, valid feedback.
16:15:55 [rbyers]
... default guess: another value for the button property
16:17:20 [rbyers]
Rick: how is the button identified?
16:17:42 [rbyers]
Jacob: suggest we use the identifier from the USB HID
16:18:38 [jrossi2]
16:18:55 [rbyers]
... suggest appending to this table a button #5%
16:19:22 [rbyers]
... will send mail with suggested button name
16:19:28 [rbyers]
... if everyone agrees, will change the spec
16:20:16 [rbyers]
Topic: Bug 20108 - Extend pointer events to support raw trackpad data
16:20:22 [ArtB]
16:20:31 [rbyers]
16:20:43 [rbyers]
Topic: Bug 20108 - Clarify pointer capture behavior
16:21:36 [rbyers]
Jacob: what's missing from the spec are some additional things IE10 does for the capture APIs:
16:21:44 [rbyers]
... see bug for details
16:23:20 [rbyers]
Jacob: #1 - should it be possible to capture when buttons=0?
16:23:49 [rbyers]
zakim, who is speaking?
16:24:02 [Zakim]
rbyers, listening for 10 seconds I heard sound from the following: +1.770.402.aabb (9%), Olli_Pettay (84%)
16:24:16 [rbyers]
Olli: may need other mechanism for UA to release pointer capture
16:24:33 [rbyers]
... gecko is fairly strict in it's set capture implementation
16:24:39 [rbyers]
... probably more so than IE
16:25:10 [rbyers]
Jacob: sounds like we need some allowances for UAs to choose to release capture at other times
16:25:15 [rbyers]
Olli: Agree
16:25:29 [rbyers]
Jacob: in IE10, it also differs between Win7 and Win8
16:25:37 [rbyers]
... I will think through some spec text to give more freedom
16:26:28 [rbyers]
Jacob: to clarify, IE10 only has preview on Win7 that doesn't support pointer events.
16:27:25 [rbyers]
Jacob: #4 from bug: pointer events aren't dispatched to elements not in the document
16:28:06 [rbyers]
... believe this is consistent with most types of events
16:28:48 [rbyers]
Rick: touch events is very different - always capture to the node where they started, even once removed from the document
16:29:41 [rbyers]
Jacob: prefer not to allow events for detached element
16:29:43 [rbyers]
Rick: agree
16:30:01 [rbyers]
Jacob: #5: compat mouse events are also redirected to captured element
16:30:17 [rbyers]
... to be consistent with where pointer events
16:30:35 [rbyers]
... hearing no opposition, should we add them?
16:31:18 [rbyers]
Olli: should we limited capturing to a single document?
16:31:58 [rbyers]
Jacob: I have looked into those multi-iframe scenarios.
16:32:29 [rbyers]
... you're not going to get access to the dom, but you will get co-ordinate data
16:32:37 [rbyers]
... agree we need to be very careful.
16:32:45 [rbyers]
... if we come up with a specific issue, we can open a bug to add a restrictioon
16:32:51 [rbyers]
Olli: ok
16:33:43 [rbyers]
RESOLUTION: Will add the additional pointer capture conditions to the spec
16:34:05 [rbyers]
Topic: 20109 - Permitted values for pressure
16:34:25 [ArtB]
16:34:36 [jrossi2]
16:35:04 [rbyers]
Jacob: Input APIs in Windows are largely designed around this USB spec
16:35:31 [rbyers]
... defines two different ways of looking at pressure, as discussed on the list
16:36:22 [rbyers]
... uses both relative (0..127) and absolute (physical units) forms of pressure
16:37:11 [rbyers]
... get the point that a more capable pen should be able to provide higher than normal values
16:37:31 [rbyers]
... think we should either keep it as is, or switch to physical units
16:37:54 [rbyers]
Olli: clear we can't report some random value that has no meaning
16:38:27 [shepazu]
16:38:37 [shepazu]
q- later
16:40:51 [rbyers]
Rick: probably only conforming behavior on Android is to truncate above 1.0
16:41:04 [rbyers]
Jacob: want the property to be interoperable and mean the same thing
16:41:45 [Zakim]
16:42:02 [Asir]
sorry I got dropped and reconnected
16:43:01 [rbyers]
Rick: key question is if we have only one anchor, should we anchor against the maximum value or some subjective indication of 'norma' pressure
16:43:22 [rbyers]
Jacob: related issue: how to report no support for pressure
16:43:33 [shepazu]
q+ to talk about simulated pressure on touch pads
16:43:46 [rbyers]
... currently we report 0
16:44:16 [rbyers]
Matt: would be nice for applicatons to have one code path for pressure sensitive and non-pressure sensitive devices
16:44:38 [rbyers]
... using 0 means the app must handle the two cases seperately
16:45:00 [rbyers]
Jacob: we want this to be device agnostic - don't want to become a device properties spec
16:45:22 [rbyers]
Jacob/Matt/Rick: agree we should simulate reasonable pressure
16:46:02 [rbyers]
Jacob: in particular, if device does not support pressure, value should be 0 when not in active button state, and 1 when it is
16:47:55 [rbyers]
RESOLUTION: if device does not support pressure, value should be 0 when not in active button state, and 1 when it is
16:48:27 [rbyers]
Jacob: OK, what about max vs. normal?
16:48:48 [rbyers]
Art: could rely on implementation feedback
16:49:01 [rbyers]
Rick: evidence for using 'normal' is not strong
16:49:21 [rbyers]
RESOLUTION: Keep pressure range as speced, but listen for implementation feedback
16:50:24 [rbyers]
shepazu: Can emulate pressure via surface area
16:50:40 [rbyers]
shepazu: should we account for this?
16:51:33 [rbyers]
Jacob: a UA could do this, and web site wouldn't notice. So would be hard to call this not compliant
16:51:58 [rbyers]
shepazu: should we mention this as a note?
16:52:12 [Zakim]
16:52:26 [Zakim]
16:53:04 [rbyers]
Jacob: don't want to go too far in specifying device behavior here
16:53:15 [ArtB]
ACTION: barstow add doug's use case about varying touch pressure to list
16:53:15 [trackbot]
Created ACTION-8 - Add doug's use case about varying touch pressure to list [on Arthur Barstow - due 2012-12-11].
16:54:13 [rbyers]
Topic: 20111 - Define compatibility mapping for touch events
16:57:47 [rbyers]
Art: any objects to touch-events mapping being done in webevents WG instead of pointer events wG?
16:57:49 [rbyers]
16:58:13 [rbyers]
16:58:45 [rbyers]
RESOLUTION: Touch-event mapping is out of scope for pointer events WG, will be handled by web events WG instead
16:59:15 [ArtB]
ACTION: barstow work with Doug and Rick on defining Touch Events mapping in the Web Events WG
16:59:15 [trackbot]
Created ACTION-9 - Work with Doug and Rick on defining Touch Events mapping in the Web Events WG [on Arthur Barstow - due 2012-12-11].
16:59:40 [rbyers]
Topic: 20112 - pointerenter and pointerleave events
16:59:53 [rbyers]
Jacob: no opposition to adding to the spec, assuming it's the same definition as for mouse
17:00:00 [rbyers]
Art: any objections?
17:00:37 [rbyers]
RESOLUTION: Add pointeenter and pointerleave to spec using the same model as mouseenter and mouseleave
17:00:43 [rbyers]
Art: extend to 90 minutes?
17:01:24 [rbyers]
Rick:Jacob: hope/expect we won't have 90 minutes worth of bugs to discuss
17:01:31 [rbyers]
Doug: would have conflict
17:01:55 [rbyers]
Jacob: suggest we leave as is for at least December, and if we're building up a backlog we can revisit in new year
17:02:13 [rbyers]
... if we're active on the mailing list then we can cover more there
17:02:39 [rbyers]
Topic: Pointer Events and Click; thread <>
17:02:53 [rbyers]
Art: seems to have resolved, follow-up on list
17:02:58 [rbyers]
Topic: any other business
17:03:05 [rbyers]
Art: will have meeting next week, Doug will chair
17:03:49 [rbyers]
Rick: I may not be able to make it next week
17:03:53 [rbyers]
Doug: I will keep track
17:03:56 [Zakim]
17:04:06 [rbyers]
... and let the list know if there's a meeting next week
17:04:09 [Zakim]
17:05:14 [rbyers]
Jacob: what do we need to do to get Matt permission to help edit the PE spec?
17:05:28 [rbyers]
Art: all members already have permission
17:05:55 [rbyers]
Jacob: OK, I'll work with Matt to make him an editor
17:06:00 [Zakim]
17:06:01 [Zakim]
17:06:01 [Zakim]
- +1.519.513.aacc
17:06:04 [Zakim]
- +1.770.402.aabb
17:06:05 [Zakim]
17:06:11 [Zakim]
- +1.717.578.aaaa
17:06:12 [Zakim]
RWC_PEWG()11:00AM has ended
17:06:12 [Zakim]
Attendees were +1.717.578.aaaa, +1.770.402.aabb, Matt_Brubeck, Art_Barstow, Olli_Pettay, [Microsoft], +1.519.513.aacc, Doug_Schepers
17:06:18 [ArtB]
RRSAgent, make minutes
17:06:18 [RRSAgent]
I have made the request to generate ArtB
17:06:36 [rbyers]
np Art, a few more times and I may start to get better at it ;-)
17:06:39 [ArtB]
RRSAgent, make log Public
17:06:59 [ArtB]
rbyers - you are doing a GREAT job!
17:07:15 [ArtB]
Scribe: Rick
17:07:20 [ArtB]
RRSAgent, make minutes
17:07:20 [RRSAgent]
I have made the request to generate ArtB
17:07:24 [Asir]
Thank you Rick
17:07:25 [rbyers]
17:08:33 [ArtB]
zakim, bye
17:08:33 [Zakim]
Zakim has left #pointerevents
17:32:16 [ArtB]
rrsagent, bye
17:32:16 [RRSAgent]
I see 4 open action items saved in :
17:32:16 [RRSAgent]
ACTION: Jacob prepare a FPWD and notify Art when it is ready (see [1]
17:32:16 [RRSAgent]
recorded in
17:32:16 [RRSAgent]
ACTION: barstow send Transition Request for FPWD of Pointer Events [2]
17:32:16 [RRSAgent]
recorded in
17:32:16 [RRSAgent]
ACTION: barstow add doug's use case about varying touch pressure to list [3]
17:32:16 [RRSAgent]
recorded in
17:32:16 [RRSAgent]
ACTION: barstow work with Doug and Rick on defining Touch Events mapping in the Web Events WG [4]
17:32:16 [RRSAgent]
recorded in