Draft minutes: 2015 Jan 27 call

The draft minutes from the January 27th voice conference are available here
<http://www.w3.org/2015/01/27-touchevents-minutes.html> (on our Minutes
wiki page <https://www.w3.org/community/touchevents/wiki/Minutes>) and
copied below. If you have any comments, corrections, etc., please send them
to the public-touchevents mail list before Feb 3rd. In the absence of any
changes, these minutes will be considered approved.

Thanks,
   Rick

- DRAFT -Touch Events Community Group
27 Jan 2015

Agenda
<https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0090.html>

See also: IRC log <http://www.w3.org/2015/01/27-touchevents-irc>
Attendees
PresentMatt_Brubeck, Olli_Pettay, Scott_Gonzalez, Asir_Vedamuthu,
Rick_Byers, Tim_Dresser, Mustaq_Ahmed, Doug_SchepersRegretsArt_Barstow,
Patrick_LaukeChairrbyersScribetdresser
Contents

   - Topics <https://www.w3.org/2015/01/27-touchevents-minutes.html#agenda>
      1. Identifying mouse events derived from touch
      <https://www.w3.org/2015/01/27-touchevents-minutes.html#item01>
      2. Identifying touch events that can trigger scrolling
      <https://www.w3.org/2015/01/27-touchevents-minutes.html#item02>
      3. Rotation angle / tilt definitions in TEE
      <https://www.w3.org/2015/01/27-touchevents-minutes.html#item03>
      4. Writing
      <https://www.w3.org/2015/01/27-touchevents-minutes.html#item04>
      5. Process for landing changes in GitHub
      <https://www.w3.org/2015/01/27-touchevents-minutes.html#item05>
      6. Plan for next two weeks of calls?
      <https://www.w3.org/2015/01/27-touchevents-minutes.html#item06>
   - Summary of Action Items
   <https://www.w3.org/2015/01/27-touchevents-minutes.html#ActionSummary>

------------------------------

rbyers: Agenda should include a discussion of what we should block checkins
on for GitHub.
Identifying mouse events derived from touch

<rbyers>
https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0065.html

<rbyers>
https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0078.html

rbyers: Last call, jrossi argued for "FiredFrom" api, Anne had some
objections to that Api, as it isn't well defined.
... On the list, I proposed a "sourcedevice" api, which would let you
determine if an event came from a device which fires touch events.
... Maybe we should punt until jrossi is here.
... Punting until next call with jrossi, or resolve over email.
Identifying touch events that can trigger scrolling

<rbyers>
https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0058.html

rbyers: We talked about this two weeks ago, came up with a tentative Api, I
wrote up a doc for it.
... High level, touch events have a "defaultstartsmanipulation" bit, which
indicates if you're about to lose control over touch events.
... It's important that we come up with something that Safari can implement
too.

asir: Do we need something like this for other event types as well?

<asir> olli has joined #touchevents

rbyers: We don't have the same kind of state machine with other input types.

olli: It could be useful for pointer events, and wheel events.

rbyers: Chrome's implementation here is really simple, but probably worse
than the implementation Firefox has. This isn't necessary for Chrome's
current implementation.
... This is somewhat similar to touch action, it could also apply to wheel
events.
... jrossi argued that this was more important for touch because touch is
common on low power devices, and touch requires lower latency.
Rotation angle / tilt definitions in TEE

<rbyers>
https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0088.html

rbyers: Samsung recently started contributing, which is good to see.
... They believe that they should be firing touch events for stylus, for
the 90% case, but they should enable websites expecting stylus input to
take advantage of stylus specific features.

shepazu: Wacom is also interested in this.
... Stylus is very important.
... If you use touch for stylus, you'll run into problems with multiple
simultaneous modalities (touch and pen at the same time).
... There was an object from a W3C member against publishing pointer events
as a formal recommendation.
... They didn't want the fragmentation between touch and pointer events.
... This objection will be raised to the w3c director, but can be
delegated. In this case it was delegated to another w3c staff .
... We don't know yet what the official decision will be on that. I expect
pointer events will be published as a recommendation.
... One of the points raised in the objection was that there is currently
no other way to support pen and touch on the web.
... We could do that here, but I think we want to be careful that we don't
just reinvent pointer events and call it touch events.

<rbyers> One possible path (inspired by pointer events) for touch events to
address the multi-device scenario:
https://docs.google.com/a/chromium.org/document/d/1x-yE4CmTZlZQXea4_FPjgly5TOvF28UBNs9gZ5aGUhg/edit

<smaug> (extending an API has fragmentation issues just like adding a new
API)

rbyers: We'll probably want to talk about extending touch events more
thoroughly in the future, but for now we do need to respond to Samsung.
... Should we say that adding the stylus specific attributes to touch
events are out of scope for now, or should we tell them we'll get back to
them in a month?

<mbrubeck> We started adding pen attributes in the abandoned "Touch Events
v2" spec https://dvcs.w3.org/hg/webevents/raw-file/default/touchevents.html

shepazu: I would say that it's definitely something that we need to solve
for the platform, and long term, we'll consider putting it in touch events.

rbyers: Does anyone object with shepazu's wording?
... I'll reply to the thread then.
Writing

shepazu: Should we have an Api for converting handwriting to text?

<rbyers> http://www.w3.org/TR/ime-api/

rbyers: I don't have much expertise in this space, at Google, our IME team
has more context here.

shepazu: Does it seem like this would be useful/possible for the web?

olli: This could be a JS library pretty easily.

rbyers: What's relevant for this group is, "If you want to support this
scenario, how would your low-level input apis change?"
... We'd need to expose the historical events. You don't want to optimize
for latency in this case, you want to optimize for accuracy.

shepazu: You could do this with a JS library, or an external service. I'll
talk to the IME folks.

rbyers: You're right that we do want to enable this offline, you may want
to make sure your handwriting isn't being sent across the web.
Process for landing changes in GitHub

<rbyers>
https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0094.html

rbyers: Doug, can you tell us anything about how other groups are using
GitHub?

shepazu: Every group is different.
... I'd take pull requests from anyone, and authorized people would
integrate the pull requests.
... For editors, the process should be "commit -> review" for everyone
else, the process should be "review -> commit"
... The editor can always come to the group and ask for feedback.
... Does that seem reasonable?

rbyers: When you say that for other folks it would be "review->commit", it
doesn't need to be a conference call does it? It can just be an editor
looking at it?

shepazu: We don't need to look at every little change on the conference
call.

rbyers: Here's a proposal:
... If any of us want to land a patch, create a pull request, and then an
editor needs to review it.
... Only editors can land patches, and all pull requests will be sent to
the list.
... We can always revert changes if there is contention.

<mbrubeck> +1

shepazu: I agree, and think we should accept that.

mbrubeck: I agree, we should keep it light, we can always revert things.

*RESOLUTION: use proposed method for landing patches.*

shepazu: specs.webplatform.org could pull the spec from GitHub, it will
provide a nice way for getting feedback.

rbyers: Right now editors of the extension note are listed as rbyers,
sangwhan, shepazu, mbrubeck, is this a good list of editors?

shepazu: Anyone active in the group, making good pull requests, who is a
member of the CG should probably be made an editor.
... We should have art on there.
... rbyers should be an editor of v1 errata.

<mbrubeck> rbyers for editor!

rbyers: We want to make sure people like Patrick can easily make a bunch of
improvements.

shepazu: Perhaps Patrick should also be an editor.
Plan for next two weeks of calls?

rbyers: I'll be in Australia for the next 2 calls. Should we meet anyways?
... Or we can just meet again in 3 weeks.

shepazu: We might as well cancel.
... rbyers and jrossi are both necessary.