IRC log of pointerevents on 2013-01-22

Timestamps are in UTC.

15:57:53 [RRSAgent]
RRSAgent has joined #pointerevents
15:57:53 [RRSAgent]
logging to
15:58:05 [ArtB]
Scribe: Art
15:58:05 [ArtB]
ScribeNick: ArtB
15:58:05 [ArtB]
15:58:05 [ArtB]
Date: 22 January 2013
15:58:05 [ArtB]
Chair: Art
15:58:05 [ArtB]
Meeting: Pointer Events WG Voice Conference
15:58:12 [ArtB]
RRSAgent, make minutes
15:58:12 [RRSAgent]
I have made the request to generate ArtB
15:58:17 [ArtB]
RRSAgent, make log Public
15:58:22 [ArtB]
RRSAgent, make minutes
15:58:22 [RRSAgent]
I have made the request to generate ArtB
15:59:24 [Zakim]
15:59:29 [mbrubeck]
Zakim, I am Matt_Brubeck
15:59:29 [Zakim]
ok, mbrubeck, I now associate you with Matt_Brubeck
15:59:50 [Zakim]
+ +1.770.402.aaaa
16:00:03 [Zakim]
+ +1.717.578.aabb
16:00:10 [scott_gonzalez]
Zakim, aabb is me
16:00:10 [Zakim]
+scott_gonzalez; got it
16:01:22 [rbyers]
rbyers has joined #pointerevents
16:01:36 [ArtB]
Present: Art_Barstow, Matt_Brubeck, Jacob_Rossi, Scott_Gonzalez, Rick_Byers, Cathy_Chan
16:01:40 [jrossi2]
Zakin, is me
16:01:55 [Zakim]
16:01:55 [scott_gonzalez]
Zakim, aaaa is jrossi2
16:01:56 [Zakim]
+jrossi2; got it
16:02:18 [Zakim]
+ +1.519.513.aacc
16:02:21 [smaug]
Zakim, [IPcaller] is Olli_Pettay
16:02:21 [Zakim]
+Olli_Pettay; got it
16:02:29 [ArtB]
Present+ Olli_Pettay
16:02:37 [smaug]
Zakim, nick smaug is Olli_Pettau
16:02:37 [Zakim]
sorry, smaug, I do not see a party named 'Olli_Pettau'
16:02:40 [smaug]
Zakim, nick smaug is Olli_Pettay
16:02:40 [Zakim]
ok, smaug, I now associate you with Olli_Pettay
16:03:01 [Zakim]
16:03:01 [ArtB]
Topic: Agenda
16:03:10 [ArtB]
AB: I posted a draft agenda on January 18
16:03:21 [ArtB]
... There are some additional potential topics ...
16:03:26 [ArtB]
... PointerEvents and iframes; Daniel Freedman;
16:03:31 [ArtB]
... Making click/contextmenu use PointerEvent interface; Jacob Rossi;
16:04:21 [ArtB]
AB: do we want to talk about those today?
16:04:43 [ArtB]
RB: touch-action should be added
16:05:00 [ArtB]
Asir: that is part of Tab's email and a bug
16:05:08 [Cathy]
Cathy has joined #pointerevents
16:05:24 [ArtB]
Present+ Asir_Vedamuthu
16:05:37 [asir]
asir has joined #pointerevents
16:05:44 [Zakim]
16:06:10 [Zakim]
16:06:12 [Cathy]
Present+ Cathy_Chan
16:06:22 [ArtB]
ScribeNick: mbrubeck
16:06:26 [ArtB]
Scribe: Matt
16:07:32 [mbrubeck]
Topic: CSSWG Feedback
16:07:52 [mbrubeck]
JR: A quick recap: Art sent a note to the CSS WG asking them to look at the touch-action property in the draft
16:08:10 [mbrubeck]
JR: We got feedback from Tab Atkins and David Baron; I replied back and got some additional replies from Tab.
16:08:14 [ArtB]
Tab Atkins
16:08:20 [ArtB]
David Baron
16:08:32 [mbrubeck]
... We worked out some improved language to describe the processing model, which is different from normal CSS inheritance.
16:09:08 [jrossi2]
16:09:25 [mbrubeck]
... This link shows what we worked out, adding text that talks about the processing model.
16:09:36 [jrossi2]
jrossi2 has joined #pointerevents
16:09:39 [Cathy]
zakim, who's here?
16:09:39 [Zakim]
On the phone I see Art_Barstow, Matt_Brubeck, jrossi2, scott_gonzalez, Olli_Pettay, +1.519.513.aacc, [Microsoft], Cathy, Doug_Schepers
16:09:42 [Zakim]
On IRC I see jrossi2, asir, Cathy, rbyers, RRSAgent, mbrubeck, Zakim, ArtB, AutomatedTester, scott_gonzalez, smaug, shepazu, trackbot, dfreedm
16:09:44 [Cathy]
zakim, drop me
16:09:44 [Zakim]
Cathy is being disconnected
16:09:45 [Zakim]
16:09:54 [Zakim]
16:09:58 [AutomatedTester]
Zakim: drop me
16:10:15 [ArtB]
Present+ Doug_Schepers
16:10:18 [mbrubeck]
... We had a somewhat nuanced description before; the new language is more explicit. The behavior when a user touches is determined by the touch-action property on the touched element and its ancestors.
16:10:58 [mbrubeck]
... The proposal is to add this new language to the spec; I opened a bug for this.
16:11:11 [ArtB]
Bug 20217:
16:11:11 [mbrubeck]
... It'll need a bit of rework in the future if we accept the proposal to add pan-x and pan-y
16:11:27 [mbrubeck]
... but that's not a big deal; we can deal with that when it comes up. I recommend this change.
16:11:34 [mbrubeck]
DS: I really like the new text.
16:11:47 [rbyers_]
rbyers_ has joined #pointerevents
16:12:13 [mbrubeck]
AB: I thought the text was pretty clear as well.
16:12:18 [mbrubeck]
Zakim, who is making noise?
16:12:28 [Zakim]
mbrubeck, listening for 10 seconds I heard sound from the following: Art_Barstow (74%), asir (5%)
16:12:43 [asir]
Text sounds good
16:12:53 [rbyers__]
rbyers__ has joined #pointerevents
16:13:04 [mbrubeck]
AB: Any objections?
16:13:06 [mbrubeck]
16:13:43 [mbrubeck]
RESOLUTION: Accept the text revision proposed by Jacob Rossi with help from the CSS WG as a change to the PE spec.
16:14:03 [mbrubeck]
Topic: iframes and pointer events / mouse events
16:14:28 [ArtB]
Daniel Freedman: <>
16:14:29 [mbrubeck]
JR: The question is, can we do something about the fact that mouse events don't propagate across iframes? Since pointer events are new, can we make them different?
16:14:48 [mbrubeck]
... My gut reaction was "no." That's a fundamental change to a longstanding boundary. We'd need to think very hard about changing it now.
16:15:06 [mbrubeck]
... I engaged in the conversation on the mail thread, but as I started to think about it more offline
16:15:29 [mbrubeck]
... I realized that you need more than just touch events for most use cases, and ultimately you really need a more general way to retarget events across frames.
16:15:51 [mbrubeck]
... There's some discussion about this on the HTML WG (?) and they are talking about reusing the @seamless attribute for iframes.
16:16:04 [mbrubeck]
... My recommendation is to continue the discussion there, and not do something special just for pointer events.
16:16:14 [mbrubeck]
... Talking specifically about iframes is really out of scope for PEWG.
16:16:23 [mbrubeck]
zakim, who is talking?
16:16:35 [Zakim]
mbrubeck, listening for 11 seconds I heard sound from the following: 9 (47%), Art_Barstow (3%)
16:16:56 [mbrubeck]
AB: One of the things I like about pointer events is that they are *not* new, and they inherit from the well-understood mouse events.
16:17:00 [mbrubeck]
zakim, who is talking?
16:17:10 [Zakim]
mbrubeck, listening for 10 seconds I heard sound from the following: Olli_Pettay (92%)
16:17:34 [mbrubeck]
zakim, who is talking?
16:17:45 [Zakim]
mbrubeck, listening for 10 seconds I heard sound from the following: Art_Barstow (4%), scott_gonzalez (98%)
16:17:57 [rbyers]
s/AB: One of the things I like/RB: One of the things I like
16:18:03 [rbyers]
zakim, who is on the phone?
16:18:03 [Zakim]
On the phone I see Art_Barstow, Matt_Brubeck, jrossi2, scott_gonzalez, Olli_Pettay, +1.519.513.aacc, asir, Doug_Schepers, Cathy
16:18:10 [rbyers]
zakim, aacc is me
16:18:11 [Zakim]
+rbyers; got it
16:18:37 [rbyers]
zakim, who is on the phone?
16:18:37 [Zakim]
On the phone I see Art_Barstow, Matt_Brubeck, jrossi2, scott_gonzalez, Olli_Pettay, rbyers, asir, Doug_Schepers, Cathy
16:18:43 [mbrubeck]
SG: Is there a way that a parent page can specifically request that the UA continue to send it pointer events if a touch starts in the parent page and then moves over an iframe?
16:18:48 [rbyers]
zakim, I am Rick_Byers
16:18:48 [Zakim]
sorry, rbyers, I do not see a party named 'Rick_Byers'
16:18:52 [mbrubeck]
... This is already a problem with mouse events.
16:19:13 [mbrubeck]
JR: Yes, I've also been thinking about this use case. It means ads in iframes can interfere with gestures, for example.
16:19:37 [mbrubeck]
... This is a use case for the pointer capture API. This is better than a design where the events come up through the iframe, because it prevents events from going to the frame to begin with.
16:19:43 [mbrubeck]
SG: I agree.
16:20:33 [mbrubeck]
ArtB: I propose a resolution that we will not add support in PE for event retargeting for iframes.
16:20:41 [mbrubeck]
... Do people agree with that?
16:20:45 [mbrubeck]
Zakim, who is talking?
16:20:56 [Zakim]
mbrubeck, listening for 10 seconds I could not identify any sounds
16:21:55 [mbrubeck]
RB: I would change the wording slightly to say that we will not do anything special regarding iframes for pointer events, but we will work with general-purpose mechanisms developed by the DOM / CSS / HTML working groups.
16:22:26 [mbrubeck]
ArtB: We could also say that we won't add any language to v1, but we will add compatibility with future general APIs as a requirement for
16:22:35 [mbrubeck]
ArtB: Any objections to Rick's revised language?
16:22:38 [mbrubeck]
16:22:56 [mbrubeck]
RESOLUTION: The Pointer Events spec will not contain any special features for event retargeting and iframes.
16:23:19 [mbrubeck]
Topic: Pointer Events Bugs; Jacob to lead discussion <>
16:23:23 [jrossi2]
16:23:42 [mbrubeck]
JR: 20217 is a request to add more of IE10's touch action values to the spec.
16:24:00 [mbrubeck]
... We took a long look at this; there are a number of these IE10-supported values.
16:24:24 [jrossi2]
16:24:27 [mbrubeck]
... Some of the more useful, non-gesture-specific ones are pan-x and pan-y, which enable scrolling but only in one direction.
16:25:43 [mbrubeck]
... This proposal would add two new values, pan-x and pan-y, which allow the UA to scroll in just one direction. This may be useful for a 1-dimensional slider control, for example. Then the UA could consume touch events for panning in one direction, but in the other direction the events would all be sent to the slider for changing the slider value.
16:26:14 [mbrubeck]
... This describes the resulting action, not the user input, so it does not specify a particular gesture. For example, panning might be a response to a one-finger gesture or a two-finger gesture.
16:26:36 [mbrubeck]
... I think this addresses a decent bit of use cases, and allows native scrolling in more situations, which is an important win.
16:27:32 [sstewart6]
sstewart6 has joined #pointerevents
16:27:33 [mbrubeck]
RB: I think this is the key part; UAs need to be able to keep panning entirely off the main thread to make it smooth. This allows pages to implement things like image carousels without disabling scrolling completely, or implementing their own scrolling in JS.
16:27:47 [mbrubeck]
ArtB: Any other feedback?
16:27:55 [ArtB]
16:28:25 [mbrubeck]
... Nothing jumps out at me as conflict with our charter.
16:28:45 [mbrubeck]
Zakim, who is talking?
16:28:56 [rbyers]
mbrubeck: that's Doug
16:28:58 [Zakim]
mbrubeck, listening for 12 seconds I could not identify any sounds
16:29:19 [mbrubeck]
DS: This doesn't seem like scope creep to me; it's addressing a specific touch use case.
16:31:11 [mbrubeck]
RB: This is similar to the IndieWG approach to things like panning and zooming (which Apple is participating in). It stays away from specific gestures.
16:31:11 [mbrubeck]
ArtB: Any objections to the proposal?
16:31:35 [mbrubeck]
RESOLUTION: Accept the proposal to add pan-x and pan-y values for the touch-action property.
16:32:07 [mbrubeck]
RB: As a follow-up, is it worth talking specifically about the zoom action? That's the last major thing in the IE implementation but not in the spec.
16:32:27 [mbrubeck]
JR: I can say at least from what we see people using, pan-x and pan-y are the most commonly used in the wild after "auto" and "none."
16:32:43 [mbrubeck]
... I rarely if ever see people use the "zoom" values.
16:32:55 [mbrubeck]
... The IE10 values in particular are too tied to IE10-specific gestures.
16:33:07 [mbrubeck]
RB: What we could consider is having a generic "touch-action: zoom" that's not tied to specific input.
16:33:19 [mbrubeck]
... You say they are rarely used in IE. What do people do to disable zoom on a page?
16:33:49 [mbrubeck]
JR: That's a good point. To clarify, touch-action is about effective hit-testing of regions on a page. It's not about enabling or disabling capabilities. That's kind of nuanced.
16:33:57 [mbrubeck]
... I'll try to give an example.
16:34:32 [mbrubeck]
... "overflow" controls whether something could scroll. "touch-action" determines whether, for individual regions within the scrollable element, whether touches on them can cause it to scroll.
16:35:14 [mbrubeck]
... For zoom, "-ms-content-zoom" controls whether something is zoomable or not. The "touch-action" values determine where touches can trigger a zoom.
16:35:25 [mbrubeck]
... I think zooming is still not a fully-developed use case.
16:35:38 [shepazu]
16:36:01 [mbrubeck]
RB: So the use case is that you'd use it if you want one specific region on the page not to cause a zoom when you touch it.
16:36:22 [mbrubeck]
JR: Right. We need to look into concrete use cases for that, and if they are compelling we can add something gesture-agnostic.
16:36:31 [mbrubeck]
RB: That also seems like something we can easily add in the future.
16:36:57 [mbrubeck]
DS: Do we need to worry about conflicts with current CSS syntax and content written today?
16:37:03 [rbyers_]
rbyers_ has joined #pointerevents
16:37:03 [mbrubeck]
JR: I think that's a valid point.
16:37:20 [mbrubeck]
JR: I'll chat with some folks about this problem, and I get get some feedback pretty quickly.
16:38:13 [mbrubeck]
MB: There's also the CSS Device Adaptation spec (successor to <meta name=viewport>) which lets authors enable or disable zoom for a whole document.
16:38:51 [rbyers]
s/DS: Do we need/RB: Do we need/
16:38:51 [mbrubeck]
DS: One possible use case: inline image/canvas/SVG elements that are zoomable inline, separately from the parent document.
16:39:33 [mbrubeck]
MB: Or a page with an embedded map
16:40:09 [rbyers]
zakim, who is talking?
16:40:20 [Zakim]
rbyers, listening for 10 seconds I heard sound from the following: Doug_Schepers (4%), Matt_Brubeck (63%)
16:41:30 [mbrubeck]
MB: If I touch outside of the map and do a zoom gesture, I want to send commands to update the map. If I touch outside the map and do a zoom gesture, I want to zoom the document (e.g. to make the text more readable).
16:42:42 [mbrubeck]
JR: In the case where you want events for the map, you really want "touch-action: none" because the map will generally be pannable as well.
16:42:45 [mbrubeck]
good point
16:42:56 [mbrubeck]
JR: Google Maps and Bing Maps already use "none" for example.
16:43:11 [abarsto]
abarsto has joined #pointerevents
16:43:19 [mbrubeck]
... There's an interesting thought exercise (which we can continue on the list) about how to make maps use native panning and zooming.
16:43:30 [ArtB]
RRSAgent, make minutes
16:43:30 [RRSAgent]
I have made the request to generate ArtB
16:43:33 [shepazu]
16:43:33 [mbrubeck]
... That's a really difficult problem because of the on-demand loading they do.
16:43:45 [mbrubeck]
... There are many more ingredients we need to solve the problem.
16:44:00 [mbrubeck]
... If we focus on making an inline element like an image or SVG zoomable,
16:44:15 [mbrubeck]
... That's what the content-zooming property does; you can set it on an individual zoomable element.
16:44:32 [mbrubeck]
... If you think of a <div style="overflow:scroll"> as a "sub-scroller"
16:44:40 [shepazu]
q+ to talk about map tiles, and transformations
16:44:43 [mbrubeck]
... "content-zooming" creates a "sub-zoomer"
16:44:53 [mbrubeck]
DS: Is content-zooming on any sort of standards track?
16:45:03 [mbrubeck]
JR: Not yet but I can try to make that happen.
16:45:10 [mbrubeck]
DS: This sounds out of scope for pointer events; it's more general.
16:45:23 [mbrubeck]
JR: Yes, I expect it to need to go through the CSS working group. It interacts with the box model.
16:45:32 [mbrubeck]
Zakim, who is talking?
16:45:42 [rbyers]
that was me
16:45:44 [Zakim]
mbrubeck, listening for 10 seconds I heard sound from the following: jrossi2 (48%), rbyers (15%)
16:46:24 [mbrubeck]
RB: Is there anything we need to do now to accommodate these interactions in the future? For example, leaving some hooks in our syntax and making sure defaults are good for unspecified values?
16:47:03 [mbrubeck]
JR: We've had this discussion at Microsoft too; our canonical example is "what if we added page rotation as a built-in UA gesture?"
16:47:26 [mbrubeck]
... The conclusion is that any additional behaviors beyond panning and zooming would not be included in "auto", e.g. they would not be on by default.
16:47:38 [mbrubeck]
... It definitely behooves us to consider how this can be extended in the future.
16:48:15 [mbrubeck]
DS: This sounds to me like we should keep the CSS WG informed about these ideas, and coordinate with them in case it affects their priorities.
16:48:36 [mbrubeck]
... Jacob, when you go off to look for use cases, make sure they are documented systematically in our wiki and then we can share them with CSS WG.
16:48:49 [mbrubeck]
... and maybe somebody there will be willing to pick up some of this and work on it.
16:49:42 [mbrubeck]
... Some other things to mention: When we're talking about transformations like zoom and rotate, my experience from SVG is that it's very tricky to get the correct pointer coordinates in a situation where one element has been transformed and other elements have not.
16:49:48 [mbrubeck]
... It gets gnarly quickly.
16:50:20 [mbrubeck]
... Let's say you zoom in on an image, and then you want to pan around within that image. The transformations on the image can give you some unexpected results, especially when your pointer moves between transformed and non-transformed areas.
16:50:42 [mbrubeck]
... In DOM 3 Events we abandoned the idea of transformed coordinate properties on events.
16:51:05 [mbrubeck]
... Should we add that to Pointer Events if we are talking about pan and zoom? Or does it belong somewhere in CSS?
16:52:10 [mbrubeck]
... And the final thing I wanted to bring up: KDDI (a Japanese mobile company) has been pushing for tiling and layering in SVG. They have a proposal for tiling large images in a declarative way. This might be relevant to the "native maps" use case above.
16:52:27 [mbrubeck]
... This isn't directly relevant to Pointer Events, but we should keep an eye on it if we want to think about that use case.
16:52:40 [mbrubeck]
JR: Cool, can you send some more information about that?
16:52:56 [mbrubeck]
DS: Any thoughts on the transformed coordinate space?
16:53:27 [mbrubeck]
JR: For basic native transformations (zooming, panning) browsers generally don't expose a different coordinate system. It's not like CSS or SVG transformations where you have nested coordinate systems.
16:54:06 [mbrubeck]
... When you're dealing with events on elements that do have CSS or SVG transforms, being able to get points in different coordinate systems is really important (and it does get nasty really quick), but I think it's better described in the specs that define the transforms.
16:54:23 [mbrubeck]
... I would expect it as a follow-on to the CSS Transforms or SVG specs as a general method, not just for pointer events.
16:54:34 [mbrubeck]
... You might also need these as general utility methods for doing layout, for example.
16:55:38 [mbrubeck]
... Like, consider a canvas that is transformed, but I want to draw a line across it that is horizontal in the "parent" coordinate space.
16:55:56 [mbrubeck]
DS: Exactly, you want to be able to transform coordinates to and from the transformed space.
16:56:36 [mbrubeck]
JR: I think some methods are useful but I'm not sure if there are pointer-event-specific use cases. We should discuss use cases more specifically on the list.
16:57:17 [mbrubeck]
Action: Jacob Rossi to investigate use cases and gesture-agnostic alternatives to IE10's zoom touch-action values.
16:57:17 [trackbot]
Created ACTION-16 - Rossi to investigate use cases and gesture-agnostic alternatives to IE10's zoom touch-action values. [on Jacob Rossi - due 2013-01-29].
16:57:23 [rbyers_]
rbyers_ has joined #pointerevents
16:57:40 [mbrubeck]
JR: Doug, do you want to send a mail to the list about the use cases you have in mind?
16:58:07 [mbrubeck]
... For support for transforming coordinates?
16:58:20 [mbrubeck]
DS: I'll raise this with the SVG working group instead.
16:58:43 [mbrubeck]
Action: Doug Schepers to raise issue with SVG WG about methods/properties to transform coordinates within transformed elements.
16:58:44 [trackbot]
Created ACTION-17 - Schepers to raise issue with SVG WG about methods/properties to transform coordinates within transformed elements. [on Doug Schepers - due 2013-01-29].
16:58:57 [jrossi2]
16:58:59 [ArtB]
s/Bug 20710:"> 20710:
16:59:59 [mbrubeck]
JR: I encourage folks to take a look at this bug and join the discussion.
17:00:19 [mbrubeck]
JR: I don't think we have time to talk about hover menus on this call. Other than that, I think that's all the bugs.
17:00:34 [ArtB]
RRSAgent, make minutes
17:00:34 [RRSAgent]
I have made the request to generate ArtB
17:04:27 [mbrubeck]
s/good point/MB: good point
17:04:44 [mbrubeck]
RRSAgent, make minutes
17:04:44 [RRSAgent]
I have made the request to generate mbrubeck
17:07:18 [mbrubeck]
ArtB: Any other business?
17:07:29 [mbrubeck]
ArtB: Let's plan on a call at the same time next week, as long as we have topics.
17:07:53 [mbrubeck]
ArtB: Okay, that's it everyone. Thanks!
17:07:55 [Zakim]
17:07:56 [Zakim]
17:07:56 [Zakim]
17:07:59 [Zakim]
17:08:00 [Zakim]
17:08:03 [Zakim]
17:08:06 [mbrubeck]
s/ArtB: Any/AB: Any
17:08:09 [Zakim]
17:08:14 [mbrubeck]
s/ArtB: Let's plan/AB: Let's plan
17:08:16 [ArtB]
RRSAgent, make minutes
17:08:16 [RRSAgent]
I have made the request to generate ArtB
17:08:23 [mbrubeck]
s/ArtB: Okay,/AB: Okay,
17:08:47 [Zakim]
17:13:48 [Zakim]
disconnecting the lone participant, asir, in RWC_PEWG()11:00AM
17:13:49 [Zakim]
RWC_PEWG()11:00AM has ended
17:13:49 [Zakim]
Attendees were Art_Barstow, Matt_Brubeck, +1.770.402.aaaa, +1.717.578.aabb, scott_gonzalez, jrossi2, +1.519.513.aacc, Olli_Pettay, Cathy, Doug_Schepers, asir, rbyers
17:15:57 [abarsto]
abarsto has joined #pointerevents
17:26:31 [rbyers]
rbyers has joined #pointerevents
17:27:31 [rbyers]
rbyers has joined #pointerevents
17:43:51 [mbrubeck]
mbrubeck has joined #pointerevents
17:56:43 [rbyers]
rbyers has joined #pointerevents
19:12:06 [Zakim]
Zakim has left #pointerevents
19:19:27 [mbrubeck]
mbrubeck has joined #pointerevents
20:04:14 [rbyers]
rbyers has joined #pointerevents
21:59:02 [mbrubeck]
mbrubeck has joined #pointerevents
22:22:22 [mbrubeck]
mbrubeck has joined #pointerevents
22:42:28 [smaug_]
smaug_ has joined #pointerevents
23:53:41 [mbrubeck]
mbrubeck has joined #pointerevents