Draft minutes: 2015 Mar 10 call

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

Next meeting opportunity Mar 17, but we'll cancel if there isn't sufficient
agenda topics.

Thanks,
   Rick

- DRAFT -Touch Events Community Group10 Mar 2015

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

See also: IRC log <http://www.w3.org/2015/03/10-touchevents-irc>
Attendees
PresentAsir, Jacob, Rick, Scott, Tim, Mustaq, TedRegretsPatrickChairrbyers
ScribeTim_Dresser
Contents

   - Topics <http://www.w3.org/2015/03/10-touchevents-minutes.html#agenda>
      1. mouseenter/mouseleave issues
      <http://www.w3.org/2015/03/10-touchevents-minutes.html#item01>
      2. Identifying mouse events derived from touch
      <http://www.w3.org/2015/03/10-touchevents-minutes.html#item02>
      3. AOB <http://www.w3.org/2015/03/10-touchevents-minutes.html#item03>
   - Summary of Action Items
   <http://www.w3.org/2015/03/10-touchevents-minutes.html#ActionSummary>

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

<jrossi2> oops I was in the wrong room

<rbyers> Scribe: Tim_Dresser

<rbyers> ScribeNick: tdresser

<teddin> Ted is here - having audio issues right now.
mouseenter/mouseleave issues

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

rbyers: I asked some more detailed questions to Jacob last week on the
list, have you had a chance to read over this?
... High level, we should discuss what it means for IE to support the
webkit style mouse event model.

jrossi: We defer the mouse events that happen normally, until after
touchend.
... We have a bug currently that the default actions aren't wired up
completely correctly.
... We'll have a build out soon with this behind a flag.
... We may also need to alter the behavior of hover.

rbyers: Are you currently setting hover when you fire mouseenter?

jrossi: No, we broke the connection between hover and enter and leave.
... Hover happens at the regular time (at pointer-enter and pointer-leave),
but we defer the mouse events.

rbyers: That makes sense. The pointer events are the primary API, and the
mouse events are there for legacy.

jrossi: The interop of hover and mouse events for touch is super broken
anyways, so I don't think it's important that the connection between mouse
events and hover is very valuable.

rbyers: That sounds good.

jrossi: The next step for me is to answer rbyers' questions from the thread
after talking it over with other Microsoft folks.

rbyers: We could spend some time talking about :active and :hover semantics
for touch either here or at the CSS working group.

mustaq: I was comparing Firefox and Chrome, and our hover and active
behavior for tap appears the same.
... They are sending enter and leave, but in terms of hover and active,
they behave the same.

rbyers: We should make sure we have a Firefox person around when we discuss
this.
... The other issue is finding examples of sites that are broken. jrossi,
can you send us the list of sites that break if you send enter/leave on tap?

jrossi: We don't have much of a list, Netflix was broken, but it's fixed
now.
... There is sample code up on StackOverflow.

rbyers: Good - so this issue doesn't show up anywhere on Netflix anymore?

jrossi: Correct.

rbyers: Our next step is to land it, and see what we break.
Identifying mouse events derived from touch

<rbyers> I sent <
https://lists.w3.org/Archives/Public/www-dom/2015JanMar/0102.html>

<rbyers> my InputDevice design sketch <
https://docs.google.com/a/chromium.org/document/d/1WLadG2dn4vlCewOmUtUEoRsThiptC7Ox28CRmYUn8Uw/edit
#>

<rbyers> to www-dom today.

rbyers: Any thoughts?

jrossi: I like it, at least as a starting point.

rbyers: We should justify every property carefully, but establishing a
pattern feels correct.

jrossi: We tried to go down this road with pointer events, but we didn't
have enough experience at that point.
... There was a discussion about this at one point on the pointer events
list. In the first version of pointer events, we used a numeric enum, which
was bad for extensibility.
... If we just use strings, we can avoid that problem.
... We might want to have a registry somewhere that isn't part of the spec,
that's easily updateable.
... I'd put Kinect in the list, maybe HoloLens.

rbyers: We could just have a page on the pointer events wiki.

jrossi: I think there should be a set of obvious ones in the spec, and then
point to a wiki for the less standard ones.

rbyers: And over time we could move more things into the spec.

jrossi: Can you enumerate the list of available values for a string enum?

rbyers: I don't think so.
... If you try to pass a string that isn't valid, it throws an exception.
... If we want to allow javascript to add input types, we should use a
string over a string enum.
... In my current proposal, you can't create new input devices.

jrossi: Could you just pass in an object that looks like an InputDevice
into the constructor?

rbyers: In WebIDL, I don't think so.
... The constructor for UIEvent would by default leave the InputDevice null.
... We might want a way for script to be able to create a new InputDevice.
... I'll add a section to my doc calling out each of these issues.
... We could tackle parts of this without adding a constructor.

jrossi: I think we should add a constructor from the beginning.

rbyers: Ok, I'll allow passing an InputDevice to the UIEvent constructor,
and allow constructing an InputDevice.
... Once we have that, we can think about custom device classes.
... What about pointer granularity? Should that be extensible? Should you
be able to define a new granularity other than fine or coarse?

jrossi: This becomes more of a general question. Couldn't the constructor
just take strings for these properties?

rbyers: This eliminates opportunities for binding languages other than
javascript.
... It could hurt things like typescript.
... The choices are clear. You can define an enum with the standard values.
Then your api can take and return an instance of that enum, or it can take
a DOM string.

jrossi: That makes sense.

rbyers: I'll focus on the www-dom thread, and try to get some consensus
there.
AOB

rbyers: Should we make hover/active the focus of our next call?

jrossi: I'll have to do some digging before I can have a productive
conversation about that.

rbyers: We'll say that's blocked on you then.