I think we should stop adding title tool tips to the site.
They don’t aid in accessibility
They aren’t usable on touch/mobile
They have to be internationalized
Many people don’t even know that things can be hovered over, especially since it’s hit or miss what has them and what doesn’t
For example, all of these things on the home page have tool tips but they don’t even add good information to the experience:
If it weren’t for localization/internationalization I probably wouldn’t care. But we get very little benefit for the cost of translating them all (when we think about all the languages we are supporting now).
Thoughts?
4 Likes
I just realized that the tooltips over the “level” icon is the only way to get an explanation of what that means. E.g. for DN1:
It’s kind of a separate issue, but the fact that this information is available only in a tooltip is not great.
1 Like
The level icon that is meant to be a tree always makes me think of broccoli.
Generally, I think we don’t need them. Tooltips that is. I like broccoli
6 Likes
tkk
February 6, 2024, 8:55am
4
Thanks, Ven Pasanna, can’t make it unseen now - love broccoli!
3 Likes
Perhaps it is broccoli. Slightly bitter, not everyone likes, but it’s very good for you.
4 Likes
sujato
February 8, 2024, 7:07am
6
Good suggestion, we should definitely remove as many as possible.
As background, I want to remove the native title
attribute completely and where necessary replace it with a high quality, accessible tooltip.
Our components are from Google’s material web project, and I have been patiently waiting many many many years for the Google team to make a tooltip component . Here’s what I’ll look like when they’re done.
This is part of a larger issue, because a tooltip is most heavily used for text notes. Currently we use a very elegantly primitive CSS implementation, but we want to do it properly. There’s a long standing issue for this:
opened 10:07PM - 03 Dec 21 UTC
Type: explore
## terminology
Let us use "notes" to include both "comments" and "variants". …
## background
Bilara texts have support for notes as "comments" (on translations) and "variants" (on root texts).
These are implemented using a pure html/css approach. I did this because of a lack of tooltip elements in material web components, and because I couldn't see an elegant solution in third-party libraries. They were all too big and not what we wanted.
There are, howver, a number of problems with this approach:
- each note has to be inserted twice, once as `data-tooltip`, once as span content.
- the `data-tooltip` version must be stripped of any HTML, which adds complexity to the process and limits usefulness (you can't link to texts, for example.)
- it's not great for accessibility.
- it's brittle and a simple CSS change can easily disrupt the whole thing.
- The sidenotes have no means to avoid collisions, so they just lay on top of one another.
## possible solution
The most widely used tooltip library is popperjs. The author of popper is releasing a new library that looks ideal for our case: Floating-UI
https://www.floating-ui.com/docs/motivation
Rather than a simple tooltip idea, this exposes an API for positioning floating elements, thus it may be ideal for us to display notes in different forms. Using this approach, we can possibly mitigate all the problems outlined above.
- small (about 10kb gzipped)
- modern, tree-shakeable code: add features as you need
- use just one set of content for sidenotes and tooltips
- avoid collisions of sidenotes. (not implemented yet)
https://github.com/floating-ui/floating-ui/
## aims
The implementation would aim for essentially the same outcomes as the current implementation, but obviously solving the problems listed above. It would aim to be small. It should use the existing HTML structure. (It is possible to change this of course, but I would rather not.)
- [ ] Insert content only once (as span content).
- [ ] render HTML
- [ ] test for accessibility (maybe add ARIA?)
- [ ] tooltips should be positioned properly relative to viewport (test on mobile, etc., and also when viewport is changed)
- [ ] on mobiles, would it be best to display the tooltip at the bottom of the screen?
- [ ] there should be a mechanism to hold the displayed tooltip so links on it can be opened. Perhaps hold `ctrl` while hovering?
- [ ] tooltip anchor should be positioned properly (i.e. with a space after not a space before as currently)
- [ ] test tooltip anchor for visibility
- [ ] when the window is narrowed, the sidenotes become inline notes (as currently)
- [ ] do not display anything if note is empty (currently a stub is displayed)
- [ ] collapse sidenotes column if there are no notes (currently fixed width)
## many notes as sidenotes
We have to figure out a way to display the sidenotes in cases where there are many notes. Currently they overlap.
Two approaches have been proposed.
### get pushy
Currently the vertical height depends solely on the text, and the sidenotes have to fit in with that. We can change this by simply removing
```
.comment, .variant{
position: absolute;
}
```
Now the notes take up vertical space, and they push the text down if need be. This lets us display all the notes, but it results in a lot of gaps in the text column. As much as possible, the text column should be readable and gaps minimized.
We can mitigate this by expanding the horizontal space available to notes, thus minimizing vertical space. This is controlled by:
```
.translation, .root {
grid-template-columns: foo bar;
}
```
### collision avoidance
If that approach does not work, or perhaps as an alternative for users, we can use collision avoidance. In this approach, where a sidenote collides with the note below, it is truncated vertically, leaving a small gap before the next note, and expanded on demand by the user.
There should be a visual indicator of this. Here is a mockup.
![Screenshot from 2023-03-27 09-06-12](https://user-images.githubusercontent.com/6112010/227807593-5b560e12-a49d-45d3-8698-45cf784748ba.png)
In this dummy example:
- top note is truncated
- ellipsis is added to text
- corners are cut at right angles
- dashed border on bottom
- expand icon is added
Anyway we can finesse the details, but you get the idea.
Per Marein's comment, Floating-UI does not implement this ATM. However, I just checked back with this issue, and, randomly, as of 12 hours ago the author has started working on it!
https://github.com/floating-ui/floating-ui/issues/1440#issuecomment-1484038095
Note that what we require for collision avoidance is much simpler than the general implementation they need. Because the sidenotes are aligned with the text, the vertical height can be calculated from the position of the start of the text segment. Also, we only need adjustment in a vertical direction.
- [ ] effectively deal with many notes in sidenotes, either by getting pushy, or by avoiding collision, or offering a user the choice.
## styles
Generally the styles should remain similar to what they are now, unless there is reason to change. We could introduce some animation for fluidity, remembering to respect `prefers-reduced-motion`.
Basically the idea would be to use a single tooltip implementation across the app.
Meanwhile, it would certainly help to remove unnecessary tooltips. I don’t think there are very many? But worth checking them out.
And if someone wants to look into floating-ui or something similar, that would be great.
1 Like
[Oh my god. I read this message in an email and automatically corrected your “typo” to read “Here’s what it’ll look like when they’re done.” I clicked through to the forum and could not figure out what was going on.]
There are not many. I will hunt them down. And throw them into a bog.
1 Like