Title tag and tooltips

I feel that a lot of developers do not use the title attribute for tooltips, which is disappointing. This leaves developers to start creating custom tooltips because the title attribute does not give enough options.

I think there should be a way to at least provide a set of options for the title attribute like:

• timeToShow where a user can specify how long a user should hover before the tooltip should be shown
• onShow/onHide to do things after and before the title shows
• showEvent/hideEventthat will accept a string eventname` of the event to dispatch when the tooltip shows/hides
• some way to customize the look and style of the title attribute with css (although not sure if this is already implemented

I’m thinking this could be available at the JS level, but not sure how this could be implemented using strictly HTML.

I don’t mind making a formal proposal for this, but just wanted to get some feedback on whether or not browser vendors could implement.

I’m sure browser vendors could implement it, but I’m not sure how many developers would use it even then. Speaking as a developer, I can’t recall the last time I’ve used a tooltip. If the attributes you propose existed, I’m still not sure I would use it.

However, I’m not the only developer in the world. Others may have different opinions, of course. Additionally, the existence of these attributes would not have any negative effects. It’s just something you’d use if you wanted to.

Thanks. It’s good to know there may not be any technical limitations of implementing this.

If the attributes you propose existed, I’m still not sure I would use it.

Interesting. Are you saying that you wouldn’t use it because you don’t need? Or are you saying that you still would use a custom one even if you needed it? If the latter, I’m curious of why.

I do agree that tooltips are not used quite as often but some people do use these, especially in corporate environments like mine where the web application/website requirements are set in stone (developers have no choice but to use them) and the application needs to be flexible enough show information in a lot of different ways, including tooltips.

I should also note that there is a lot of tooltip usage on the web these days. Github uses them when you hover over avatars, Facebook uses them when hovering over share counts/comments, Linkedin uses them rather extensively when hovering over a user’s profile snippet, Amazon in multiple areas when navigating lists.

Of course developers can continue to use custom tools for this, but having browsers support this natively will have a lot of performance gains.

Are you saying that you wouldn’t use it because you don’t need? Or are you saying that you still would use a custom one even if you needed it?

The former. I’ve just never experienced the need for it. Of course, there are certainly times when it could be deemed necessary. One example I can think of off the top of my head is XKCD. They have tooltips on all their cartoons, and it would likely improve the UX if there was a time attribute.

It should also be noted that if browser vendors implement these, developers wouldn’t have to do custom absolute positioning hacks that the custom implementations would require. Sometimes it is not sufficient for the custom built tooltip to just be nested relatively under the parent element that it is describing. For instance, if tooltips are too close to the edges of the viewport, the user might not be able to see entire message. In this case, a very hacky solution will need to be implemented by the developer, which seems silly if the title tag already does this and is already supported by browser vendors.

One reason why title isn’t used more often could be because there’s no way to trigger it via JavaScript; the tooltip only shows up when the user hovers over the element with a mouse cursor.

Another (bigger) issue is that, by default, the user cannot trigger the tooltip using the keyboard alone; until the lack of keyboard access it addressed, I wouldn’t recommend extending it with more functionality.

the user cannot trigger the tooltip using the keyboard alone; until the lack of keyboard access it addressed, I wouldn’t recommend extending it with more functionality.

I think the keyboard issue can easily be addressed. Can any browser vendor reps confirm?

Although i have to admit to using them sometimes, the title attribute is problematic for internationalisation too. There’s no way to declare the language of the title attribute text if it’s different than that of the element content (which can be problematic for voice browsers or if say the tooltip text was presented to a Chinese reader using a Japanese font because that’s the browser’s default for ideographic text).

Additionally, markup can’t be used, eg. to establish the language of a part of the title attribute text, or to apply directions for bidirectional text using markup.

Not to mention any other type of rich text you’d like to apply to title element text.

And btw some UX people recommend against tooltips because they are hard for some people to read, or cause problems on devices that don’t have mouse hovering.

So if alternative approaches allow the content author to use proper markup solutions that’s much better in my view. Having said that, a standard element that allows browsers to hide and show the information in an interactive way, and that allows various alternatives through attributes, without the content author having to reach for a javascript library would be interesting.

It’s not trivial, but nor is it as hard as lots of things browsers do. The issues are

1. If you add everything with a title, but that wasn’t focusable, into the tab order, users might not be best pleased.
2. Where to put the tooltip.

For users who can only navigate with a tab key, a lot of pages already have too much stuff in them and take a stupid amount of time to work. This is why old Opera, and screen readers, generally have extra navigation paths. But for keyboard-only users without a screenreader that doesn’t help, you just gave them more work.

When you focus something with a keyboard, any tooltip should not cover the bit you are looking at. But it should be near the start, since you might have a title on the main element… This isn’t an insoluble problem, but will take designers some thinking time. When the tooltip follows the mouse cursor it’s easier to move out of the way…

I wonder whether the details element - used in reverse, as it were, so that on expanding it actually provides a summary of the thing it’s wrapping - is a better path forward. I mean something like

<details>
  <summary><input type="date"></summary>
  Select a date or enter in YYYY-MMM-dd format
</details>`

Not that details is implemented a lot better in terms of accessibility, but it does allow you to deal with a lot of the problems @r12a talked about.

It doesn’t offer much in the way of styling though

I don’t think the tooltip should be separately-focusable from the item that it is describing. I think of a tooltip as helpful text or a quick way to describe the content with which it is associated.

Here’s how I see it:

For screen readers: focusing into an element with a tooltip would simply read the content of the tooltip/title attribute (as they currently do). Like mentioned above, it is just a helpful description of the item being focused.

For keyboard-only cases: Would it be possible to always show the tooltip when a user focuses into the element the tooltip is describing? At that point it’s just ensuring that the tooltip does not visually cover the content, which seems doable. This could also work for mobile devices.

I wonder whether the details element - used in reverse, as it were, so that on expanding it actually provides a summary of the thing it’s wrapping - is a better path forward

Interesting idea, but i think the <details> element is too robust when compared to a tooltip. You can inject anything into it which should not be the case with a tooltip/title.