Draft minutes: 2015 Jan 13 call

The draft minutes from the January 13th voice conference are available here
<http://www.w3.org/2015/01/13-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 Jan 20th. In the absence of any
changes, these minutes will be considered approved.

Thanks,
   Rick

- DRAFT -Touch Events Community Group13 Jan 2015

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

See also: IRC log <http://www.w3.org/2015/01/13-touchevents-irc>
Attendees
PresentJacob_Rossi, Scott_Gonzalez, Rick_Byers,
Tim_DresserRegretsPatrick_Lauke,
Olli_PettayChairRick_ByersScribeTim_Dresser
Contents

   - Topics <http://www.w3.org/2015/01/13-touchevents-minutes.html#agenda>
      1. Feedback on updated proposal for Identifying mouse events derived
      from touch
      <http://www.w3.org/2015/01/13-touchevents-minutes.html#item01>
      2. Identifying touch events that will trigger a tap / click
      <http://www.w3.org/2015/01/13-touchevents-minutes.html#item02>
   - Summary of Action Items
   <http://www.w3.org/2015/01/13-touchevents-minutes.html#ActionSummary>

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

<rbyers> Scribe: Tim_Dresser

<rbyers> ScribeNick: tdresser

rbyers: Anything else on the agenda?

[none]

<rbyers> touch
Feedback on updated proposal for Identifying mouse events derived from touch

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

rbyers: Should we use constructor names, or interface names?

jrossi: We need flexibility to enable this with pointer events.
... If you were a browser that only supported pointer events, would you
return true on mouseevent.FiredFrom("TouchEvent")?

rbyers: No, it's about "what code have we triggered in our application?,"
not "what input device did this come from?".
... The goal is to prevent double handling, not figuring out the input
device.
... We want this to be hard to misuse. What questions might developers be
trying to ask which would cause them to misuse this api?

jrossi: Looks reasonable.

rbyers: What about mouseevent.FiredFrom("MouseEvent")?
... We can just return always false.

jrossi: Always false or always true is fine with me - false makes more
sense.

rbyers: FiredFrom means: would have been suppressed if that other event had
been cancelled.

jrossi: Not sure it's always cancellable, for example, you may not be able
to prevent a click event by cancelling a Keyboard event.

rbyers: Can the definition be up to interpretation then? This is kind of
fuzzy.

jrossi: +1
... It is still the default action, it's just that sometimes default
actions aren't cancellable.

rbyers: Any other examples of where FiredFrom would return true?

jrossi: Maybe IME composition events?

mbrubeck: How about the click event? Is it FiredFrom("MouseEvent")?

rbyers: Maybe clickEvent.firedFrom("MouseEvent") would be useful.
... When you press enter on a checkbox, do you get synthetic mouse events?

jrossi: It probably varies.

rbyers: If we don't have a definite use case, lets say
clickevent.FiredFrom("MouseEvent") is false.

mbrubeck: +1

rbyers: Is a wheel event fired from a mousewheel event?

jrossi: There's something like three different events types for mouse wheel
input.
... wheel event, mousewheel event, and some other interface for the third
one. They each have different properties.

rbyers: In blink we don't fire one as the default action of another. It's
something like "If there's a wheel event handler, don't fire the legacy
events"

scott_gonzalez: I just tested, that looks correct.

rbyers: So to prevent double handling, this api could be useful here.
... So I should make these tweaks and send this out?

jrossi: We should write an idl.
... That spec is going to change names today.

rbyers: Have you talked about this with Travis?
... I'll bring this up with some internal google people too.

jrossi: Spacebar presses don't appear to cause synthetic mouse events.

<jrossi> http://jsbin.com/watina/57/edit?html,js,console,output

jrossi: It could be a problem in the same way that we had problems with
hasFeature.
... Browsers will need to return different values, making it a fragile api.
... As long as we hit the core scenarios, we should be fine.

rbyers: +1
... Whenever we define a new api, we should try to ship a polyfill first.
Maybe we should do that here?
... Touch should be easy to polyfill, but polyfilling all the common cases
would be a lot of work.

jrossi: Don't you need to make assumptions?

rbyers: Yes, you do need to make assumptions.

jrossi: I don't think we need to make a polyfill, this is a low level
primitive that will enable other polyfills.

rbyers: Right, this is a primitive, sounds good.

scott_gonzalez: In jquery, we have an autocomplete component where an
element appears under the mouse cursor, which causes synthetic mouse
events. Is there a way we could use this api to determine where the mouse
events came from?

rbyers: This sounds more similar to the sourceDevice problem.
... Maybe we should also be talking about that at some point?
... This is part of the reason why we have different co-ordinates passed
with the events. You can sometimes check if the event co-ordinates changed
to solve this.

scott_gonzalez: What we do here is look at when keys are pressed in the
text input, and then set a timer, and within that timer we ignore the mouse
events.

<scott_gonzalez>
http://dev-test.nemikor.com/behavior/mouseover-when-element-is-shown.html

scott_gonzalez: The behavior is different across browsers.

rbyers: What does PointerEvents give you for the pointer type?

jrossi: We don't have this issue. If I understand correctly, chrome has a
timer that synthesizes these mouse events.

rbyers: When we don't have this behavior, we get people complaining that
you don't get mouse hover when you'd expect to get mouse hover.

jrossi: You can make the opposite argument, where you're getting mouse move
events when the mouse didn't work.
... I'm not in opposition to that behavior, we just haven't gotten around
to it.
... You aren't going to have this problem with input modalities other than
mouse, as they jiggle a lot.
Identifying touch events that will trigger a tap / click

rbyers: Let's come back to this at some point, when we talk about
SourceDevice.

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

rbyers: Main scenario I want to solve here is to identify when a touch end
event will result in a tap.
... Lots of sites try to do this already, using some heuristics, and there
can be some subtle bugs.
... At the very least, having a bit in the touch event that says "a tap
will occur" will be valuable.
... Safari proposed a rich api that exposed the state of the gesture
recognizer through the touch events.
... There would be some property that said "Here's the events that can
happen if you don't cancel this event."

mbrubeck: This is basically exposing the browser gesture recognition state
machine?

rbyers: Not the full state machine, but exposing the key state transitions.
... I'm not sure how much value there is in gestures other than tap.
... I can see some value in the other gestures though. It would be tricky
to detect them in JS.

jrossi: I'm not sure this will work successfully unless we add
interoperable definitions of what these gestures mean, which isn't going to
happen.
... There may be a more tractable smaller set of events we can deal with.

mbrubeck: Click seems feasible, pan seems trickier because there's a lot
more variation in browser implementations.
... Same thing with pinch.

jrossi: Are there click scenarios other than the fastclick scenario?
Fastclick should go away eventually anyways, with touch action.
... Are we just solving the problem twice?

rbyers: The click and pan cases are interlinked. At least in Chrome,
they're mutually exclusive.

jrossi: We've definitely seen people looking at the delta from touch start,
and try to identify when a pan is starting.
... This happens when you're implementing your own panning, and you want to
know that a pan has started as early as possible.

rbyers: Maybe I'm conflating two problems here.
... We don't want sites to use heuristics to identify taps.
... We suppress some touchmoves, because some web devs assume that they can
make decisions based on the first touchmove sent.
... The first touchmove may not be a good predictor of what the finger is
going to do.
... Our touchmove suppression is confusing here - we'd like a better
solution that let's us give the application all the events.

jrossi: The most common scenario I've seen for panning is when a web dev is
trying to determine the direction of a pan.
... Touch action enables this though.
... This happens when someone wants to prevent scrolling in one direction,
but not the other.

rbyers: I've seen this scenario a lot too.
... A bunch of people were excited that touch action would solve this, but
we had to delay shipping touch action. Touch action with Chrome's new model
of touch event dispatching doesn't solve this problem, since the page
doesn't know when scrolling has started.

jrossi: You need something like the awfully named
"ManipulationStateChanged" event.

rbyers: That's the event fired when you start scrolling?

jrossi: Yes.

rbyers: So we want to identify when an event is going to occur. When is
ManipulationStateChanged dispatched?

jrossi: Today in IE it would come directly after pointercancel and
touchcancel, starting the pan.
... In our implementation where we dispatch touch events during scrolling,
it fires at the same time, but we don't fire a touchcancel.
... It let's you solve the carousel case with touch action and
ManipulationStateChanged.
... You ignore touch events when ManipulationStateChanged has indicated
that scroll has started.

rbyers: The cancellable bit doesn't solve this problem. If you're at the
top of the page and you scroll upwards, those events are set as cancelable.
... It enables customized overscroll - when you reach the top of the
document you start pulling down some header.
... We could solve this just for click - the dual of firedFrom, something
like willFire. But the most interesting case is probably identifying when a
scroll is about to happen.

jrossi: We need to nail down the exact use cases here.

rbyers: Safari's proposal was that this would be true if the touch event
will cause the gesture to occur.
... It's the transition to when a scroll is started - it's a notification
that this is the developers last chance to cancel the gesture.
... We might be able to accomplish this using the same api that jrossi
proposed.
... It's willFire("ScrollEvent").
... Though scrollevent is a UIEvent, which is annoying.
... After all of this discussion, should we be trying to solve the problem
of identifying touches that will result in clicks?
... Ideally we don't try to predict a click, we just use the click.

jrossi: Is this worth posting to specifiction, where we can get some more
feedback?

rbyers: The click problem doesn't seem compelling enough with the data
we've got right now.
... Scrolling is a separate issue, and I've been conflating them.
... I think I have enough evidence that the scrolling issue is worth trying
to solve.
... jrossi, do you think there is a solution to that problem that you could
participate in?

jrossi: Yes.

rbyers: So what about just touchEvent.canStartScroll?
... I would like to go with a pattern we can extend than an api that forces
us to handle all the cases.

<rbyers>
https://groups.google.com/a/chromium.org/forum/#!searchin/input-dev/mattgaunt/input-dev/Bo5FyTLljwY/aZVWhHV04AwJ

rbyers: We're out of time. How about I send a concrete proposal to the list?
... I'll try to get agreement with some internal folks, and we can talk
about it more next week.

<scott_gonzalez> I had to drop off as I have another meeting that just
started.

rbyers: Shouldn't this be a problem for the pointer event polyfill as well?

jrossi: I don't think so.

rbyers: You've got to know when to send the pointercancel.

jrossi: You can look for when a scroll occurs.

rbyers: If you're at the top of the page and scroll up, then chromium gives
you no indication that a scroll has started.
... Scott, does this sound valuable?
... We'll talk about this next week.
... mbrubeck, some of this would previously have been hard for us to
implement, would this stuff be hard for firefox?

mbrubeck: I'll run it by the people who are involved in that code.

<rbyers> s/^Topic:.*mouse events derived from$//

<rbyers> s/^Topic:.*mouse events derived from $//