Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove boundary events and use capture node as target #138

Merged
merged 2 commits into from Sep 8, 2016

Conversation

@NavidZ
Copy link
Member

commented Aug 31, 2016

This fix addresses issue #8

index.html Outdated
<li>Set the <code>relatedTarget</code> attribute of the event to <code>null</code>.</li>
<li>Set the target to the <a>pointer capture target override</a> object.</li>
</ul>
<li>If the <a>pointer capture target override</a> has been set for the pointer, set the target to <a>pointer capture target override</a> object. This may cause some boundary events as this is the same as pointer leaving its previous target and entering this new target.

This comment has been minimized.

Copy link
@mustaqahmed

mustaqahmed Sep 6, 2016

Contributor

Nit: This may fire some boundary events...the same as the pointer leaving...

@@ -840,7 +830,6 @@
<li>If the pointer is not in the <a>active buttons state</a>, then terminate these steps.</li>
<li>For the specified <code>pointerId</code>, set the <dfn>pending pointer capture target override</dfn> to the <code>Element</code> on which this method was invoked.</li>
</ol>

This comment has been minimized.

Copy link
@mustaqahmed

mustaqahmed Sep 6, 2016

Contributor

Do we need a line (or "note") here that pointerenter/over/leave/out events are never fired for a captured pointer?

This comment has been minimized.

Copy link
@NavidZ

NavidZ Sep 6, 2016

Author Member

They might be fired for a captured event in the transition phase though.

</li>
<li>If the <a>pending pointer capture target override</a> for this pointer is set and is not equal to the <a>pointer capture target override</a>, then fire a pointer event named <code>gotpointercapture</code> at the <a>pending pointer capture target override</a>.
<ul>
<li>Further, if the <a>pointer capture target override</a> is not set and, the <a>pending pointer capture target override</a> is not equal to the hit test node for the pointer event which invoked this process, and the hit test node has received <code>pointerover</code> and <code>pointerenter</code> events, then fire a pointer event named <code>pointerout</code> and a pointer event named <code>pointerleave</code> at the hit test node.</li>
</ul>
</li>
<li>Set the <dfn>pointer capture target override</dfn> to the <a>pending pointer capture target override</a>, if set. Otherwise, clear the <a>pointer capture target override</a>.</li>
</ol>

This comment has been minimized.

Copy link
@mustaqahmed

mustaqahmed Sep 6, 2016

Contributor

I think we need to clarify what triggers boundary events when releasing a capture. Something symmetric to your change above (in 5.1.3) which covers the case during capturing. Consider this scenario:

  1. Mouse is pressed on element A, which then sets capturing to B.
  2. Mouse is moved within A (which trigger the gotpointercapture event).
  3. The capturing at B is release while on A.
  4. Mouse is moved within A (which trigger the lostpointercapture event).

We expect boundary events in Steps 2 and 4. Section 5.1.3 covers Step 2, but w/o a notion like "current node for boundary events", it's not clear to me that Step 4 would fire any boundary events. Right?

This comment has been minimized.

Copy link
@NavidZ

NavidZ Sep 7, 2016

Author Member

How about this? Now I added an explicit node at the end of the section explaining both scenarios.

<li>Otherwise, set the target to the object returned by normal hit test mechanisms (out of scope for this specification).</li>
</ul>

<p>If this is a <code>pointerdown</code> event, the associated device is a direct manipulation device and the target is an <code>Element</code>, then <a href="setting-pointer-capture">set pointer capture</a> for this <code>pointerId</code> to the target element as described in <a>implicit pointer capture</a>.

<p>Fire the event to the determined target.

<div class="note">Using the <a>pointer capture target override</a> as the target instead of the normal hit-test result may fire some boundary events. This is the same as the pointer leaving its previous target and entering this new capturing target and if they are different targets boundary events should be dispatched first. When the capture is released the same scenario may happen as the pointer is leaving the capturing node and entering the hit-test target.</div>

This comment has been minimized.

Copy link
@RByers

RByers Sep 7, 2016

Contributor

This is a little hand-wavy (it's non-normative text but it describes behavior that isn't captured by the normative spec text outside of notes). As you know I'm OK with being a little imprecise (as least for now) as long as we have tests that validate the intended precise behavior.

One simple way to improve this may be to change the sections that describe the boundary events. They currently say "when a pointing device is moved into the hit test boundaries of ..." etc. If instead they said something like "when the target for the events for a given pointerId changes to ...". I.e. boundary events are generated as a result of changes in event targets within a per-pointer event stream, not as a result of movement around "hit-test boundaries". Alternately in the section on pointer capture you could just say that capture modifies the (unspecified) hit-test algorithm so that all other references to hit-testing in the spec use the pointer capture target override.

Even better, this could be encoded precisely in the firing algorithm (eg. by defining a "last target per pointer" map). But that's probably a fair bit more work. Maybe file a spec bug for that to explore in detail later?

@RByers

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2016

Seems like we're just focused on details. Since this is on a branch already, should we merge this PR as-is and then continue to iterate on details in a subsequent (less urgent) PR?

@mustaqahmed

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2016

I agree that the only remaining piece here is defining the modified triggering of boundary events. I think Rick's idea that boundary events triggers "when the target ... for a given pointerId changes..." is the cleanest solution. IMO all we need after that is to clarify the non-normative note added in this patch with an example capture/release from outside the hittest element.

LGTM on hashing out the details through future PRs.

@RByers RByers merged commit 0d2febe into w3c:reduce-hit-tests Sep 8, 2016

@RByers

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2016

Ok, merged. Let's keep iterating though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.