- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Jul 2023 17:42:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] Standardize tooltip styling and expose as `::tooltip` ``, and agreed to the following: * `RESOLVED: Standardize a ::tooltip pseudo, with a few properties, to style tooltips` <details><summary>The full IRC log of that discussion</summary> <fremy> lea: proposal as of a few days ago<br> <fremy> lea: tooltip styling has been brought up multiple times<br> <fremy> lea: first was tantek, but there were many other ones<br> <fantasai> s/times/times by multiple people since 2000/<br> <fremy> lea: every single time, there was little pushback<br> <fremy> lea: yet it never went anywhere<br> <fremy> lea: many websites have custom code to style tooltips<br> <fremy> lea: and most of these stylings are not very fancy<br> <fremy> lea: mostly color, background, font-style, customizing the delays...<br> <fremy> lea: because browsers sometimes wait too much<br> <fremy> lea: but all of this requires chaning the markup, because the element must wrap the location<br> <fremy> lea: so this is pretty heavy-weight, and it's easy to forget some accessiblity requirements<br> <fremy> lea: so, I really think we should do something about it<br> <castastrophe_> +1 lea I argued so hard against our library building a tooltip web component at work<br> <fremy> lea: and the most common proposal is a pseudo-element acceting a few properties<br> <masonf> q?<br> <masonf> q+<br> <fremy> lea: since the tooltips can escape the window bounds, it could make huge tooltips and confuse the users if everything is customizable<br> <fremy> lea: but some properties sound fine<br> <una> q+<br> <fremy> lea: later on, we can add positioning, maybe using anchor positioning, but magic is fine for MVP<br> <gregwhitworth> q+<br> <fremy> lea: content itself can probably be magic too, because SVG and HTML do this differently<br> <fremy> lea: keyword vs totally magic, not that important<br> <fremy> lea: we can narrow this down later<br> <fremy> lea: later on, we can add html elements, attributes, focusable, etc...<br> <fremy> lea: but I see consensus on the basics<br> <fremy> lea: so, are there implementors that are concerned about this?<br> <gregwhitworth> note, I'm not an implementer anymore :P<br> <fremy> lea: (also, maybe javascript-created tooltips?)<br> <castastrophe_> A reference for anyone interested in Adobe's tooltip web component: https://opensource.adobe.com/spectrum-web-components/components/tooltip/#example<br> <fremy> lea: maybe in that case, bound to the frame<br> <castastrophe_> And an example from Shoelace: https://shoelace.style/components/tooltip<br> <masonf> q?<br> <fremy> lea: so, what are the constraints holding us back here?<br> <gregwhitworth> ack gregwhitworth<br> <emilio> q+<br> <astearns> ack masonf<br> <fremy> masonf: thank you for bringing this up<br> <masonf> Shameless plug for popover=hint and hover triggering: https://open-ui.org/components/popover-hint.research.explainer/<br> <fremy> masonf: I pasted our shim in the chat, a more complex version of this<br> <ntim> q+<br> <fremy> masonf: but for most use cases I have seen, a few styling would go a long way<br> <fremy> masonf: I would love it to have the tooltip in the window bounds, so that styled tooltips are consistent depending on how much they are styled<br> <fantasai> s/complex version of this/complex version of this using popover/<br> <fremy> masonf: I would prefer some things to remain magic, like delays, but ok<br> <fremy> masonf: html uses the title element, but also some aria attributes<br> <astearns> ack masonf<br> <astearns> ack una<br> <fremy> una: thank you for opening this issue<br> <myles> q+<br> <lea> q?<br> <fremy> una: the first thought that comes to mind, can this also style "form error messages"<br> <masonf> we should support the title attribute for HTML, or the <title> element with svg.<br> <fremy> una: does that also apply to "alt text" over images?<br> <fremy> una: maybe, this can be a "style bag" rather than a pseudo-element<br> <lea> q+<br> <emilio> q- later<br> <fremy> una: but, if you have a popover, that gives you multiple elements, and more flexibility<br> <fremy> una: so, the limitations of this proposal, are they acceptable enough, is my first question<br> <fremy> una: my second question, is that, how does this related to other features like alt text<br> <astearns> ack ntim<br> <SebastianZ> q+<br> <fremy> ntim: outside of the window bounds, we would want to filter down to a list of properties<br> <masonf> q+<br> <fremy> ntim: also, probably some constraints like size or box-shadow<br> <astearns> ack myles<br> <fremy> myles: further than that, tooltips ship with the OS, and the platform usually don't allow much styling<br> <fremy> myles: so, one limit, I would start with what the platform allows<br> <gregwhitworth> q+<br> <fremy> myles: also, tooltips outside the window, requires nsWindow etc...<br> <fremy> myles: this is costly if we want to do that<br> <fremy> myles: but I understand that from the issue, the benefits are also quite high<br> <fremy> myles: so, this is not "easy" at least<br> <fremy> astearns: the rest of the proposal doesn't get to that bar?<br> <astearns> ack lea<br> <fremy> myles: yes<br> <fremy> lea: I think errors for form controls are a different pseudo, because they have different constraints<br> <astearns> s/the rest/the hard part is displaying outside the window. The rest<br> <fremy> lea: there are commonalities, but also major differences<br> <fremy> lea: I'm not seeing the alt text connection, which I think is more of a ::part() I think<br> <una> q?<br> <fremy> lea: to reply to ntim, I would definitely favor an allow list<br> <fremy> lea: but, just an allow-list might not be the whole story<br> <fremy> lea: I think many authors want padding, rounded borders, etc...<br> <fremy> lea: to reply to myles, I think this would generate non-native tooltips<br> <myles> q+ to reply to that<br> <fremy> lea: because what authors do today is this<br> <gregwhitworth> ack gregwhitworth<br> <fremy> una: what do you think of popover=hint?<br> <fremy> lea: it can probably solve some, but it requires a lot of code, and doesn't play natively with title attribute etc<br> <fantasai> s/what do you think of popover=hint/do you think popover=hint solving these problems?<br> <fantasai> s/solving/solves/<br> <gregwhitworth> I agree with Lea on this<br> <fremy> lea: more complex use cases would like it<br> <astearns> ack myles<br> <Zakim> myles, you wanted to reply to that<br> <lea> q?<br> <fremy> myles: if this is not native tooltip, for us this is not a tooltip<br> <fremy> myles: I would not want to call this a tooltip at this point<br> <gregwhitworth> q+<br> <astearns> ack emilio<br> <fremy> emilio: indeed, we need to answer whether the content area is enough (even for iframes)<br> <fremy> emilio: if not, non-native tooltips are not ok<br> <lea> q+<br> <fremy> emilio: but we already discussed this for <selectmenu> elements<br> <TabAtkins> These are conditions that people already live with when they're using the custom JS-driven versions.<br> <fremy> emilio: so, if we are, this seems workable<br> <fremy> emilio: if we don't think this is sufficient, I would not think that this is doable (in a reasonable amount of effort)<br> <gregwhitworth> note, only when ::tooltip is present<br> <fremy> emilio: so, would browsers engines be fine with that?<br> <fremy> emilio: and I have the impression that myles isn't confortable with that, maybe?<br> <fremy> emilio: personally, I guess I'm fine, but needs some thoughts<br> <lea> q?<br> <fremy> astearns: TabAtkins replied on IRC that people today have those limitations, so those are probably ok with them<br> <gregwhitworth> not if you don't use ::tooltip<br> <fremy> emilio: but those aren't native, right?<br> <fremy> TabAtkins: yes, they override<br> <astearns> ack SebastianZ<br> <fremy> SebastianZ: I wanted to say more about the security issue<br> <fremy> SebastianZ: the native tooltips should still be able to actual document<br> <fremy> SebastianZ: right now, UAs can clip the text etc..., UAs can create new rules based on size etc...<br> <fremy> SebastianZ: do we have concensus that this is something that should be worked on, at least?<br> <masonf> I'll rejoin<br> <astearns> ack masonf<br> <fremy> masonf: <confusing echo><br> <astearns> ack gregwhitworth<br> <fremy> gregwhitworth: personally, I never envisioned the non-native tooltips to escape the bounds<br> <fremy> gregwhitworth: and I think, as an author, that is reasonable<br> <fremy> gregwhitworth: but even then, we can start with simple properties anyway<br> <fremy> gregwhitworth: una pointed out alt text, and some sites use them as a tooltip in some cases<br> <fremy> gregwhitworth: also, agree with myles, maybe this shouldnt be called a tooltip<br> <fremy> gregwhitworth: but "the box that pops up when tooltips happen"<br> <gregwhitworth> +1 to masonf<br> <fremy> masonf: also, pointing out, many sites refuse to use these tooltips<br> <lea> +1 to masonf too<br> <fremy> masonf: and these sites accept the trade-off about off-bound positioning<br> <fremy> masonf: personally, I don't even see that native tooltips are that necessary<br> <fremy> masonf: I would not mind a single path, custom ones<br> <fremy> masonf: they would be simpler<br> <astearns> ack lea<br> <fremy> astearns: removing is difficult on the web platform, but that's an interesting idea<br> <fremy> lea: can we get some data about what tooltips can do on native platforms?<br> <fremy> lea: that would help shape the discussion<br> <fremy> lea: also, if it behaves like a tooltip, I feel it should be called a tooltip<br> <fremy> lea: scrollbars were in that list of strange things once, but we resolved that built-in customization is better than wild hacks<br> <masonf> astearns, the behavior of the title attribute (generating a "tooltip") is not standardized, so we're not really removing something. We're better defining it and making it more developer-friendly.<br> <emilio> q+<br> <fremy> lea: mutltiple codepaths are fine on the web platform, like for <button> so I don't buy that objection<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fremy> lea: if we can get rid of the native ones, I don't mind personally<br> <fremy> lea: eventually, we can probably find constraints<br> <fremy> lea: most sites that have enough resources to make a choice<br> <fremy> lea: do not use the native ones<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to comment on alt text<br> <una> +1 will be much easier to build without expanding window bounds and that doesn't sound like a top requirement to support authors here<br> <fremy> lea: also, I would object about "title" as the name, because "title" was an odd name<br> <fremy> dbaron: some feedback we once got about alt text in tooltips<br> <TabAtkins> Basically, webcomics.<br> <fremy> dbaron: we stopped doing this by default<br> <astearns> ack emilio<br> <fremy> dbaron: because alt text was used as a hack, instead of a real description<br> <fremy> dbaron: so, this change was intentional<br> <fremy> emilio: multiple codepaths are fine, but also the difficulty of them is important<br> <lea> q?<br> <fremy> emilio: for me to become more serious about this, I would like to hear some consensus from implementors that the bound restriction<br> <lea> emilio: Of course the code path is different for buttons, my point was that from the author side there is precedent for rendering going through a different code path once CSS is applied.<br> <fremy> emilio: if we get consensus on that, I'm fine with this<br> <astearns> ack fantasai<br> <lea> We have "make simple things easy and complex cases possible" in our TAG principles :)<br> <fremy> fantasai: personally, I agree with lea, we need to bridge the gap between "you control nothing" and "you have to implement javascript, accessibility, etc..."<br> <lea> s/complex cases/complex things/<br> <fremy> fantasai: right now we don't have that middle ground<br> <fremy> fantasai: I also feel like if it looks like a tooltip and behaves like a tooltip, let's call it a tooltip<br> <fremy> fantasai: and for the content, I think we are ok with using the same text as it would do today<br> <fremy> fantasai: I think it's fine, ::tooltip should allow you to style it<br> <fremy> fantasai: given the facts a lot of authors seem fine to keep it in the window bounds, I think it's reasonable<br> <fremy> fantasai: in terms of positioning, we can punt this for now, and come back to this later<br> <masonf> +1 to everything fantasai just said.<br> <lea> also +1 to everything fantasai just said!<br> <fremy> fantasai: but, globally, I think it's a net benefit if (a) it's easy (b) <missed> (c) accessibility is preserved<br> <lea> q?<br> <lea> q+<br> <miriam> q+<br> <nicole> q+<br> <fremy> lea: I would not mind the bounds restrictions to depend on the used styles<br> <fremy> miriam: quick question<br> <fremy> miriam: I have seen many a11y recommendations to not use the title attribute<br> <fantasai> s/<missed>/UA handles positioning and appearance logic so it's not error-prone/<br> <fremy> miriam: is that an anti-pattern?<br> <fremy> chrishtr: I have heard the same, it's often much too loud for them<br> <fantasai> perhaps it should be less loud...<br> <fremy> astearns: I'm wondering, can we resolve on a ::tooltip pseudo, with a few properties allowed, and figure out the details later in little pieces<br> <lea> allowlist and window bounds are related, they should be part of the same issue<br> <masonf> +1<br> <lea> +1<br> <fremy> astearns: any direct response to that proposed resolution?<br> <gregwhitworth> +1<br> <fremy> astearns: any objection to this?<br> <bramus> +1<br> <castastrophe_> Very exciting!<br> <una> awesome :)<br> <gregwhitworth> only 23 years<br> <lea> 🎉<br> <fremy> RESOLVED: Standardize a ::tooltip pseudo, with a few properties, to style tooltips<br> <masonf> :-) nice!<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8930#issuecomment-1644333441 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 20 July 2023 17:42:36 UTC