Touch Events Community Group -- 10 Mar 2015

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

- DRAFT -

Touch Events Community Group

10 Mar 2015

Attendees

Contents

mouseenter/mouseleave issues

Identifying mouse events derived from touch

AOB

Summary of Action Items

Scribe.perl diagnostic output