<patrick_h_lauke> hey folks

<rbyers> hello!

<rbyers> Happy new year!

<patrick_h_lauke> likewise :)

<patrick_h_lauke> nobody dares to say anything...

<rbyers> Scribe: Jacob_Rossi

Identifying mouse events derived from touch http://lists.w3.org/Archives/Public/public-touchevents/2014Sep/0000.html

rbyers: I think most important issue for this group is that browsers can't enable TE on all devices
... IE is mobile only, Chrome is touchscreen only and has emulation in dev tools

jrossi: +1

rbyers: the chrome team has a rough plan for how we turn this on everywhere
... willing to take some compat pain, it's all about mitigation strategy
... important piece is having really clear guidelines for what devs can do instead

<rbyers> Common problematic coding pattern: if ('ontouchstart' in window)

rbyers: sometimes used for feature detection, sometimes used for detecting if there's a touchscreen
... first step was interaction media queries

<rbyers> http://dev.w3.org/csswg/mediaqueries-4/#mf-interaction

rbyers: gives input into what devices the user has
... recently tweaked this API to make it more powerful on touchscreen laptops (any-hover, any-pointer)
... on by default in Chrome beta
... not the only q they're trying to ask. they're also what do i do when i see mouse events or a click?
... we still don't have areally good story for that pattern.
... you can call preventDefault() on touch. i thought that was a good solution, but i've been convinced otherwise.
... one component may not have all the information it needs to call preventDefault(), making a global decision based on local needs

<patrick_h_lauke> should i troll now and say pointer events solves this? :p

<rbyers> jrossi: would be good to write down different use cases for this

<rbyers> patrick: yep ;-)

<mbrubeck> jrossi: For example, duplicate events (touchstart + mousedown), versus "want to handle click event without waiting for double-click delay"

<mbrubeck> rbyers: I had originally listed this as two separate issues, but they may be more entangled than I thought.

<rbyers> Some notes on this problem here: https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit?pli=1#

rbyers: Scott, do you have experience in this?

scott_gonzalez: I need to go back and look at this. We didn't pick a model before [touch/pointer], just used X/Y coordinates and gestures, but are now to pointer.
... in a lot of cases we just want to handle which is first. in some though we probably want to kno the differeence and provide different UX.

rbyers: let me understand jquery better. you listen to touch events first, and ignore mouse events during. at what time do you start listening to mouse again?

scott_gonzalez: as soon as another interaction starts (after touchend) we start over

rbyers: i don't think that works because the mouse events come after. how did you handle double firing?
... need to make sure you don't do a redundant action

scott_gonzalez: not sure about that part. I think they just use their tap event, but I'd have to check with them.

rbyers: I'd like to make this a short snippet of JS rather than some crazy recommended heuristics

scott_gonzalez: I think devs do that, but just use a fastclick library

rbyers: I think if that was the extent of the problem, then I wouldn't think this needs further problem. But I think the issue isn't just about click, but they have both touch & mouse handlers and need to avoid duplicate.

scott_gonzalez: to be honest, developers have been saying pointer can solve this

<patrick_h_lauke> (oops i think i've been disconnected...? ... repasting my previous message in case it got lost)

rbyers: yeah, we can look at this as something for touch events to help pointer event polyfills

<mbrubeck> Mozilla has a non-standard MouseEvent.mozInputSource (basically MouseEvent.pointerType): https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent#Properties

mbrubeck: I have some feedback based on FF experience. Gecko has a non-standard inputSource property
... not really used on the web, but we have used it in FF UI code
... 100% of the time we use it to tell if you have a mouse event created from touch

rbyers: the very simple proposal is add a bit to MouseEvent that helps you know it came from TouchEvent

patrick_h_lauke: I think the issue is that we're making it so touch specific. just in the case that we need a geenratedFromSomeOtherDevice flag in the future

mbrubeck: you need to know not just if it's derived but that its from something else you handled

MouseEvent.firedFrom("TouchEvent")

this was something I threw out as an idea with rbyers

rbyers: I like this because presumably you could also do firedFrom("PointerEvent")
... my proposal though is probably more discoverable

jrossi: yeah, that's true

rbyers: could imagine a hybrid where firedFrom is an object with different event model members

patrick_h_lauke: could just be a string
... could have even more specific with some unique id
... I think it's finding the middle ground.

mbrubeck: yeah rbyer's doc rejects the idea of providing the original event

rbyers: has great complexity issues with lifetime management and threading
... if there's a really compelling case, we can explore it. otherwise, would rather not.

jrossi: i agree
... it's a nightmare

rbyers: other thing is that just a string doesn't let you have future models [describes pointer & touch both firing mouse]

patrick_h_lauke: there's still an issue of code not knowing about future event types that get added (even if it's not a string)

<patrick_h_lauke> so conceptually...we want to provide developers enough information to "pick" which event they want to listen to (rather than using either big hammers like preventDefault() to kill off certain events, or having to keep track of event sequences of "which event came first" and then debouncing or avoiding double handling).

<patrick_h_lauke> you want devs to be able to "dip" into the event stream and choose what they're interested in, rather than having to manipulate this stream (preventDefault) or having to duplicate functionality (counting, keeping track of events, setting their own flags of what they handled, etc).

rbyers: yeah, that sounds like a good characterization to me. nit: not necessarily listen to, but respond to. it's not until the actual event that they know whether they want to do something with it.
... i don't have a strong opinion on the small API differences. but maybe next concrete steps is to write it up more formally and propose to DOM Events group
... i sent my original proposal and they gave feedback that it was a little too specific
... is there a real difference between the method that takes a string and the object?

jrossi: we have to bikeshed, rbyers. :-)

<patrick_h_lauke> wondering if method way is more extensible (not needing blessing from other groups to extend DOM event)

rbyers: I can whip up a version where firedFrom is a object with properties

<patrick_h_lauke> vs individual properties...

rbyers: i think given that, I think Jacob's proposal is less likely to cause future problems. i can edit the doc i linked to with this proposal.

Identifying touch events that will trigger a tap / click

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

jrossi: are you going to send that to th DOM group?

rbyers: I'll circle it with you guys first

<patrick_h_lauke> note: even pure touchscreen-only can be problematic when coupled with assistive tech http://patrickhlauke.github.io/touch/tests/results/#mobile-tablet-touchscreen-assistive-technology-events

<patrick_h_lauke> http://patrickhlauke.github.io/touch/tests/results/#desktop-assistive-technology-events

rbyers: one other problem. with this API shape, we don't have a way of telling if the browser doesn't support the event type you passed
... don't have an "i don't know" return value
... we might need a yes, no, unknown

<patrick_h_lauke> https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation.hasFeature

jrossi: just want to make sure we don't get into solving the hasFeature problem. that's a different problem.

rbyers: suggest we table the second topic for next week
... objections?

[none]

AOB

<scott_gonzalez> I need to drop off and join another call.

<patrick_h_lauke> "prioritization games", the lesser known sequel to "hunger games" ...

<rbyers> jrossi: thanks, was just going to ask. Guess I should add one more missing thing:

:-)

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/tap/click event/
No ScribeNick specified.  Guessing ScribeNick: jrossi
Found Scribe: Jacob_Rossi
Default Present: Scott_Gonzalez, rbyers, +44.797.663.aaaa, patrick_h_lauke, +1.571.426.aabb, Matt_Brubeck, jrossi
Present: jrossi rbyers tdresser scott_gonzalez mbrubeck patrick_h_lauke Asir_Selvasingh
Regrets: ArtB
Agenda: http://lists.w3.org/Archives/Public/public-touchevents/2015Jan/0004.html
Got date from IRC log name: 06 Jan 2015
Guessing minutes URL: http://www.w3.org/2015/01/06-touchevents-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.