Touch Events Community Group -- 13 Jan 2015

<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 $//

- DRAFT -

Touch Events Community Group

13 Jan 2015

Attendees

Contents

Feedback on updated proposal for Identifying mouse events derived from touch

Identifying touch events that will trigger a tap / click

Summary of Action Items

Scribe.perl diagnostic output