Re: Impact of pointer capture on pointerover/pointerout events

Re this comment and the CR comment tracking doc, I set the Resolution to 
"add non-normative note" 
<http://www.w3.org/wiki/PointerEvents/CR-pointerevents-20130509>.

On 10/31/13 4:40 PM, ext Cathy.Chan@nokia.com wrote:
> Works for me, as long as you
> s/by targeted by/be targeted by/
>
> - Cathy.
>
>
>> -----Original Message-----
>> From: ext Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
>> Sent: Thursday, October 31, 2013 3:49 PM
>> To: Chan Cathy (Nokia-CIC/Boston); rbyers@google.com
>> Cc: scott.gonzalez@gmail.com; public-pointer-events@w3.org
>> Subject: RE: Impact of pointer capture on pointerover/pointerout events
>>
>> "Note: when pointer capture is set, pointerover, pointerout, pointerenter,
>> and pointerleave events are only generated when crossing the boundary of
>> the element that has capture as other elements can no longer by targeted by
>> the pointer. This has the effect of suppressing these events on all other
>> elements."
>>
>> -----Original Message-----
>> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
>> Sent: Thursday, October 31, 2013 12:20 PM
>> To: rbyers@google.com; Jacob Rossi
>> Cc: scott.gonzalez@gmail.com; public-pointer-events@w3.org
>> Subject: RE: Impact of pointer capture on pointerover/pointerout events
>>
>> Correct me if I'm wrong. The way I see it (which was not immediately obvious
>> from the prose), pointer capture effectively redirects all pointerup,
>> pointermove and pointercancel(?) events of the pointer to the element that
>> has capture, while suppressing the pointerover, pointerout, pointerenter
>> and pointerleave events of that pointer on all other elements. Maybe that's
>> what should go into the note?
>> - Cathy.
>>
>>> From: ext Rick Byers [mailto:rbyers@google.com]
>>>
>>> On Thu, Oct 31, 2013 at 2:51 PM, Jacob Rossi
>> <Jacob.Rossi@microsoft.com>wrote:
>>>> I'm ok with a note as well. Here's suggested text to be placed in
>>>> section
>>>> 10:
>>>>
>>>> "Note: when pointer capture is set, pointerover, pointerout,
>>>> pointerenter, and pointerleave events are only generated for the
>>>> element that has capture as other elements can no longer by targeted by
>> the pointer. "
>>> Good, but a little ambiguous as to the precise behavior I think.  How
>>> about replace "for the element that has capture" with "when crossing
>>> the boundary of the element that has capture" - just to make it
>>> crystal clear that they're not generated "for" the capture element
>>> when crossing over other elements.
>>>
>>>> -----Original Message-----
>>>> From: Cathy.Chan@nokia.com [mailto:Cathy.Chan@nokia.com]
>>>> Sent: Thursday, October 31, 2013 11:39 AM
>>>> To: rbyers@google.com; Jacob Rossi
>>>> Cc: scott.gonzalez@gmail.com; public-pointer-events@w3.org
>>>> Subject: RE: Impact of pointer capture on pointerover/pointerout
>>>> events
>>>>
>>>>> From: ext Rick Byers [mailto:rbyers@google.com]
>>>>>
>>>>> This makes sense, thank you.  Do you think it's worth adding a
>>>>> note to this effect - the reasoning is a little subtle (but the
>>>>> behavior is intuitive so maybe it's not necessary).
>>>>>
>>>> +1 for an informative note.
>>>> - Cathy.
>>>>
>>>>> Sounds like we just need to add a 'not' to the description in the
>>>>> test (
>>>>> https://github.com/InternetExplorer/web-platform-tests/blob/ddffbd
>>>>> c5ed
>>>>> d63c972b9ee42df1f161fc17778125/pointerevents/capture.html#L16),
>>>>> and ideally expand the test to validate this.
>>>>>
>>>>> Rick
>>>>>
>>>>>
>>>>> On Thu, Oct 31, 2013 at 1:47 PM, Jacob Rossi
>>>>> <Jacob.Rossi@microsoft.com
>>>>> wrote:
>>>>>
>>>>>> Pointer capture makes it so that pointer events cannot hit test
>>>>>> to any other element but the one with capture. It follows, then,
>>>>>> that a move can only be detected to have entered or left the hit
>>>>>> test bounds of the element with capture ("A user agent MUST
>>>>>> dispatch this event when a pointing device is moved into the hit
>>>>>> test boundaries of
>>>> an element." [1]).
>>>>>> So, pointerover/pointerout only fire for entering/leaving the
>>>>>> element with capture but do not fire for entering/leaving other
>>>>>> elements. This is what occurs in the test case where pointerover
>>>>>> is dispatched to the element
>>>>>> (#target0) that has capture.
>>>>>>
>>>>>> -Jacob
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 30, 2013 at 2:43 PM, <Cathy.Chan@nokia.com> wrote:
>>>>>>
>>>>>>   I don't have anything to add (yet) except a link to the
>>>>>> original
>>>> thread:
>>>>>> http://lists.w3.org/Archives/Public/public-pointer-events/2013Ap
>>>>>> rJun
>>>>>> /0120.html
>>>>>>
>>>>>>   - Cathy.
>>>>>>
>>>>>>   > From: ext Rick Byers [mailto:rbyers@google.com]  > Sent:
>>>>>> Tuesday, October 29, 2013 10:43 PM  > To: Scott González; Jacob Rossi
>>> Cc:
>>>>>> public-pointer-events@w3.org  > Subject: Re: Impact of pointer
>>>>>> capture on pointerover/pointerout events
>>>>>>
>>>>>>
>>>>>>   > Reviving this old thread - I don't think we ever talked about
>>>>>> it on a call  > (I was away for the following call and it looks
>>>>>> like we never re-scheduled  > discussing of it).
>>>>>>   >
>>>>>>   > The Microsoft test submission says it expects to receive a
>>>>>> pointerover  > event in exactly this scenario (  >
>>>>>> https://github.com/InternetExplorer/web-platform-tests/blob/ddff
>>>>>> bdc5
>>>>>>
>> edd63c972b9ee42df1f161fc17778125/pointerevents/capture.html#L16
>>>>>> ),
>>>>>>   > but it's not actually validating that it happens and IE11
>>>>>> appears not to do  > it.
>>>>>>   >
>>>>>>   > I think we need some clarity on what the spec intends here.
>>>>>> Is IE11's  > behavior correct?
>>>>>>   >
>>>>>>   > Thanks,
>>>>>>   >    Rick
>>>>>>   >
>>>>>>   >
>>>>>>   > On Mon, Apr 29, 2013 at 12:08 PM, Scott González <
>>>>>> scott.gonzalez@gmail.com>wrote:
>>>>>>   >
>>>>>>   >> On Fri, Apr 26, 2013 at 4:32 PM, Rick Byers
>>>>>> <rbyers@google.com>
>>>> wrote:
>>>>>>   >>
>>>>>>   >>> Should we explicitly specify that?
>>>>>>   >>>
>>>>>>   >>
>>>>>>>> I wouldn't expect any over/out events during capture.
>>>>>>   >>
>>>>>>   >> Also should we explicitly specify the meaning of
>>>>>> relatedTarget for the  >>> pointer events analogous to the mouse
>> events?
>>>>>>   >>>
>>>>>>   >>
>>>>>>   >> This seems like a good idea.
>>>>>>   >>
>>>>>>
>>>>

Received on Sunday, 3 November 2013 18:03:36 UTC