Add popover=hint #9778
Add popover=hint #9778
Conversation
|
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 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. |
|
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 |
|
|
||
| <li><p>If <var>popover</var> is in <var>popoverList</var>, then return the index of | ||
| <var>popover</var> in <var>popoverList</var> + 1.</p></li> | ||
| <p>To <dfn>get the popover stack position</dfn>, given an <span data-x="html elements">HTML |
There was a problem hiding this comment.
Hmm, are popover hints guaranteed to be "leaf" / always on top of the non-hint ones?
In particular, if you stash a non-hint popover inside a hint one, then using two separate lists seems wrong? This might be an issue with auto popovers already, in a way.
It might be worth having a single popover list, and just make algorithms skip popovers given a "type"?
So to hide all hints you'll copy the full popover list, and just skip those that are not of type "hint"... Which is already kinda what https://html.spec.whatwg.org/#auto-popover-list is doing already.
But the behavior of getStackPosition doesn't make sense otherwise, I believe.
There was a problem hiding this comment.
Hmm, are popover hints guaranteed to be "leaf" / always on top of the non-hint ones?
The intention of the algorithms as-is (e.g. see <var>okNesting</var>) is that yes, popover hints are guaranteed to be either a) on top of any non-hint popovers (if nested) in the "auto popover stack", or b) stacked by themselves (with no non-hint ancestors) in the "hint popover stack".
In particular, if you stash a non-hint popover inside a hint one, then using two separate lists seems wrong?
In this case, the algorithm (again, see <var>okNesting</var>) will treat that non-hint popover as not actually being nested inside the hint popover, and the hint popover will be closed. In the same way that one independent popover will close another.
This might be an issue with auto popovers already, in a way.
Help me understand this comment. What's the issue?
It might be worth having a single popover list, and just make algorithms skip popovers given a "type"?
I'm not sure if you are proposing a change in functionality, or just doing away with the two algorithms for "auto popover stack" and "hint popover stack"? Those were just conveniences to make the rest of the algorithms less verbose - they essentially just retrieve the elements with the right opened in popover mode. There's really just one list - the top layer elements list.
If you're talking about a change in functionality, where we do away with opened in popover mode, then I'm not sure this is possible. For example, if you open a new hint that is nested inside another hint on the "auto popover stack", then that should close any hints from the "hint popover stack" but not the one already in the "auto popover stack". So you need to know which list they're in. Help me understand.
So to hide all hints you'll copy the full popover list, and just skip those that are not of type "hint"... Which is already kinda what https://html.spec.whatwg.org/#auto-popover-list is doing already.
See above.
But the behavior of
getStackPositiondoesn't make sense otherwise, I believe.
Not sure I understand what part doesn't make sense, but perhaps it's about the above questions.
There was a problem hiding this comment.
Gentle ping - any concerns with my answers above? Can we resolve this comment?
There was a problem hiding this comment.
Gentle ping @emilio, thanks!
There was a problem hiding this comment.
Sorry I had to page this back in, I think it's ok. Really sorry for the lag here.
There was a problem hiding this comment.
Great! Thank you, and no problem on the delay.
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?
See my comment in the review - let's discuss there. I want to understand a bit better. |
|
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: |
@emilio any thoughts on this one? I.e. adding support (or not) from Mozilla's point of view, for |
Fixes #9776
Explainer: https://open-ui.org/components/popover-hint.research.explainer/#popoverhint-behavior
(See WHATWG Working Mode: Changes for more details.)
/interactive-elements.html ( diff )
/popover.html ( diff )