I've pushed a commit to the existing MR for this work that applies the latest rerolled patch (3178313-tree-editor-24.diff). I also synced the branch with the forked 3.x branch.
I'm working on refactoring the ReorderChildrenFunctionalTest.php to test the patch functionality of being able to reorder the full tree. Separately, it looks like there's a phpunit test failing right now? I haven't parsed it apart, but it would be helpful if someone more familiar with the existing testing pipeline could offer some guidance on what might be happening there.
inregards2pluto → changed the visibility of the branch 3.x to hidden.
inregards2pluto → made their first commit to this issue’s fork.
@Anybody I was poking around this AM to investigate whether floating-ui is in core and I found this core issue ticket ✨ Replace dialog positioning with floating-ui Active . I also was looking in the Drupal API documentation and found the floating-ui library, but it's flagged as an internal library, so I'm not sure if there are potential complications from trying to load the library via core. It seems like the move to include it as a public library in core is very recent.
I'm going to try and see what happens if I include the library as a dependency via core. I've been trying to find alternate ways of pulling it in other than CDN since Drupal generally seems to discourage that method of pulling in 3rd party libraries.
Let me update my branch to use the tippy.js library and I'll do some testing. I'll report back in a bit :)
I started a fork where I was creating a custom implementation, but I had to step away before fully completing it. Between then and now, my thinking has evolved and I agree it makes probably makes more sense to leverage an existing library.
When I was previously working on this for a government client, we ended up using the USWDS tooltip component within our styleguide to meet WCAG 2.2 criteria. It was pretty straightforward to add the necessary class to the `glossify-tooltip` twig template and have it work as expected:
{#
/**
* @file
* Markup for inline tooltips.
*
* Available variables:
* - word: the text where the tooltips applies to.
* - tip: the tooltip text.
* - tip_raw: the tooltip text in its raw format.
* - langcode: the tooltip language code.
*
* @ingroup themeable
* @see src/07-utility/_glossify.scss
*/
#}
<span tabindex="0" {% if tip %} title="{{ tip }}" {% endif %} class="glossify-tooltip-tip usa-tooltip" data-position="top" {% if langcode %} lang="{{ langcode }}" {% endif %}>{{ word }}</span>But I'm not sure how easily the one component can be pulled in separate from the full USWDS library, which would be a lot for a contrib module.
I haven't used the tippy.js library before, but do we know how it reads with VoiceOver? When we were testing the USWDS component in conjunction with the tooltip component, we went through a LOT of iteration to make it useful to a screenreader user.
On a separate note, another thing we ended up creating (which I'm hoping to recontrib back here) is a custom block that gathers up all the Glossified terms on a page and added them to a "Glossary" block at the bottom of the page. This is another technique that WCAG indicates improves accessibility, so maybe between that and the updated tooltip implementation, that should go a long way to improve the accessibility.
inregards2pluto → made their first commit to this issue’s fork.
Applied patch and confirmed that it still works against version 3.0. I know this ticket was originally made against v2.0. Is there a way we could fork this fix against the 3.0 branch that doesn't involve making a duplicate issue ticket?
Just ran face first into this same issue on version 3.0.