Add the `interesttarget` attribute

[foolip]

trafficstars

• [ ] At least two implementers are interested (and none opposed):
  • …
  • …
• [ ] Tests are written and can be reviewed and commented upon at:
  • …
• [ ] Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• [ ] Corresponding HTML AAM & ARIA in HTML issues & PRs:
• [ ] MDN issue is filed: …
• [ ] The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/browsers.html ( diff ) /form-elements.html ( diff ) /image-maps.html ( diff ) /index.html ( diff ) /indices.html ( diff ) /popover.html ( diff ) /semantics-other.html ( diff ) /text-level-semantics.html ( diff ) /interesttarget.html ( diff )

[foolip]

This is an initial translation of https://open-ui.org/components/interest-invokers.explainer/ to spec language, with a lot of things incomplete.

@mfreed7 I think the two biggest points of uncertainty I have now are the integration with mouse/keyboard/touch input on the one end, and with CSS on the other.

For showing interest, the timing of these algorithms relative to "mouseover" and other events needs to be defined.

For CSS, the fact that there are CSS properties controlling the timing means we need to think about:

• When do we look at the computed style to extract those times?
• Is there a state machine with timers, and is anything observable between the initial sign of interest and when we run "capture interest"?

There are many more minor TODOs, but I'd like to get the high-level flow settled first.

[foolip]

Thanks @lukewarlow, I've pushed those changes! (Couldn't apply the suggestions directly as they were line-by-line.)

[foolip]

Thanks for the review @mfreed7! I've addressed your comments now.

[foolip]

I have now pushed definitions of when :interest-source and :interest-target should match. Those pseudo-classes are now defined in https://drafts.csswg.org/selectors/#interest-source.

[foolip]

For anyone following only this PR and not the tracking issue, see https://github.com/whatwg/html/issues/10309#issuecomment-3252590058 about today's WHATNOT discussion and request to advance to stage 2.

[foolip]

https://github.com/whatwg/html/pull/11006/commits/fa121b61ee7bc1b96ee80e0f32b9d52f625ac895 is intended to align with https://chromium-review.googlesource.com/c/chromium/src/+/6970966. @mfreed7 can you carefully review it?

It's now closer to the Chromium implementation in that it doesn't depend on a recursive call to "handle interest change", but there are differences that I'm unsure about:

• I never cancel pending gain interest tasks, because I couldn't understand what effect it could have. All of the active interest sources already have interest (already "showing") and even if there are pending gain interest tasks, they will end up being no-ops, right?
• If I'm reading the Chromium code right, the iteration of AllSourceInterestInvokers() comes after a check that the element is an a, area, or button element. In the spec I'm iterating "recursive active interest sources" before the same check. I can't see what else would prevent a popover from closing when moving focus or hovering from the interest source to something inside the target popover, in the simplest case just a <div> with some text.

[mfreed7]

fa121b6 is intended to align with https://chromium-review.googlesource.com/c/chromium/src/+/6970966. @mfreed7 can you carefully review it?

Thank you!

It's now closer to the Chromium implementation in that it doesn't depend on a recursive call to "handle interest change", but there are differences that I'm unsure about:

• I never cancel pending gain interest tasks, because I couldn't understand what effect it could have. All of the active interest sources already have interest (already "showing") and even if there are pending gain interest tasks, they will end up being no-ops, right?

This seems right. I removed that code from Chromium and the tests still pass. I'll land that change, but this seems ok as-is in spec.

• If I'm reading the Chromium code right, the iteration of AllSourceInterestInvokers() comes after a check that the element is an a, area, or button element. In the spec I'm iterating "recursive active interest sources" before the same check. I can't see what else would prevent a popover from closing when moving focus or hovering from the interest source to something inside the target popover, in the simplest case just a <div> with some text.

Hmm, HandleInterestForHoverOrFocus() is the only one that calls AllSourceInterestInvokers(), but that can be called on any element, particularly targets of interest invokers, and contents of both invokers and targets. So it can get called on elements that aren't an a, button, etc. I just stuck a comment on the change, here, that outlines the problems that I can see. I wonder if it's worth trying to bring the spec closer to the implementation of HandleInterestForHoverOrFocus()?