Pointer Events WG Voice Conference -- 22 Jan 2013

<ArtB> Scribe: Art

<ArtB> ScribeNick: ArtB

Date: 22 January 2013

<jrossi2> Zakin, +1.770.402.aaa is me

Agenda

AB: I posted a draft agenda on January 18 http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0023.html.
... There are some additional potential topics ...
... PointerEvents and iframes; Daniel Freedman; http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0019.html
... Making click/contextmenu use PointerEvent interface; Jacob Rossi; http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0024.html
... do we want to talk about those today?

RB: touch-action should be added

Asir: that is part of Tab's email and a bug

<scribe> ScribeNick: mbrubeck

<ArtB> Scribe: Matt

CSSWG Feedback

JR: A quick recap: Art sent a note to the CSS WG asking them to look at the touch-action property in the draft
... We got feedback from Tab Atkins and David Baron; I replied back and got some additional replies from Tab.

<ArtB> Tab Atkins http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0016.html

<ArtB> David Baron http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0018.html

JR: We worked out some improved language to describe the processing model, which is different from normal CSS inheritance.

<jrossi2> http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0029.html

JR: This link shows what we worked out, adding text that talks about the processing model.

<AutomatedTester> Zakim: drop me

JR: 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.
... The proposal is to add this new language to the spec; I opened a bug for this.

<ArtB> Bug 20217: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217

JR: It'll need a bit of rework in the future if we accept the proposal to add pan-x and pan-y
... but that's not a big deal; we can deal with that when it comes up. I recommend this change.

DS: I really like the new text.

AB: I thought the text was pretty clear as well.

<asir> Text sounds good

AB: Any objections?

[none]

RESOLUTION: Accept the text revision proposed by Jacob Rossi with help from the CSS WG as a change to the PE spec.

iframes and pointer events / mouse events

<ArtB> Daniel Freedman: <http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0019.html>

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?
... 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.
... I engaged in the conversation on the mail thread, but as I started to think about it more offline
... 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.
... There's some discussion about this on the HTML WG (?) and they are talking about reusing the @seamless attribute for iframes.
... My recommendation is to continue the discussion there, and not do something special just for pointer events.
... Talking specifically about iframes is really out of scope for PEWG.

RB: One of the things I like about pointer events is that they are *not* new, and they inherit from the well-understood mouse events.

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?
... This is already a problem with mouse events.

JR: Yes, I've also been thinking about this use case. It means ads in iframes can interfere with gestures, for example.
... 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.

SG: I agree.

ArtB: I propose a resolution that we will not add support in PE for event retargeting for iframes.
... Do people agree with that?

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.

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 v.next.
... Any objections to Rick's revised language?

[none]

RESOLUTION: The Pointer Events spec will not contain any special features for event retargeting and iframes.

Pointer Events Bugs; Jacob to lead discussion <http://tinyurl.com/Bugs-PointerEvents>

<jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217

JR: 20217 is a request to add more of IE10's touch action values to the spec.
... We took a long look at this; there are a number of these IE10-supported values.

<jrossi2> http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0034.html

JR: Some of the more useful, non-gesture-specific ones are pan-x and pan-y, which enable scrolling but only in one direction.
... 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.
... 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.
... I think this addresses a decent bit of use cases, and allows native scrolling in more situations, which is an important win.

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.

ArtB: Any other feedback?

<ArtB> … http://www.w3.org/2012/pointerevents/charter/

ArtB: Nothing jumps out at me as conflict with our charter.

<rbyers> mbrubeck: that's Doug

DS: This doesn't seem like scope creep to me; it's addressing a specific touch use case.

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.

ArtB: Any objections to the proposal?

RESOLUTION: Accept the proposal to add pan-x and pan-y values for the touch-action property.

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.

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."
... I rarely if ever see people use the "zoom" values.
... The IE10 values in particular are too tied to IE10-specific gestures.

RB: What we could consider is having a generic "touch-ACTION: zoom" that's not tied to specific input.
... You say they are rarely used in IE. What do people do to disable zoom on a page?

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.
... I'll try to give an example.
... "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.
... For zoom, "-ms-content-zoom" controls whether something is zoomable or not. The "touch-action" values determine where touches can trigger a zoom.
... I think zooming is still not a fully-developed use case.

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.

JR: Right. We need to look into concrete use cases for that, and if they are compelling we can add something gesture-agnostic.

RB: That also seems like something we can easily add in the future.
... Do we need to worry about conflicts with current CSS syntax and content written today?

JR: I think that's a valid point.
... I'll chat with some folks about this problem, and I get get some feedback pretty quickly.

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.

DS: One possible use case: inline image/canvas/SVG elements that are zoomable inline, separately from the parent document.

MB: Or a page with an embedded map
... 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).

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.

MB: good point

JR: Google Maps and Bing Maps already use "none" for example.
... There's an interesting thought exercise (which we can continue on the list) about how to make maps use native panning and zooming.
... That's a really difficult problem because of the on-demand loading they do.
... There are many more ingredients we need to solve the problem.
... If we focus on making an inline element like an image or SVG zoomable,
... That's what the content-zooming property does; you can set it on an individual zoomable element.
... If you think of a <div style="overflow:scroll"> as a "sub-scroller"
... "content-zooming" creates a "sub-zoomer"

DS: Is content-zooming on any sort of standards track?

JR: Not yet but I can try to make that happen.

DS: This sounds out of scope for pointer events; it's more general.

JR: Yes, I expect it to need to go through the CSS working group. It interacts with the box model.

<rbyers> that was me

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?

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?"
... 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.
... It definitely behooves us to consider how this can be extended in the future.

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.
... 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.
... and maybe somebody there will be willing to pick up some of this and work on it.
... 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.
... It gets gnarly quickly.
... 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.
... In DOM 3 Events we abandoned the idea of transformed coordinate properties on events.
... Should we add that to Pointer Events if we are talking about pan and zoom? Or does it belong somewhere in CSS?
... 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.
... 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.

JR: Cool, can you send some more information about that?

DS: Any thoughts on the transformed coordinate space?

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.
... 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.
... I would expect it as a follow-on to the CSS Transforms or SVG specs as a general method, not just for pointer events.
... You might also need these as general utility methods for doing layout, for example.
... Like, consider a canvas that is transformed, but I want to draw a line across it that is horizontal in the "parent" coordinate space.

DS: Exactly, you want to be able to transform coordinates to and from the transformed space.

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.

<scribe> ACTION: Jacob Rossi to investigate use cases and gesture-agnostic alternatives to IE10's zoom touch-action values. [recorded in http://www.w3.org/2013/01/22-pointerevents-minutes.html#action01]

<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].

JR: Doug, do you want to send a mail to the list about the use cases you have in mind?
... For support for transforming coordinates?

DS: I'll raise this with the SVG working group instead.

<scribe> ACTION: Doug Schepers to raise issue with SVG WG about methods/properties to transform coordinates within transformed elements. [recorded in http://www.w3.org/2013/01/22-pointerevents-minutes.html#action02]

<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].

<jrossi2> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

<ArtB> s/Bug 20710: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217/Bug 20710: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217/

JR: I encourage folks to take a look at this bug and join the discussion.
... 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.

AB: Any other business?
... Let's plan on a call at the same time next week, as long as we have topics.

ArtB: Okay, that's it everyone. Thanks!

- DRAFT -

Pointer Events WG Voice Conference

22 Jan 2013

Attendees

Contents

Agenda

CSSWG Feedback

iframes and pointer events / mouse events

Pointer Events Bugs; Jacob to lead discussion <http://tinyurl.com/Bugs-PointerEvents>

Summary of Action Items

Scribe.perl diagnostic output