Draft minutes: 2015 Jan 6 call

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

Thanks,
   Rick

- DRAFT -Touch Events Community Group06 Jan 2015

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

See also: IRC log <http://www.w3.org/2015/01/06-touchevents-irc>
Attendees
Presentjrossi, rbyers, tdresser, scott_gonzalez, mbrubeck, patrick_h_lauke
RegretsChairrbyersScribeJacob_Rossi
Contents

   - Topics <http://www.w3.org/2015/01/06-touchevents-minutes.html#agenda>
      1. Identifying mouse events derived from touch
      http://lists.w3.org/Archives/Public/public-touchevents/2014Sep/0000.html
      <http://www.w3.org/2015/01/06-touchevents-minutes.html#item01>
      2. Identifying touch events that will trigger a tap / click
      <http://www.w3.org/2015/01/06-touchevents-minutes.html#item02>
      3. AOB <http://www.w3.org/2015/01/06-touchevents-minutes.html#item03>
   - Summary of Action Items
   <http://www.w3.org/2015/01/06-touchevents-minutes.html#ActionSummary>

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

<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" ...