Re: [whatwg/dom] Define special dispatch behavior for click events (#342)

domenic commented on this pull request.

Upon reviewing, the name "activation behavior" does seem strange compared to e.g. "(legacy) post-click-dispatch steps". I'd prefer the symmetry, although probably we should omit legacy as you say.

I think a non-normative note explaining the historical nature of this pattern, and why just checking the canceled flag from normal event dispatch (like for other events) doesn't work, would be helpful. The answer being, basically, that legacy web code depends on certain actions happening when it does dispatchEvent() appropriately---right?

> @@ -1028,6 +1028,18 @@ specified otherwise it returns null.
 <p class="note no-backref"><a>Nodes</a>, <a for=/>shadow roots</a>, and <a>documents</a> override
 the <a>get the parent</a> algorithm.
 
+<p>Each {{EventTarget}} object can have an associated
+<dfn export for=EventTarget>legacy pre-click-dispatch steps</dfn> algorithm,
+<dfn export for=EventTarget>legacy post-canceled-click-dispatch steps</dfn> algorithm, and
+<dfn export for=EventTarget>activation behavior</dfn> algorithm. The <a>activation behavior</a>
+algorithm is passed an <a>event</a>, as indicated in the <a>dispatch</a> algorithm.</p>
+
+<p class="note no-backref">An {{EventTarget}} object that has <a>legacy pre-click-dispatch steps</a>

This phrasing in the non-normative note seems a little strange. I think it's stating an observation about the world, but maybe it's meant to be more of a requirement?

Perhaps a better conceptual framework would be to define two special types of EventTargets:

- clickable event targets, which have activation behavior
- clickable event targets with interception, which additionally have legacy pre-click dispatch steps and legacy post-canceled-click-dispatch steps

(better names welcome). Then you say e.g. "every HTMLXElement is a clickable event target with the following activation behavior: ..."

> @@ -1225,12 +1240,28 @@ for discussion).
    <li><p>Otherwise, set <var>target</var> to <var>parent</var> and append (<var>parent</var>,
    <var>target</var>, <var>relatedTarget</var>) to <var>event</var>'s <a for=Event>path</a>.
 
-   <li><p>If <var>parent</var> is non-null, then set <var>parent</var> to the result of invoking
-   <var>parent</var>'s <a>get the parent</a> with <var>event</var>.
+   <li>
+    <p>If <var>parent</var> is non-null, then:
+
+    <ol>
+     <li><p>If <var>event</var>'s {{Event/bubbles}} attribute is true, <var>activationTarget</var>
+     is null, and <var>parent</var> has <a>activation behavior</a>, then set
+     <var>activationTarget</var> to <var>parent</var>.
+     <!-- If an EventTarget object with activation behavior can ever have an associated shadow root
+          we need to complicate this somewhat. -->

So the only reason this isn't complicated yet is that we disallow attachShadow on elements with interesting activation behavior? That is kind of fragile, if so... hmm.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/342#pullrequestreview-4138227