RE: Constructor question and mouseEvents compat

For the change at 1.18 "a master pointer amongst the set of active pointers 
for each event type", should "for each event type" be "for each pointer type" 
instead?
- Cathy.


> -----Original Message-----
> From: ext Matt Brubeck [mailto:mbrubeck@mozilla.com]
> Sent: Tuesday, April 09, 2013 12:42 PM
> To: Jacob Rossi; Wesley Johnston; public-pointer-events@w3.org
> Subject: 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.)