W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

RE: A few questions on the current PE draft

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Tue, 5 Feb 2013 04:31:27 +0000
To: "Cathy.Chan@nokia.com" <Cathy.Chan@nokia.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Message-ID: <60001d2a8c634b8dbcc1736623e32223@BN1PR03MB021.namprd03.prod.outlook.com>
-----Original Message-----
From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com] 
Sent: Wednesday, January 30, 2013 1:36 PM
To: public-pointer-events@w3.org
Subject: A few questions on the current PE draft

> Upon re-reading the current draft, I have a few questions.
> 
> 1. At any point in time, how many pointers can simultaneously have isPrimary
set to true? The way I read it, there could be up to three, one for a mouse
device, one for a touch input, and one for a pen input, if the underlying
platform supports all three input types simultaneously. Is that correct?

Correct. Generally, users don't mix input simultaneously. In IE10, multiple primary pointers effectively "fight" for a mouse cursor (e.g. you'll see mousemove events firing back and forth between the two locations).

> 2. If my understanding in #1 is correct, then in "8.1 Mapping for devices
that support hover", there should be *three* different PREVENT MOUSE EVENT
flags, one for each input type. Otherwise, cancelling the pointerdown event
of the primary touch input would inadvertently disable the compatibility
mouse events for subsequent events from the primary mouse and pen inputs as
well.

Totally right, I opened Bug 20872.  Though I think I'll update this to say "set the PREVENT MOUSE EVENT flag for this pointer type" and "if the PREVENT MOUSE EVENT flag is set for this pointer type." That way the principle applies if new device types are added.

> 3. In "8.1 Mapping for devices that support hover": 
[[ 4.If the pointer event dispatched was pointerover, 
1.dispatch a mouseover event, and
2.if the pointer has been moved onto the boundaries of an element or one of
its descendants then dispatch a mouseenter event.]]
>Why not simply dispatch a mouseenter event when the pointer event being
dispatched is a pointerenter event, and only dispatch the mouseover event
with the pointerover event? I'm guessing that this is an artifact of not
having the pointerenter and pointerleave events initially?
> The same applies to the pointerout event, as well as section 8.2.

Yeah this would be a better way to write it. Yes, this is just an artifact of pointerenter/leave not originally being in the spec. I'll definitely update this so it's cleaner now. Since this is just editorial, I'll go ahead and make the change. Thanks for the feedback.

> 4. In "7.3 Implicit Release of Pointer Capture", should the requirement also
apply to the firing of the pointercancel event?

Yes it should. Opened Bug 20873 for this.

> Regards, Cathy.

-Jacob
Received on Tuesday, 5 February 2013 04:32:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:17:04 GMT