Re: Constructor question and mouseEvents compat

On 4/8/2013 11:11 AM, Matt Brubeck wrote:
> On 4/8/2013 10:49 AM, Jacob Rossi wrote:
>> "The primary pointer is used to identify a master pointer amongst the 
>> set of active pointers for the pointer type.
>
> This part sounds good.
>
>>   This pointer will produce compatibility mouse events."
>
> This is still confusing, because with multiple primary pointers active 
> at once, one will generate mouse events and the others might not (or 
> will not?).  Maybe it should say "Only a primary pointer can generate 
> compatibility mouse events."

Per our discussion on today's telcon, I made several minor changes to 
the spec to clarify that multiple primary pointers may be active at once:
https://dvcs.w3.org/hg/pointerevents/rev/9e15214ee5c5

> Then in section 8 we can expand on this with something like, "When 
> more than one primary pointer is active, the user agent MAY choose to 
> dispatch compatibility mouse events for only one of the primary 
> pointers." (Maybe that should be a "SHOULD" or "MUST"...)
>
> If my understanding is correct, we also need to update the mapping 
> algorithms in 8.1 and 8.2 to allow the user agent to terminate the 
> steps if it selects a different active pointer to generate mouse events.

It seems my understanding was *not* correct here: User-agents are *not* 
expected to choose only one active pointer to generate mouse events.  If 
there is more than one primary pointer, they will all generate mouse 
events, effectively "fighting over" the mouse cursor.  This is not 
generally a problem in practice, since users can just restrict 
themselves to a single input type for applications that only handle 
mouse events.  Since the compatibility mapping is only intended for 
legacy compatibility, and the proposed additional steps do not provide a 
significant compatibility benefit, we will not add them.

(User agents or platforms may perform "arbitration" on input before it 
reaches content, but that happens outside of the Pointer Events model 
and is out of scope for this working group. This would include things 
like "palm rejection" for touch+stylus input.)

Received on Tuesday, 9 April 2013 16:42:09 UTC