Draft minutes: 2015 Feb 17 call

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

Next meeting March 3rd.

Thanks,
   Rick

- DRAFT -Touch Events Community Group17 Feb 2015

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

See also: IRC log <http://www.w3.org/2015/02/17-touchevents-irc>
Attendees
PresentRick_Byers, Jacob_Rossi, Asir_Selvasingh, Ted_Dinklocker,
Patrick_Lauke, Olli_Pettay, Mustaq_Ahmed, Tim_Dresser, Scott_Gonazlez,
Matt_BrubeckRegretsChairRick_ByersScribeTim_Dresser
Contents

   - Topics <http://www.w3.org/2015/02/17-touchevents-minutes.html#agenda>
      1. mouseenter, mouseleave and touch compat/interop
      <http://www.w3.org/2015/02/17-touchevents-minutes.html#item01>
      2. Identifying mouse events derived from touch
      <http://www.w3.org/2015/02/17-touchevents-minutes.html#item02>
      3. Feedback on (or approval to merge) PR
      <http://www.w3.org/2015/02/17-touchevents-minutes.html#item03>
      4. AOB <http://www.w3.org/2015/02/17-touchevents-minutes.html#item04>
   - Summary of Action Items
   <http://www.w3.org/2015/02/17-touchevents-minutes.html#ActionSummary>

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

<patrick_h_lauke> i'm in...though i'm not sure if zakim knows

<rbyers> Scribe: Tim_Dresser

<rbyers> scribenick: tdresser

<smaug> oh

<smaug> hmm,what is the conf code

<rbyers> smaug: 7394

<asir> Asir Selvasingh

<teddin> Ted Dinklocker
mouseenter, mouseleave and touch compat/interop

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

rbyers: If Chrome fixes this bug, will this break things? jrossi2, do you
have some data indicating how many people we'd break?

jrossi2: That would be our preferred path forward.
... We only hit a couple sites that broke, but there was a popular
stackoverflow post that suggested the pattern that breaks.
... It's hard to measure.
... Netflix is also broken in Chrome (as well as IE), we'll reach out to
them on that.
... We'll hold off on firing mouseenter and mouseleave, Chrome can go
ahead, it should be reasonably low risk.

rbyers: What should web devs do so that would work with all browsers?

jrossi2: The answer depends on whether or not we implement "firedFromTouch."

rbyers: Yeah, firedFromTouch is the clean solution.
... We'll try to fix that bug.
... It should be easy to fix - we'll aim for Chrome's M43, and get some
data within 6 weeks.

jrossi2: We should have a build out soon that will let you turn on touch
events in desktop, so you can test interop.

mbrubeck: I'll file the corresponding gecko bug.

<patrick_h_lauke> as i still got a bit lost with the bug description...is
this basically the problem that: Safari magically stops firing the final
click if there was a "change" to the page, effectively?

mbrubeck: Do we need spec errata?

jrossi2: I'd like to see errata, a note would be fine.

<patrick_h_lauke> and that chrome/IE/etc cannot replicate the heuristic
because of...the dreaded P word

<patrick_h_lauke> and instead we'll not fire mouseenter/mouseleave instead?

rbyers: Yeah we should add a note.

<mbrubeck> patrick_h_lauke: Not sure if there are IP barriers to
implementing the heuristic

<mbrubeck> patrick_h_lauke: But there are definitely
lack-of-spec/documentation issues

<mbrubeck> patrick_h_lauke: And we don't know if Safari's behavior will
change again in the future

<patrick_h_lauke> http://patrickhlauke.github.io/touch/tests/results/

rbyers: Chrome bug is that we've never sent mouseenter or mouseleave for
touch.

<patrick_h_lauke> gotcha

rbyers: We're going to break people who have depended on this.

jrossi2: I don't think we want to specify any heuristic behavior here.

<mbrubeck> I agree.

<patrick_h_lauke> +1 i don't want to rely on heuristics, even if documented

<rbyers> Safari code for hover feature is here:
https://trac.webkit.org/browser/trunk/Source/WebKit2/WebProcess/WebPage/ios/WebPageIOS.mm#L433

<patrick_h_lauke> rbyers if you could CC me on the bug for your proposed
solution around it (assume it's "fire mouseenter?") that'd be cool

<smaug> (sounds really horrible)

rbyers: A brief summary - during a style recalc, if some element changed
from being hidden to being shown, they consider that to be a content
observable change. If there was a content observable change, they suppress
the click event.
... It's complicated, we need a clear api for it.
... There are races in their implementation.
Identifying mouse events derived from touch

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

<patrick_h_lauke> (incidentally, iOS8 changed the "detect changes" algo
which forced me to update my tests...
https://github.com/patrickhlauke/touch/commit/27a44597e389aca75472c23d00490682c2394e98
 )

rbyers: When we last talked about this, we prefered the "firedFrom" design.

<smaug> s/DOM Events/DOM/ spec

<patrick_h_lauke> (as before innerHTML wasn't somehow counted as a "change"
that stopped the event sequence)

rbyers: We got a bunch of objections from Anne, editor of the DOM spec,
saying it's fuzzy and not defined clearly enough.

<jrossi2> pointerType?

rbyers: For this problem, we don't want to know if it came from a touch
device, we want to know if it fired touch events.
... We could have a sourceDevice per event, which currently only contains a
bit indicating if the device can fired touch events.
... We'll want an input device API for other reasons too, so this feels a
bit cleaner.
... Any feedback?

jrossi2: How is this different from pointerType?
... We could use the same api for touch events and pointer events, which
would be convenient.

rbyers: I think aligning them makes sense, but I don't think pointerType is
rich enough.
... For example, a stylus on android needs to indicate that it fires touch
events, but the pointerType should be "stylus".

<mbrubeck> event.sourceDevice.pointerType, event.sourceDevice.maxTouchPoints

rbyers: pointerType could be an attribute of the source device.

jrossi2: Isn't this the same thing as pointerType == "touch"?

rbyers: Not on IE desktop, because pointerType would be touch even though
no touch event was fired.

jrossi2: We're changing IE behavior.

rbyers: But all Android browsers fire touch events for all input devices
(like stylus and mouse).

jrossi2: This is similar to how the Windows "messageForPointer" structure
works. We pass a bunch of information about the input device.

rbyers: In PEWG, we had a bunch of discussion about whether or not
pointerType is adequate.
... We should put pointerGranularity, and hoverCapable etc in the
sourceDevice. Developers should never have to infer the device capabilities
based on the device type.

jrossi2: Some browser vendors believe that all input devices should be
handled uniquely, and would disagree with this.

<patrick_h_lauke> some browser vendors also don't have any
multimodal/multi-input devices...so their view is a bit blinkered

rbyers: If we think the sourceDevice API gives us what we need, and we
think it's a good idea for the web in general, we should go in that
direction.

smaug: I think we will need a source device object. We'll need to be aware
of potential fingerprinting issues.

jrossi2: One nice thing about events is that they're scoped more tightly.

rbyers: At this point we don't want to worry about enumerating all input
devices etc.

<patrick_h_lauke> as we mentioned CSS media features...one of the snags
with granularity etc is that having a single property/feature breaks apart
in multi-input scenarios, and you have to settle on "lowest common
denominator" which then is less useful. so if we are thinking of doing
something similar, it should definitely be input-specific

<rbyers>
https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#heading=h.rbcct8al2kop

jrossi2: Do you have any IDL written for this?

rbyers: On the list, people wanted feedback on the long term plans for this
API.

jrossi2: I'll run this by some folks on our side.
... It's pretty low risk. Worst scenario you end up with a property which
is nested unnecessarily, which isn't too bad.

rbyers: We haven't thought about equality comparisons, which we'll have to
figure out.
... Does touchevent.sourceDevice == touchevent2.sourceDevice?
... We can get by with a singleton for now.
... We may want to have a different sourceDevice per touch screen.
... If two fingers change simultaneously on two different targets, there
will be two different events, with two different source devices.

<teddin> Need to sign off. Looking forward to working with the grouo.

jrossi2: Does this go on UIEvent, or is it per touch?
... That's a good reason to sketch out the future of this, to help us
decide if there could be per-touch sourceDevices.

rbyers: The source device of the event corresponds to all of the changed
touches, not all of the touches.

jrossi2: Consider a leap motion laptop, you could have two input devices
firing touchevents which both have changedTouches on the same element, but
with different source devices.
... One's on the screen, and one is in the air.

<patrick_h_lauke> two touchscreens, browser window large enough to span
both, event listeners on body...

rbyers: If you guys think it's a promising avenue, I'll whip up a design
sketch.

jrossi2: A more realistic version of my scenario: If we use touch events
for pen, this could definitely happen.

rbyers: Either we'd have to allow a source device per touch, or you'd have
to send a separate event per sourceDevice.

jrossi2: There might be some compatability issues there.

rbyers: They share the same touches and targettouches arrays, but
changedTouches is different.
... We probably already never coalesce input events across devices.
... I'll follow up on this on the www-dom thread.
Feedback on (or approval to merge) PR

<rbyers> https://github.com/w3c/touch-events/pull/3

patrick_h_lauke: There are two outstanding issues on my pull request.
... Just want to figure out if we should land this.

<patrick_h_lauke>
https://github.com/w3c/touch-events/pull/3#discussion_r24487209

rbyers: In PEWG, we never mentioned anything that sounded like a gesture.

patrick_h_lauke: I don't want to use "click," because we aren't referring
to a click event.

rbyers: We could use "activate."

<patrick_h_lauke> "The activation of an element (e.g., in some
implementations, a tap)..."

jrossi2: As we start to explore other input devices, activation may be a
better word than tap.

patrick_h_lauke: I'll update the pull request.
... I was probably overly eager with removing line breaks.

<patrick_h_lauke>
https://github.com/w3c/touch-events/pull/3#discussion-diff-24468273

rbyers: I found it hard to review on github, because of the way diffs are
displayed.

patrick_h_lauke: The pointer events spec appeared to be using long lines.

<scott_gonzalez> I have to drop off to join another call.

rbyers: I don't have a strong preference, but we shouldn't switch back and
forth more than necessary.

mbrubeck: I don't think we need to stick with what pointer events did.

rbyers: There's benefit for being consistent with pointer events, but it's
also nice to be able to use the github diff tool.
... I don't care, but if we want to be able to send diffs around, short
lines would be more convinent.

<mbrubeck> https://dvcs.w3.org/hg/webevents/rev/be35b766b5ef

mbrubeck: I have a slight preference for short lines, because of diffs.

<mbrubeck> https://dvcs.w3.org/hg/webevents/rev/5c770b2dd992

rbyers: I can undo the line ending changes.

patrick_h_lauke: I need to edit it anyways, so I'll give it a try.
AOB

<patrick_h_lauke> heh

<rbyers> I propose we meet in 2 weeks