Create a new component: Toggletip

I think we can close this, because PopperJS is in core now https://popper.js.org/docs/v2/modifiers/offset/

Keeping this open for now as we need to update the docs & change a lot of the UI.

1. Should non-js users be able to access these tips? I don't think they are essential so maybe it's fine, but we need to be aware that non-js users might not be able to access these.
2. I think we should move the attribute conversion outside from \Drupal\Core\Render\Renderer::doRender because it feels that \Drupal\Core\Render\Renderer::doRender is too low level code for it to support this. Could this be moved to template_preprocess?
3. The toggle isn't vertically aligned to middle on headings
   😅
4. The positioning should probably take displace into account:
   

1. Should non-js users be able to access these tips? I don't think they are essential so maybe it's fine, but we need to be aware that non-js users might not be able to access these.

   I'm thinking no. Perhaps the eventual documentation for this can include a mention that system-critical information should not be provided in the toggletip (it really shouldn't anyway)

2. I think we should move the attribute conversion outside from \Drupal\Core\Render\Renderer::doRender because it feels that \Drupal\Core\Render\Renderer::doRender is too low level code for it to support this. Could this be moved to template_preprocess?

   I moved it. This also required a modification to the html_tag render element since it doesn't uses a template, but it does seem like a more appropriate place than the low level Render.php

3. The toggle isn't vertically aligned to middle on headings

   This was pretty tricky, especially making sure it works when the text wraps, but I think it's in good shape.

4. The positioning should probably take displace into account:

   Top displace was supported already, and I added side support. That was tricky! I also added positioning options for the toggle button

I'm sure there's more to do, but pushing what I have so far so folks can have a look.

Anyone wanting to give this a spin can enable the toggletip_test module and go to /toggletip-test/toggletips. It's a test module, so $settings['extension_discovery_scan_tests'] = TRUE; must be configured.

I'm switching this to "Needs Review" to make it easier to find, but it's probably more accurate to say this needs architectural review as there aren't tests etc. The functionality works and should be evaluated to what parts we keep and what should be changed. Instructions how to see tooltips locally at the beginning of the issue summary, and a video of them in action can be found here: https://youtu.be/8l6cEVwgGXw

At this moment

• **YES** Reviewing the approach, design, implementation details, etc
• **NO** Reviewing as if this is a candidate for RTBC. This is a work in progress and we're not there yet. We don't need screenshots, code optimizations, typo correction, etc until there's more agreement on how we move forward

Both items in #16 are addressed and most items in the MR. I'd prefer to wait on the theme functions until things are further along so iterating is easier as we discover new things.

Also tagging with needs tests. There's a test module already built with many toggletip use cases that tests can use.

Setting back to needs review, fully aware that at the very least theme functions and tests must be added, but making this available again for architectural review to see if any interesting feedback comes in before a day is spent on tests.

Been back n forth to this ticket. One tooltip I think would be the format tags on a text editor. People love to complain about that list of tags at the bottom, this would just make it better but still be there.

Maybe should be tagged for accessibility as well.

Should we be looking to leverage the popover API here with this polyfill for browsers yet to support it? https://github.com/oddbird/popover-polyfill

@larowlan re #21 I think this is a good route. Seems like this will be standard pretty soon. It looks like the popover API already works in most supported browsers and the Firefox support is far enough along that it can be enabled via the dev console. The one thing we'd need to check for is that the Polyfill works for Opera, as the repo does not specify it, and that appears to be the furthest one out from introducing the feature.

It's tempting to also use the CSS Anchor Positioning polyfill which seems like a nice way to handle positioning, but it seems a little too early to be sure the spec will be widely adopted in its current form. Figured I'd mention it on the off chance that this issue takes long enough to get in that there's better browser support for this (believe it or not some Drupal issues take a while 😛) Floating UI is a pretty solid library in the meantime.

I'm just putting forward this example from the USWDS. It's better than most I've tested:
https://designsystem.digital.gov/components/tooltip/

That said, I'm looking for an explicit example like I've called for here:
https://github.com/uswds/uswds/issues/5343

I don't know how often buttons stand in isolation with tooltips.

JS tests have been added. Looks like there's something wrong with the right, right-start, right-end toggle tips so the test is expected to fail on those assertions right now

Did a small test with the test module. This one tooltip seemed off.

Think the failure was random so restarted the tests to be sure.

But would this be merged as is and follow ups made?

Failure did appear to be random.

I'm confused whether this is now a tooltip or a toggletip, everyone seems to be talking about tooltip including the issue title but the code is toggletip?

Also, doesn't this require documentation and a change record on how to use this?

I think we need to guard against XSS here, left some comments on the MR

Appears threads have been addressed so moving back to RTBC.

Posted comments on the MR

This is hitting #3211992: TestSiteApplicationTest::testInstallWithNonExistingFile() fails when another test creates database tables during the test run which was supposedly fixed but was not

Looks like all the feedback has been addressed now. Waiting for #3383230: TestSiteApplicationTest::testInstallWithNonExistingFile() fails when another test creates database tables during the test run to go in that address the last test fail.

Tests passed hooray

I think the CR could still use some more information about what has been added, and how to use it.

Tagging for JavaScript subsystem maintainer review since this is adding a new JavaScript API.

Updated the CR.

Few comments on the MR

I see some places where we can improve it. Gonna work on it.

Hello!
Great initiative!

For my part, I want to note that I see two components here...

The first is a button with the letter "I" which is added to Drupal elements in different positions and which depends on another component

The second component is a completely independent Tooltip. To call it, the minimum requirement is a couple of attributes:

data-drupal-tooltip-toggle-button="Tooltip Text"
popovertarget="very_unical_id"

Which can be used by developers for example of the Navigation module:
https://www.drupal.org/project/navigation/issues/3393067

As additional attributes I added:
- [data-drupal-tooltip-placement] from https://floating-ui.com/docs/computePosition#placement-1
- [data-drupal-tooltip-on-hover]

We also need to add:
- [data-drupal-tooltip-hide-arrow]
- [data-drupal-tooltip-extra-css-class]

I think this will make the component more flexible and allow for simple evolution when we want to use for example:
https://developer.chrome.com/blog/tether-elements-to-each-other-with-css...

I added some examples in core/modules/system/tests/modules/toggletip_test/src/Form/ToggletipForm.php

Everything is working:
https://gyazo.com/eff3ddefa40ae15908de552819c75d7d

Please take a look!

I like the idea for an additional tooltip component alongside the toggletip being built here, but it shouldn't be added within the scope of this issue for two significant reasons:

• Before work even started on this, we confirmed there is an accessible way to implement toggletips. This isn't the case for tooltips, and in some cases the recommendation to make truly accessible tooltips was to use toggletips instead
• Even if a fully accessible tooltip approach was discovered, it is best implemented in a separate issue. I's not necessary to introduce them at the same time, and keeping them separate means less of a review burden and avoids the scenario where one render element is fine but the issue can't land because there are concerns about the other one.

I closed the MR to avoid additional work going into something that, while a good idea, should not be happening in the scope of this issue. The branch still exists, though, and can be used to port the code to a dedicated tooltip issue.

@bnjmnm
Hello!

I can't see problem here if we build it with 2 components still.

in js positioning of toggletip button and tooltip can be splitted
is css styles of button and styles of tooltip can be splitted.

Even if it will be used only as toggle tip only. I can provide MR with same functional but splitted. And without extra features. Then later it will be easier to switch. What you think?

I can't see problem here if we build it with 2 components still.

The problem with providing two components in this issue instead of the one proposed is

• Scope creep
• Adding a component that has not been vetted as accessible

Maybe I explained it wrong.

But:

1. Positioning a button and positioning a tooltip are different tasks in Javascript. And they should not be in one monolithic script.

2. From the point of view of BEM, these styles are also easily separated.

A11y has absolutely nothing to do with it

These components are still in one package. So scope not a reason aswell.

Did you check this MR?

I just pushed tooltip without hover attribute. I still think that placement needed.

@bnjmnm can you please take a look?

How it affects a11y and scope?

Did you check this MR?

Admittedly I didn't get very far as I saw the addition of things labeled "tooltip" when we are decidedly going the toggletip route, not tooltip. For more on that distinction, this article explains it pretty well. Since you're apparently not adding a tooltip per that understanding of it, this can be looked into further - but if this is determined to be a good approach the naming should be something other than "tooltip".

@bnjmnm Thank you for article link. Sorry but i still see no reason to merge `i` button positioning with tooltip component.

Sorry but i still see no reason to merge `i` button positioning with tooltip component.

I haven't stated a position on the merging / separation of these components one way or the other so no apology needed. Any reservations expressed thus far are specific to the terminology "tooltip", which should not be used as that is not what is being created here. This is hiding/showing additional information via a dedicated disclosure button, which makes it a toggletip. A tooltip would be something that offers additional info that is triggered by interacting with an element/text on the page that has a purpose outside of being a disclosure for the tip content. Something like tipTrigger and tipContent would be more accurate labels for what I think is being attempted here.

Yes. Sorry for the misunderstanding.

This new component may be called
WhatLooksLikeTooltipButNotTooltip
or the more neutral "Drupal tooltip"

But the most important things that are obvious to me:

1. The component name should not be a blocking issue.

2. "If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck." so maybe the term tooltip will be more understandable for developers and users.

3. Positioning the trigger is a separate task for the script and styles.

That is why I believe that we can safely split this large monolithic script into something simpler, more obvious, component-based and better supported in the future.

The splitting itself makes sense since the toggle tips consists of two parts, the button that user can click and the box that displays the message. I agree with @bnjmnm that tooltip as a name is confusing since it's often used to refer the behavior where user hovers over an element and a box with a message appears. Maybe we could try to rename the component into something that would only describe the box with a message instead of the tooltip behavior? The first idea that comes in my mind is "arrowBox" since it's essentially a box with an arrow. If we ever end up creating a tooltip component, it could reuse the arrow box component. Thoughts? 😊

Name not critical for me if it will be possible to use it somewhere outside of circle buttons logic and styles

Good names IMO.

InfoButton
Tip

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

RE: #65

laurii i think arrowbox not cool. because
i believe in can be triggered with optional arrow. as i suggested in navigation module usage.
So now we have T...tip :)

As suggested i renamed Tooltip to Tip.

ToggleTip now controls position of `i` button
Tip is only about positioning and style of T..tip

Seems logical to me.

Navigation module is in core now. https://www.drupal.org/node/3438895

It has same tooltip on board. And it works and looks more or less same.
So here we can move `tTip` outside of Navigation and add extra attribute [data-drupal-tooltip-on-focus] or something to cover both cases.

Popover API is now part of baseline https://web.dev/blog/popover-api 🙌

Hidden outdated branches.

Some issues with RTL, but it close to finish now.

Now seems all works as expected.
Please review.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Posted some small changes on MR.

Also one thing that i noted while manually testing the toggletips on toggletip-test/toggletips form is that when we click on any toggletip there is a momentary flash and then the information is positioned correctly.Can some also test this and confirm that this is happening on their setup?

yeah, i had it aswell. fixed in last commit

Removed popover polyfill, it seems not required anymore

Think it would be neat to get this into 11.1

Left some comments around the cspell lines.

After discussion in Slack seems we still need popover polyfill for Firefox ESR

Rebased and fixed php linter. Please review

How I Verified the Issue:
Here’s the process I followed to make sure the toggletip issue was fixed:

Environment Setup: I set up a Drupal 11.x-dev environment and enabled the toggletip_test module.
Test Page: I visited the test page at /toggletip-test/toggletips to see the toggletip in action.
Testing Tooltip Functionality: I checked that the tooltips worked properly on different HTML tags like h1, h2, and h3.
UI Complexity Review: I reviewed the interface to ensure the tooltips reduced visual clutter in areas with long forms and lots of information.
Reusability Test: I tested the toggletip in different areas like navigation and contextual links to ensure it could be reused without any issues.
Responsiveness Check: I checked how the tooltips behaved on different devices and screen sizes, making sure they were properly positioned.
Cross-browser Test: I tried the tooltips on multiple browsers (Chrome, Firefox, Safari) to confirm they worked consistently.

Outcome:
The toggletip issue is fully resolved! Here’s why:

Tooltips Work Smoothly: They show up and disappear as expected when interacting with different HTML elements. No glitches or interruptions.

Less Visual Clutter: The tooltips effectively reduced clutter in sections with long forms and text, making the interface cleaner and easier to navigate.

Reusability: The toggletip can now be reused in different places (like navigation and contextual links) without any problems.

Responsive Design: The tooltips fit well on different screen sizes and devices. They don’t cover up any content or break the layout.

Cross-browser Compatibility: The tooltips work perfectly across all major browsers, like Chrome, Firefox, and Safari.

I reviewed the code, backported it for a 10.x project, and played with it, and noticed one bug:
- The #toggletip code in theme.inc does NOT attach the library. It should.
- The demo form "manually" attaches the library. It should not.

All in all: Hot stuff!

Fixed feedback and add small fix in case of wrong context of textarea.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rebased. Please review.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Seems some php linters were changed.
I have no power here ;)

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

I've tested MR5221 in Safari 18.0.1 and latest Edge and Firefox with macOS 14.7 with and without VoiceOver active. And in Safari the Toggletip is not shown/expanded at all.
In edge and Firefox am able to expand it by pressing space or the return key, by clicking the icon with the mouse, or with VoiceOver active by pressing VO-space, each time the toggle tip is expanded. while in Safari nothing happens when i press, space, return, VO-space or by clicking with the mouse, the toogletip remains collapsed.

The console in Safari shows the following warning: The atDescription property of toggle button 27qvhmhw12i-toggle is empty, and is using a default value. To be sufficiently accessible, this property should describe the information this button reveals. in toggletip-js:133

Setting it back to needs work

and i've tested the toggle with voiceover in edge. unfortunately keycstr the app i am using to show the keys i've pressed isnt showing any voiceover keycombinations (anything with VO = ctrl and option) . but if i wouldnt have the visual context i would consider the toggle tip experience in the aural inteface challenging. i've recorded a short video (voiceover.mp4)

• when the first toggle icon gets into focus i press VO-space so the toggle expands
• i then i've pressed VO-arrow up and the toggletip expands.
• i then tried VO-arrow left. the focus gets to "a container render array" with the voiceover cursor.
• i press VO arrow right and the voiceover cursor gets back to the toggle icon. i press VO arrow right again. then i press VO arrow down and then finally i press VO-arrow up.
• voiceover then announces "there is a group with three items". but the content that is automatically announced now starts with "the story opens", "CONTAINER: a movie" is omitted. (*i am also unsure how to reach that paragraph. i was unable to by stepping through with the voiceover cursor same as if i press VO-a to read through everything the content on the page is getting announced not the content within the toggletip)
• with the toggle tip still expanded i then pressed the tab button. the focus went to the "mystery" link within the toggletip and then to the next info button which is next in the tabindex outside the toggletip.
• on the second toggle tip i then did again VO-space. but in contrast to the first toggletip i am unable to get the content of the toggle tip announced. i've tried again in the VO- arrow left, VO arrow right VO arrow down VO arrow up.. for the first three nothing happens but for VO arrow up the voice over cursor gets to the sentence right before the info button and not like for the first toggletip announces the content of the toggletip.

And one additional detail. the toggle button border has #d3d4d9 against the white background, which leads to a color contrast of only 1.5:1... SC1.4.11, to being able to recognize the button, would require at least 3:1

I found original bug with safari.
https://github.com/hotwired/turbo/issues/1245

If i just create node with button and popover it works. But if it is inside any form. it doesn't work in safari

Hi @finnsky and all,

this is a great step forward, and this is why i cherry-picked this early for use in one project. (And i see my initial feedback was helpful, nice!).

Here is some more feedback:
- I like the '#help' approach, it makes altering existing elements possible (without additional wrapper).
- In the current approach, the trigger button is added with javascript, leveraging a library that does the positioning. This gave us some pain in our project.
- (1) First, js-added stuff is a PITA for theming (it's like select box improvements, where we switched to sumoselect, as it responds to CSS).
- (2) But the killer was, the javascript totally breaks when the element is not in the viewort initially, like with tabs and other disclosure elements.
- I doubt that (2) can be healed robustly, and tbh. in face of (1) we don't think putting effort in it is worth it.
- The result was, that we had to abandon this approach, and roll our own.

You can find our approach here and pick whatever you like: https://gitlab.com/geeks4change/modules/h4d_help
I suggest using this approach, because:
- It builds the markup server-side, so it works without JS (at least soon-ish, when the polyfills are obsoleted)
- It is stylable via CSS
- It works with tabs and other disclosure elements
- Apart from the popover polyfill, it uses anchor positioning for the toggle and help (native in chromium-based browsers, polyfilled in others) in its anchor-position variant. (The anchor-positioning Insert-Area variant is even nicer "soon" but not polyfilled yet.)

So needs-work for that imho.

I think it is ok about button positioning with js.
But we need to clean different position calculations for button.
And move them to css:has()

This would be a great feature! We could all use more time to work on Drupal, but if you have time at some point, perhaps it's most likely to get done, if you implement the changes you suggest in comment #107 @geek-merlin?

Which element types support '#toggletip'? Should the CR say which ones, or how to identify which ones?

We're putting the trait into so many elements -- what's the reason for not just putting it in the base class?

'content' => '<p>My content inside the toggletip</p>',

Can you put a render array inside this instead of HTML?

@joachim
@phenaproxima

Thanks for the review, it was really needed!
I simplified the code based on your recommendation.

Should the CR say which ones, or how to identify which ones?

Yes, it's possible! The current CR doesn't reflect the status of the code.
I want to first make sure everything is correct from a backend perspective and then prepare a CR.

Can you put a render array inside this instead of HTML?

Yes, that's a good idea!

Just a note on #107, I really like the idea of using a component based on anchor positioning, since we are working with what is native in browsers, and a lot less for us to maintain with a custom implementation.

Added to that anchor-positioning has just become stable in Firefox (release 147 about 3 weeks ago):

Support for CSS anchor positioning was added, enabling tethering elements. The anchor-positioned elements can then have their size and position set relative to the anchor elements to which they are bound.

It's definitely worth looking into that as a solution.

Well, this MR already uses anchor-positioning to position buttons.

Sorry to be that guy but with default_admin added assuming we will need to take that into account. Stable9 I'm not 100% sure as know some time we don't touch that (but don't remove just mentioned)

@markcontroy as the markup maintainer are you fine with this approach that we could maybe remove that tag?

@smustgrave - yep, looks good to me. Thanks for checking.

Not sure that this passes the Hoverable condition of SC 1.4.13 Content on Hover or Focus (Level AA).

The hover examples in the demo do not let me move the pointer from the trigger to the additional content.

From the above link:

Hoverable

The intent of this condition is to ensure that additional content which may appear on hover of a target may also be hovered itself. Content which appears on hover can be difficult or impossible to perceive if a user is required to keep their mouse pointer over the trigger. When the added content is large, magnified views may mean that the user needs to scroll or pan to completely view it, which is impossible unless the user is able to move their pointer off the trigger without the additional content disappearing.

Another common situation is when large pointers have been selected via platform settings or assistive technology. Here, the pointer can obscure a significant area of the additional content. A technique to view the content fully in both situations is to move the mouse pointer directly from the trigger onto the new content. This capability also offers significant advantages for users who utilize screen reader feedback on mouse interactions. This condition generally implies that the additional content overlaps or is positioned adjacent to the target.

Additional note to my last comment:

Adrian Roselli called out a tooltip example on Web.dev for failing the Hoverable condition: https://github.com/GoogleChrome/web.dev/issues/8959

When I move my pointer to the tool-tip to try to copy the content, the tool-tip disappears. This violates the Hoverable clause.

We generally trust Adrian Roselli, and SC 1.4.13 is pretty clear.

Also from the link in #120:

Hoverable
If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

So, I'm going out on a limb that it does need to pass the Hoverable condition and flagging for accessibility review to confirm.