Touch Events Community Group -- 17 Feb 2015

<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

<gitbot> [13touch-events] 15AFBarstow created 06AFBarstow-patch-1 (+1 new commit): 02https://github.com/w3c/touch-events/commit/9e536c68d37f

<gitbot> 13touch-events/06AFBarstow-patch-1 149e536c6 15Arthur Barstow: Minor boilerplate updates...

<gitbot> [13touch-events] 15AFBarstow opened pull request #7: Minor boilerplate updates (06v1-errata...06AFBarstow-patch-1) 02https://github.com/w3c/touch-events/pull/7

<artb> oh dear, I think https://github.com/w3c/touch-events/pull/7 is on the master branch and it should be on the v1-errata branch :-(

<artb> btw, sorry I missed today's call (winter vacation week for schools in Mass)

<patrick_h_lauke> hmmm...i probably made this worse now (re line breaks etc)

<patrick_h_lauke> serves me right for being an idiot and doing two things in the same commit (changing line lengths and more consistent use of <code>)

<patrick_h_lauke> https://github.com/patrickhlauke/touch-events/commit/fd843c2efa3197816343e7c10803225070dd059d

<patrick_h_lauke> i'll see if i can salvage it (may have to try and split out the <code> additions)...

<artb> I suspect the easiest thing for me to do is to delete PR-7 and just submit another PR for the v1-errata branch. rbyers, mbrubeck, all, should I do that?

<mbrubeck> artb: yeah, sounds right

<gitbot> [13touch-events] 15AFBarstow created 06AFBarstow-patch-2 (+1 new commit): 02https://github.com/w3c/touch-events/commit/1ab9a5d6e4eb

<gitbot> 13touch-events/06AFBarstow-patch-2 141ab9a5d 15Arthur Barstow: Minor boilerplate updates...

<gitbot> [13touch-events] 15AFBarstow opened pull request #8: Minor boilerplate updates (06v1-errata...06AFBarstow-patch-2) 02https://github.com/w3c/touch-events/pull/8

<gitbot> [13touch-events] 15RByers closed pull request #8: Minor boilerplate updates (06v1-errata...06AFBarstow-patch-2) 02https://github.com/w3c/touch-events/pull/8

<gitbot> [13touch-events] 15RByers pushed 1 new commit to 06v1-errata: 02https://github.com/w3c/touch-events/commit/d181c34d389b9dd1eca36bc7e07aad0f587d709a

<gitbot> 13touch-events/06v1-errata 14d181c34 15Rick Byers: Merge pull request #8 from w3c/AFBarstow-patch-2...

<patrick_h_lauke> i'll redo/rebase my PR later tonight...

<patrick_h_lauke> got a plan of action ;)

<rbyers> patrick_h_lauke: Great, thanks!

<gitbot> [13touch-events] 15AFBarstow pushed 1 new commit to 06v1-errata: 02https://github.com/w3c/touch-events/commit/1424440f26240128d8d49014aeb481478e5083c7

<gitbot> 13touch-events/06v1-errata 141424440 15Arthur Barstow: Appears extraCSS is needed...

<gitbot> [13touch-events] 15AFBarstow pushed 1 new commit to 06v1-errata: 02https://github.com/w3c/touch-events/commit/0e6319630e4444d8c3cc60fdf5642af81fe9257f

<gitbot> 13touch-events/06v1-errata 140e63196 15Arthur Barstow: Fix syntax error...

<gitbot> [13touch-events] 15AFBarstow pushed 1 new commit to 06v1-errata: 02https://github.com/w3c/touch-events/commit/1c320f119caef0f000a926d0e0718ab66e7b2123

<gitbot> 13touch-events/06v1-errata 141c320f1 15Arthur Barstow: I am now an `Invited Expert`...

<patrick_h_lauke> hopefully fixed the messy PR with some manual rewriting and a scary interactive rebase

<patrick_h_lauke> obviously, this means i've rewritten history...sorry all

<patrick_h_lauke> ah, few tiny leftover things, but looking at github just now seems it's a lot tidier already

<patrick_h_lauke> going to fix up some minor things and change history again...and then we should be good to merge

- DRAFT -

Touch Events Community Group

17 Feb 2015

Attendees

Contents

mouseenter, mouseleave and touch compat/interop

Identifying mouse events derived from touch

Feedback on (or approval to merge) PR

AOB

Summary of Action Items

Scribe.perl diagnostic output