- From: Greg Whitworth via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Jun 2023 03:49:19 +0000
- To: public-css-archive@w3.org
I love this and think that this is a _quick_ win for web UI authors. > Not exactly within the purview of the CSS WG, but it would be nice if in the future we could backport this element into HTML, to cater to the use cases that require more rich tooltip content without having to deal with all the plumbing and positioning manually. I do wonder what web compat would be like — I suspect there must be some clumsy author code out there that assumes there is only a single <title> element on the page, and it contains the document title. Though inline SVG would break those already. I think this piece should move to Open UI as we've discussed numerous times as popup landed that we'd need to introduce various popup elements that people will reach for manual for and probably get some of the a11y wrong. > As it currently stands, how the tooltip is positioned is still magic. This does make it easier to implement, but makes certain common styles very difficult: how to add a pointer when you don't know how the tooltip and originating element positions relate? I'm personally in favor of V1 leaving this as magic as you noted for MVP. > Maybe via env()? > I think it's ok if we ship an MVP where pointers are not yet possible (which still covers a large number of use cases), but the design does need to allow for this to become possible in the future. Perhaps by restricting the properties allowed in ::tooltip > @tabatkins can anchor positioning help here? Yeah, that is my thought as well. The UA stylesheet should have a recommendation of leveraging anchor-positioning, or at least not inhibiting the support for it (eg: for all I know historical implementation details make it so anchor positioning will have little to no effect). For example, Chromium allows titles to escape the window bounds so this will need some level of discussion not only of implementation but also security (maybe not since tooltip is ephemeral due to only occuring on `:hover` and doesn't contain interactive content).  That doesn't mean that `::tooltip` shouldn't happen but it does introduce the need for a conditional of some form in that the UA will probably need to revert to a behavior that supports more complex styling capabilities but I'll allow the implementors to weigh in on that (eg: how hard is it to add a drop shadow to that if it's a completely different window, how do animations work, etc)? **The name** And one final thing that I would like _some_ alignment on between Open UI and the CSSWG is the naming. Tooltip has been in HTML forever so the name here makes sense, but I'm curious as look towards additional elements to add to the authors toolbox that have the semantic and a11y bindings built in leveraging the popover primitive will we use the same name given its wide adoption across the web or utilize a different name. This is lower pri, but wanted to surface this. Thank you again @LeaVerou so much for raising this and with the Open UI community, we greatly appreciate it! Also, thanks @scottaohara for at-mentioning me so that this popped up in my inbox :) -- GitHub Notification of comment by gregwhitworth Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1581847783 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 June 2023 03:49:21 UTC