In #1490402: Redesign tabs and the content header we introduced a new tooltip style for the shortcuts link in the header.

#2170947: Visual cleanup of Edit shortcuts link could use this same style and it's possible other interfaces could have a use for a tooltip. Let's abstract it out into it's own CSS component.

Remaining tasks

- Decide on an appropriate jQuery tooltip plugin
- Implement it
- Restyle the tooltip to match the tour tooltips
- Test in Bartik and Stark

Comments

LewisNyman’s picture

Issue summary: View changes
LewisNyman’s picture

LewisNyman’s picture

Status: Active » Needs review
FileSize
4.79 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 64,831 pass(es). View

That was easier than I thought.

LewisNyman’s picture

Once #1921044: Align the styling of tool tips to be more consistent with Seven is committed, we should definitely try and bring the two closer together.

philipz’s picture

This looks good but the tooltip is always to the right of the parent element isn't it? Maybe there could be also a modifier class when it should be to the left like it needs to be in #2170947: Visual cleanup of Edit shortcuts link - comment #13.

Or we could add that when/if it really will be needed later :)

LewisNyman’s picture

Yeah I was thinking the same thing. We should probably add a little arrow similar to the tooltips in #1921044: Align the styling of tool tips to be more consistent with Seven

philipz’s picture

Absolutely! :) I was thinking the tool tips in joyride are looking nice with the arrow, little less opaque and with smaller radius (it looks smaller).

LewisNyman’s picture

Yeah, I think they should be able to share the same classes as long as we can wrangle the joyride templates enough. We will need a variant to change the radius but I can't decide if we should have a tooltip--small or tooltip--large variant.

LewisNyman’s picture

Issue tags: +JavaScript

The more I think about this, the more I think we should be using the title attribute and Javascript to create and style these tooltips. It would be good to get an opinion from a Javascript maintainer.

I know jQuery UI provides this functionality, bootstrap also provides a really nice attribute only API for this http://getbootstrap.com/javascript/#tooltips

LewisNyman’s picture

Issue summary: View changes

There are loads of ways of adding this tooltip functionality with just CSS. Should we do that instead? What are the browser requirements?

LewisNyman’s picture

Component: Seven theme » CSS
Issue tags: -JavaScript

I am 100% convinced we should do this is pure CSS. If we're going to use a library to do this (why not?) then we might as well add this to every theme. I'm going to work on a patch to add hint.css

LewisNyman’s picture

FileSize
9.61 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,480 pass(es), 11 fail(s), and 4 exception(s). View

This needs theming to match Seven's tooltips but so cool :)

Status: Needs review » Needs work

The last submitted patch, 12: 2207383-tooltip-component-12.patch, failed testing.

LewisNyman’s picture

Status: Needs work » Needs review
Issue tags: +frontend
FileSize
3.29 KB
12.28 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,486 pass(es), 11 fail(s), and 4 exception(s). View

Added Seven CSS and attempted to fix failing tests

Status: Needs review » Needs work

The last submitted patch, 14: 2207383-tooltip-component-14.patch, failed testing.

LewisNyman’s picture

I've opened an issue with hint.css to separate out the styling so it's not so overbearing https://github.com/chinchang/hint.css/issues/80

sqndr’s picture

LewisNyman’s picture

Yep :) let's try and push forward on this

sqndr’s picture

Assigned: Unassigned » sqndr

I'll give this a go.

Update 1:
- I've applied the patch from Lewis. The tooltips look good, but the <em> tags are displayed as code. I'm looking for a solution for this at the moment.
- Screenshot of the issue be found here.

@LewisNyman: It's a bit off topic, but is there a style guide for these elements? Should I add some documentation on how developers/themers can use this new design element? Where can this documentation be found? ;-)

Update 2:
Small coding remarks:

+++ b/core/modules/shortcut/shortcut.module
@@ -393,14 +393,18 @@ function shortcut_preprocess_page(&$variables) {
+          'attributes' => array ('class' => array('hint--right'), 'data-hint' => $link_text, 'title' => $link_text)

- array () should be array() - so with no space.
- there should be a , at the end of the line.

sqndr’s picture

Issue summary: View changes
FileSize
12.34 KB
1.09 KB

Here's a new patch with the small remarks from comment #19. Still needs work, since the <em>'s are an issue. I've updated the issue summary.

sqndr’s picture

Assigned: sqndr » Unassigned
sqndr’s picture

Status: Needs work » Needs review
FileSize
1.22 KB
13.44 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,828 pass(es), 11 fail(s), and 4 exception(s). View
12.39 KB

OK. I've solved the issue with the <em>. I've changed the %shortcut_set into @shortcut_set .

Hint CSS in action!

sqndr’s picture

Issue summary: View changes

Status: Needs review » Needs work

The last submitted patch, 22: 2207383-tooltip-component-22.patch, failed testing.

sqndr’s picture

Issue summary: View changes

Change the Issue summary. Since we've made some changes to the html, the tests for the shortcut module are failing. These tests need some work.

LewisNyman’s picture

@LewisNyman: It's a bit off topic, but is there a style guide for these elements? Should I add some documentation on how developers/themers can use this new design element? Where can this documentation be found? ;-)

We do not have a good process for documenting the style guide yet, see #2102191: Discuss the availiable solutions to document the Seven style guide

I'm happy to start pushing along with that.

LewisNyman’s picture

Status: Needs work » Needs review
Issue tags: +accessibility
FileSize
969 bytes
13.46 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,727 pass(es). View

Ok, looks like we have to keep some text inside the link. That makes sense for screen readers anyway.

sqndr’s picture

+++ b/core/core.libraries.yml
@@ -281,6 +281,13 @@ html5shiv:
+      assets/vendor/hint.css/hint.css: { }

I don't think there should be a space?
{ } -> {}

The rest of the patch looks good.

sqndr’s picture

Status: Needs review » Needs work
Issue tags: +css-novice, +Novice

To-do: Remove the space from the last patch. Added the novice tag.

er.pushpinderrana’s picture

Status: Needs work » Needs review
FileSize
367 bytes
13.46 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,830 pass(es). View

Removed extra space as mentioned by @sqndr in #28 and #29. Please review the rerolled patch.

sqndr’s picture

Status: Needs review » Reviewed & tested by the community

@er.pushpinderrana - Thanks for change. Marking this as RTBC!

LewisNyman’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
Issue tags: -css-novice, -Novice +Needs change record

I am happy for this to be committed now, as long as we have a follow up to implement hint.base.css when it lands in the master branch: https://github.com/chinchang/hint.css/blob/add-a-base-build/hint.base.css

We haven't really changed the mark up that much, and the new attributes don't affect accessibility, so I don't think this requires a hard accessibility review.

We need a change record because this is an API addition? Let's also give this a quick sanity check in Stark and Bartik.

mgifford’s picture

I just saw this.

There are still accessibility issues with hint.css https://github.com/chinchang/hint.css/issues/81

I'm happy to report that it works well with keyboard users.

The problems with screen readers may be that there's still no best practice that's well supported for tooltips.

I created this issue with hint.css:
https://github.com/chinchang/hint.css/issues/81

Also filed issues with NVDA & ChromeVox.

mgifford’s picture

Was there any consideration of http://jqueryui.com/tooltip/

This too has known accessibility issues:
https://www.ssbbartgroup.com/blog/2013/07/03/jquery-ui-accessibility-ana...

But I'm not clear what version it was tested against.

@falcon03 suggested that actually a year ago https://www.drupal.org/node/1919940#comment-7234280

Notes too from Twitter with @scott_gonzalez:
https://twitter.com/scott_gonzalez/status/484402080677777408
https://github.com/jquery/jquery-ui/commit/b9e438d07c370ac2d4b198048feb6...

This is probably the better way to proceed.

mgifford’s picture

Well, the jQuery Tooltips are certainly available:
core/assets/vendor/jquery.ui/ui/jquery.ui.tooltip.js

Seems pretty powerful http://www.tutorialspoint.com/jqueryui/jqueryui_tooltip.htm

I'm just not sure how to use it.

nod_’s picture

FileSize
13.71 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 72,939 pass(es). View
2.21 KB

I'll be less categorical than sun is in #1919940-6: Build API to Replace Links using Title Attributes with Proper Accessible, Themable Tooltips, by saying that any solution that requires jQuery is a no-go. It'd mean we're back to jQuery (and some jQueryUI) being loaded on all pages.

I agree with him that it's not the place of Drupal to take care of this but if we can do something for a11y, why not.

That said, rerolled patch to use libraries properly.

LewisNyman’s picture

As a frontend dev, I would much rather use lightweight CSS plugin than a jquery plugin, jquery UI has always had terrible mark up and really annoying CSS to override. It looks like the author of hint.css recommends aria-label which looks like an accessible solution. If we add that to the implementation here, with a recommendation in documentation, is that enough?

sun’s picture

FileSize
70.06 KB
68.15 KB

Fanciness may be an argument, but Accessibility is not a good argument to bring up for Hint.css, because its tooltips may appear outside of the visible viewport and are thus not accessible.

Hint.css:

Hint.css tooltips exceed visible viewport; text not readable.

Native UA tooltips:

Native Title UA tooltips can appear outside of the browser window to be readable.

For the UA demo, a title="" attribute was added to the download button on http://kushagragour.in/lab/hint/

UA tooltips can be displayed outside of the browser window, and they are automatically repositioned in case the tooltip does not fit on the screen.

Since purely CSS-positioned (ahead of rendering time), Hint.css tooltips are hard cut-off on the visible browser window viewport. The tooltip text does not soft-wrap even in situations in which the whole tooltip could fit on screen.

This applies to all possible tooltip directions, whereas the bottom and top directions are most problematic, since those may simply be rendered off-screen. In the right and bottom directions, a tooltip causes browser scrollbars to appear on hover on smaller screens.

Lastly, unless I'm missing something, the data-hint attribute is unknown to screen-readers, so any contained help text won't be announced. I assume the source attribute would have to be changed to consume one of the ARIA description attributes instead.

Bottom line: Hint.css looks like a great effort and library. I like the idea. But without some minimal JavaScript for positioning & text-wrapping (& scaling), I don't see how it can reliably work for tooltips in today's world of vastly different screen sizes. In its current form, it clearly introduces accessibility problems (even for users not having a visual disability).

LewisNyman’s picture

@sun Can we not just position them on the other side for these situations? eg. hint--left?

sun’s picture

The attempt to control layout/positioning in HTML (via classes) is conceptually flawed. Normally, layout/positioning exclusively belongs into CSS. However, CSS still lacks conditional screen/box selector constraints at the element level that would allow to prevent tooltips from appearing cut-off/incomplete or off-screen/invisible. At this point, the necessary level of positioning control can only be achieved through JS in a reliable way.

Due to that, we should move forward with a CSS + JS based solution.

I'm not sure why a potential dependency on jQuery presents any kind of problem? Tooltips normally appear on more complex user interfaces only (e.g., forms) and those pages have a very high probability of requiring jQuery either way already.

(That's not to be meant as an endorsement for the jQuery Tooltip library [there are popular alternatives], but only meant to say that I can't get behind the resistance to a JS based library.)

nod_’s picture

jQuery based library is my issue. But I guess one could just do away with the library and use the default browser tooltips.

LewisNyman’s picture

We could add this implementation just to Seven? Then it wouldn't affect frontend pages, most admin pages load jQuery anyway I assume.

There is a use case to add tooltips to some of the toolbar icons though, but the toolbar loads jQuery anyway so that isn't a problem.

LewisNyman’s picture

Issue summary: View changes
LewisNyman’s picture

Ok, it's a shame we can't do this is in pure CSS but I think using a jQuery plugin isn't going to upset anyone if this is going to be used on pages that load jQuery anyway, right @nod_?

I've updated the remaining tasks with this in mind.

nod_’s picture

I'm ok with implementing that with jQuery if it's Seven only.

droplet’s picture

Sites owner always expected more than just showing the hints, Pure CSS libs never able to fulfill their needs.

anyway, #1890266: dropbutton text fails to retain .dropbutton-widget width has same issue mentioned in Comment #38. (sometimes a hint could be a dropdown menu, just see how do you styling it.)

LewisNyman’s picture

FileSize
4.14 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 74,978 pass(es), 11 fail(s), and 0 exception(s). View

Ok, here's a go at implementing jquery.ui.tooltip with the Seven styling.

It kinds of shows how much we use the title attribute all over the UI that aren't always obvious. We should probably have a data attribute to opt in to this styling. I kind of wish we were using a plugin with a more modern API.

Status: Needs review » Needs work

The last submitted patch, 47: tooltip-component-2207383-47.patch, failed testing.

LewisNyman’s picture

Status: Needs work » Needs review
FileSize
4.95 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 75,138 pass(es), 11 fail(s), and 0 exception(s). View

I forgot to add the new files

Status: Needs review » Needs work

The last submitted patch, 49: tooltip-component-2207383-49.patch, failed testing.

nod_’s picture

Less code than expected, nice.

From what I tested, jquery handles the offscreen situation nicely but there are a few styling issues.

Background should be opaque, not transparent. It's not legible when there is text under the tooltip (which is very often). Position of the tooltip isn't helping much, either top or bottom is more helpful.

with $(document).tooltip(); and a black background the tooltips looks good enough.

LewisNyman’s picture

I would really like for it to be easy to change the position of the tooltip on a case per case basis, what works for some does not work great for others.

Also, the idea of using the tooltip for any element that has a 'title' attribute feels really flawed, we use the title attribute in lots of situations to provide context to screen reader users only, and the sometimes unnecessary information can be distracting for visual users. eg. The toolbar menu items. I'm guessing this is one of the reasons the tooltip for title attributes has effectively been removed from modern browsers.

Ideally we could do this without JS, similar to how hint.css uses variant classes. I'm tempted to explore another JS solution which has a more modern API :\

bobrov1989’s picture

May be we can use something like this http://cssdeck.com/labs/hint-css-tooltip
We should take tooltip text from some data attribute, for exmple data-tooltip.

LewisNyman’s picture

@bobrov1989 If you read through the initial comments that idea what shot down because it's impossible to adjust the position based on viewport width/height. I would still prefer that over nothing...

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Needs work » Postponed

Would love to have it, but....

joelpittet’s picture

Status: Postponed » Active

Open for business

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

emma.maria’s picture

Issue tags: +Needs design, +Usability

Added tags + updated to 8.2.x.

Note: Discussion for a solution is very much needed before any patches appear for this issue.

yoroy’s picture

Design solutions should probably also take the design of the Tour module call-outs into account.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mgifford’s picture