-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
popover=hint #305
Comments
I think it would be good to address the issue we discussed in the last WHATNOT about features participating in the top layer concept all needing to be able to nest. As this would be another such feature and should ideally build on that envisioned infrastructure. |
Yep, that's a good point. I think that should be roughly orthogonal to this feature, or at least should "just work", but I'll get that prototyped to see what it looks like. |
Some other thoughts upon reading more:
|
Yeah, we discussed this at some length in OpenUI, in various places. But the main discussion is located here: openui/open-ui#532. You'll note in my OP I agree with you that the primary use case is "tooltip" (and also in this comment openui/open-ui#532 (comment)). But there was some pushback to using the name of a use case for the value. I'd personally be fine with
The idea is that auto can't be nested inside hints. The behavior will be that the topmost popover ancestor algorithm will be modified so that it does not detect an auto "inside" a hint as forming an ancestor relationship. In practice this means that opening the auto will cause the hint to close.
I'm almost done implementing the modal dialog and fullscreen interactions thing, and I've prototyped it for both auto and the new hint proposed behavior. You'll have to trust me for now, but it seems like it'll fall out fairly naturally. |
@mfreed7 I left a comment on the Open UI issue. I can't reopen. I feel pretty strongly naming should be consistent across the web platform. Getting |
Thanks. I commented there also and added that issue back to the agenda to talk about again. |
Hey @mfreed7, we discussed this a bit again and one question we have is whether this is going to be the final |
We (Chromium) don't have any plans to pursue other values. And I also haven't heard any requests for other values/behaviors. The set of three ( |
Any further thoughts on this one? There's now an approved spec PR and a prototype implementation that seems to work nicely. We'd love to get multi-implementer support. |
https://bugs.webkit.org/show_bug.cgi?id=275048 here's the bug |
Colleagues and I discussed this quite a bit after more closely looking at the primary use case of this feature (as well as For certain element types there are workarounds (e.g., As such we are currently leaning negative on this idea. |
Thanks for the feedback!
This sounds like you're actually supportive of trying to solve the "tooltips" use case, am I correct? You say that rich tooltips are a valuable idea, and the existing platform support is relatively bad, especially for mobile. Just confirming that your view is positive on the use case, but negative on the particulars. If I'm wrong about that, please help me understand the view.
I agree that the text-only workarounds (which are typically adding the plain-text
I'm actually fine with either solution! Solution 1, which currently doesn't exist, is obviously better, once you figure out what it is. In the meantime, solution 2 actually does solve a problem for users today, in that it provides access to otherwise inaccessible content on mobile. The current state of affairs for rich tooltips on the web today is that they're most often completely broken and inaccessible to touch users. Please help me solve this problem! |
One additional comment here. This standards position request is about the |
In our view they are tied. If we don't have a good cross-platform solution for rich tooltips we should not be adding anything that further encourages their use. |
Combining this with the comment above, it sounds like you're supportive of tooltips, but don't feel there's a good solution for touch. In that case, please help us design a good solution! The best we have right now is one of these two things:
I'm in favor of #1, because I believe it leaves some flexibility to browser vendors and even hardware manufacturers to innovate on touchscreen mechanics. However, I am willing to live with #2 if that's what it takes to help move tooltips forward on the web. But please help me come up with a solution that works for WebKit. Hopefully "we don't know how to solve this" isn't how we leave this. |
WebKittens
No response
Title of the spec
popover=hint
URL to the spec
whatwg/html#9778
URL to the spec's repository
https://github.com/whatwg/html
Issue Tracker URL
No response
Explainer URL
https://open-ui.org/components/popover-hint.research.explainer/
TAG Design Review URL
No response
Mozilla standards-positions issue URL
mozilla/standards-positions#965
WebKit Bugzilla URL
https://bugs.webkit.org/show_bug.cgi?id=275048
Radar URL
No response
Description
This is related to, but not blocked/gated by, the invokers proposal.
See also, whatwg/html#9776.
Note that the spec PR is slightly out of date and is being updated to include the "hint stack" concept.
The text was updated successfully, but these errors were encountered: