See also: IRC log
rbyers: Agenda should include a discussion of what we should block checkins on for GitHub.
<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.
<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.
<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.
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.
<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.
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.
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/asir/olli/ Succeeded: s/??/shepazu/ Succeeded: s/yandex/a W3C member/ Succeeded: s/(Ralph)// Succeeded: s/your api's/your low-level input apis/ WARNING: Possible internal error: join/leave lines remaining: <asir> olli has joined #touchevents No ScribeNick specified. Guessing ScribeNick: tdresser Inferring Scribes: tdresser Default Present: Matt_Brubeck, Scott_Gonzalez, rbyers, +1.571.426.aaaa, Doug_Schepers, Olli_Pettay Present: Matt_Brubeck Olli_Pettay Scott_Gonzalez Asir_Vedamuthu Rick_Byers Tim_Dresser Mustaq_Ahmed Doug_Schepers Regrets: Art_Barstow Patrick_Lauke Agenda: https://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0090.html Got date from IRC log name: 27 Jan 2015 Guessing minutes URL: http://www.w3.org/2015/01/27-touchevents-minutes.html People with action items: WARNING: Possible internal error: join/leave lines remaining: <asir> olli has joined #touchevents WARNING: Possible internal error: join/leave lines remaining: <asir> olli has joined #touchevents[End of scribe.perl diagnostic output]