See also: IRC log
<ArtB> Scribe: Art
<ArtB> ScribeNick: ArtB
Date: 22 January 2013
<jrossi2> Zakin, +1.770.402.aaa is me
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
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.
<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.
<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!
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/AB: One of the things I like/RB: One of the things I like/ Succeeded: s/DS: Do we need/RB: Do we need/ WARNING: Bad s/// command: 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/ Succeeded: s/good point/MB: good point/ Succeeded: s/ArtB: Any/AB: Any/ Succeeded: s/ArtB: Let's plan/AB: Let's plan/ Found Scribe: Art Found ScribeNick: ArtB Found ScribeNick: mbrubeck Found Scribe: Matt Scribes: Art, Matt ScribeNicks: ArtB, mbrubeck Present: Art_Barstow Matt_Brubeck Jacob_Rossi Scott_Gonzalez Rick_Byers Cathy_Chan Olli_Pettay Asir_Vedamuthu Doug_Schepers Agenda: http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0023.html Found Date: 22 Jan 2013 Guessing minutes URL: http://www.w3.org/2013/01/22-pointerevents-minutes.html People with action items: doug jacob rossi schepers[End of scribe.perl diagnostic output]