Add popover=hint

[josepharhar]

Fixes #9776

Explainer: https://open-ui.org/components/popover-hint.research.explainer/#popoverhint-behavior

• At least two implementers are interested (and none opposed):
  • Chrome
  • popover=hint WebKit/standards-positions#305
  • Supportive: popover=hint mozilla/standards-positions#965
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/semantics/popovers/popover-types-with-hints.tentative.html
• Implementation bugs are filed:
  • Chromium: Implemented
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=275048
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1867743
• MDN issue is filed: popover=hint mdn/mdn#593

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

---

/interactive-elements.html ( diff )
/popover.html ( diff )

[nt1m]

I would probably want https://github.com/keithamus/invoker-buttons-proposal to be worked on first before addressing this, as I think it's a building block for this and other declarative attributes.

[mfreed7]

I would probably want https://github.com/keithamus/invoker-buttons-proposal to be worked on first before addressing this, as I think it's a building block for this and other declarative attributes.

So I've significantly updated the popover=hint explainer, and there are a few sections detailing why I believe the functionality described in this PR is independent of the hover-triggering functionality described by the Invokers explainer (note that it was moved to the OpenUI repo). See this section:

• https://open-ui.org/components/popover-hint.research.explainer/#tooltip-lifecycle-behaviors

Indeed both are important bits of functionality, but I'm hoping we can tackle them independently rather than needing to put up another huge spec PR. That didn't work very well for the original Popover spec PR, at least in my opinion.

[josepharhar]

Note to self: this will require additional changes in https://chromium-review.googlesource.com/c/chromium/src/+/5229300 if the corresponding PR to be opened gets merged

[mfreed7]

Ok, I reviewed mostly for the correctness of the algorithms, and things look pretty good. I made a few corrections, but other than those, LGTM.

[mfreed7]

Gentle ping - any chance we could get an initial review of this PR? @annevk @domenic

[emilio]

Conceptually looks good, though I think the current getStackPosition behavior is not correct / what we want? I might be wrong tho.

[mfreed7]

Conceptually looks good,

Cool, thanks for the review! Sounds like you're supportive of the PR in general? If so, mind marking that on mozilla/standards-positions#965?

though I think the current getStackPosition behavior is not correct / what we want? I might be wrong tho.

See my comment in the review - let's discuss there. I want to understand a bit better.

[mfreed7]

This issue/PR was just discussed at the OpenUI/WHATWG/CSSWG form controls task force meeting, in the context of a more general discussion of the "tooltip" use case. The notes are located here:

https://logs.csswg.org/irc.w3.org/css/2024-07-25/#e1637392

[mfreed7]

Conceptually looks good,

Cool, thanks for the review! Sounds like you're supportive of the PR in general? If so, mind marking that on mozilla/standards-positions#965?

@emilio any thoughts on this one? I.e. adding support (or not) from Mozilla's point of view, for popover=hint?

[josepharhar]

I checked the implementer interest box now that mozilla is supportive: mozilla/standards-positions#965 (comment)

@zcorpan

[mfreed7]

Cool, thanks all. I can file the MDN bug, which looks like the last checkbox to check. Anything else needed here in order to land this? @domenic

[domenic]

I'd like a chance to review the most recent changes, which will probably have to wait until Monday, but yeah, we should basically be good!

[mfreed7]

I'd like a chance to review the most recent changes, which will probably have to wait until Monday, but yeah, we should basically be good!

Sounds great! Thanks.

[domenic]

Found a mismatched algorithm call, which I'm not sure how to fix, but otherwise looks good. (Be sure to pull in my nit fix commit as well.)

[annevk]

WebKit is opposed to this. I don't think this should land.

[domenic]

Thanks for the comment @annevk. Am I to take it that WebKit is invoking the "strongly recommended" working mode criteria that "There should be no strong implementer objections to the new feature."?

[mfreed7]

WebKit is opposed to this. I don't think this should land.

Thanks for the feedback, @annevk. With reference to the Standards of Behavior, I'd like to ask you to "Take actions that are constructive, and move towards consensus when possible". In this case, I think that'd include a lot more detail about the specifics of your objection, including what obstacles we'd have to overcome in order for you to be supportive of this proposal. I presume (but would love confirmation) that your objection here is related to your comment on the standards position request. If so, could you point out the person we should be talking to in order to co-design a tooltip/hovercard solution that works for Apple?

[mfreed7]

We discussed, in two OpenUI meetings now, the utility of popover=hint in isolation. I.e. without an interesttarget feature. The developer feedback was solidly supportive, primarily because existing hovercards/tooltips today have to use popover=manual and then re-implement all of the light dismiss functionality via javascript. The popover=hint feature would remove the need to manually implement that logic.