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

[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.

[mfreed7]

Given this comment (WebKit/standards-positions#305 (comment)) it sounds like the objection has been removed. Given that it has all checkboxes checked now, and editor approval, would it be ok to land?

[annevk]

Is there a corresponding accessibility PR? This seems like the kind of feature that needs one.

[mfreed7]

Is there a corresponding accessibility PR? This seems like the kind of feature that needs one.

See this comment mozilla/standards-positions#965 (comment) from @scottaohara. It sounds like all that will be needed is to add hint to the existing list(s) - no "new" behavior is needed beyond what the other popover values already do. @scottaohara any updates on that one?

[domenic]

I will plan to merge this once we have a html-aam PR adding hint as a sibling of auto and manual.

I was thinking of doing it myself but I'm confused about the status of the html-aam repo vs. the aria monorepo per w3c/html-aam#548.

[lukewarlow]

Does this actually need any chages to aam? https://w3c.github.io/html-aam/#att-popover - the existing entry doesn't mention the auto or manual values?

[scottaohara]

the PR exists - w3c/aria#2375

but the PR essentially states that there are no mappings tied to a specific value for popover (which is why there wasn't direct mention of the manual or auto states before - because the mappings are the same)

@domenic, just responding to your comment, the HTML AAM repo is essentially an issue tracker now. all spec updates occur over in the mono (aria) repo - direct link to the html aam spec in the mono repo