Draft minutes: 22 January 2013 call

The draft minutes from the January 22 voice conference are available at 
<http://www.w3.org/2013/01/22-pointerevents-minutes.html> and copied below.

WG Members - if you have any comments, corrections, etc., please send 
them to the public-pointer-events mail list before 22 January 2013. In 
the absence of any changes, these minutes will be considered approved.

Thanks to Matt for Scribing this meeting.

-AB

[1]W3C

[1] http://www.w3.org/

- DRAFT -

Pointer Events WG Voice Conference

22 Jan 2013

[2]Agenda

[2] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0023.html

See also: [3]IRC log

[3] http://www.w3.org/2013/01/22-pointerevents-irc

Attendees

Present
Art_Barstow, Matt_Brubeck, Jacob_Rossi, Scott_Gonzalez,
Rick_Byers, Cathy_Chan, Olli_Pettay, Asir_Vedamuthu,
Doug_Schepers

Regrets
Chair
Art

Scribe
Art, Matt

Contents

* [4]Topics
1. [5]Agenda
2. [6]CSSWG Feedback
3. [7]iframes and pointer events / mouse events
4. [8]Pointer Events Bugs; Jacob to lead discussion
<http://tinyurl.com/Bugs-PointerEvents>
* [9]Summary of Action Items
__________________________________________________________

<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
[10]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0023.html.
... There are some additional potential topics ...
... PointerEvents and iframes; Daniel Freedman;
[11]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0019.html
... Making click/contextmenu use PointerEvent interface; Jacob
Rossi;
[12]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0024.html
... do we want to talk about those today?

[10] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0023.html.
[11] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0019.html
[12] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0024.html

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
[13]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0016.html

[13] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0016.html

<ArtB> David Baron
[14]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0018.html

[14] 
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>
[15]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0029.html

[15] 
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:
[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217

[16] 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:
<[17]http://lists.w3.org/Archives/Public/public-pointer-events/
2013JanMar/0019.html>

[17] 
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0019.html%3E

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
<[18]http://tinyurl.com/Bugs-PointerEvents>

[18] http://tinyurl.com/Bugs-PointerEvents%3E

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

[19] 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>
[20]http://lists.w3.org/Archives/Public/public-pointer-events/2
013JanMar/0034.html

[20] 
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> … [21]http://www.w3.org/2012/pointerevents/charter/

[21] 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
[22]http://www.w3.org/2013/01/22-pointerevents-minutes.html#act
ion01]

<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
[23]http://www.w3.org/2013/01/22-pointerevents-minutes.html#act
ion02]

<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>
[24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

[24] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20236

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

[25] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20217/Bug
[26] 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!

Summary of Action Items

[NEW] ACTION: Doug Schepers to raise issue with SVG WG about
methods/properties to transform coordinates within transformed
elements. [recorded in
[27]http://www.w3.org/2013/01/22-pointerevents-minutes.html#act
ion02]
[NEW] ACTION: Jacob Rossi to investigate use cases and
gesture-agnostic alternatives to IE10's zoom touch-action
values. [recorded in
[28]http://www.w3.org/2013/01/22-pointerevents-minutes.html#act
ion01]

[End of minutes]

Received on Tuesday, 22 January 2013 17:11:23 UTC