Show HN: Hint.css v2.0 – Pure CSS tooltip library | Hacker News Reader

Show HN: Hint.css v2.0 – Pure CSS tooltip library

kushagragour.in

253 pointschinchang63 comments

For those wondering, the main trick is here: https://github.com/chinchang/hint.css/blob/master/hint.css#L...

This creates a pseudo ":after" element with content set to the value of the data-hint attribute. Smart!

https://developer.mozilla.org/en-US/docs/Web/CSS/attr

That's amazingly useful. I'd never seen that before. It says that support other than with 'content' is experimental. Where else does it work? Does anyone have any other useful / novel use cases they could share?

I believe it's pretty solid: http://caniuse.com/#search=CSS%20Generated%20content%20for%2...

Also checkout the pseudo counter: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Lists_a...

Very clever. I didn't know you could reference attributes in css.

I haven't verified this, but I really doubt that this, or any other CSS-only solution, will work with elements constrained in an `overflow: hidden` block with a fixed height too short to display the tooltip. Which is a fairly common scenario when building app UIs. Most of the work done by Javascript tooltip libraries is figuring out the correct position relative to the <body> tag and appending the tooltip element outside of normal flow constraints.

Also, a good JS solution will dynamically reposition the tooltip if the requested orientation results in the tooltip being clipped by the viewport (eg. switch from right to left, top to bottom).

How accessible is this approach to screen reader users and people who rely on keyboard interaction alone?

Edit: A quick test reveals these tooltips are not accessible at all.

Not with keyboard interaction: they’d have to add :focus rules and tabindexes to the parent.

Screen readers sometimes read out generated content. Léonie has more info: http://tink.uk/accessibility-support-for-css-generated-conte...

Unfortunately that's a major deal breaker for using this for any professional project. Making things accessible isn't really that hard, and it makes the lives of people who need it much easier. It's a shame it's not more common place.

Yup. Use of the title attribute would be better, but I don't think there's a way to turn off the default behaviour, unfortunately.

Isn't there a tag for links similar to the description tag for images? If so, you could just enter the tooltip there as well.

No. Well, you could use aria-describedby but that has to refer to a separate element. There’s no generic aria-description.

You could use aria-label potentially, but it has fairly scrict semantic connotations as a label for an input, I believe.

aria-label is totally cool for not-input's: https://www.w3.org/WAI/GL/wiki/Using_aria-label_to_provide_l...

Yeah, that should bring in some accessibility. Right now the library uses `data-hint` attribute. We could use `aria-label` attribute instead!

Keyboard accessibility should arrive soon: https://github.com/chinchang/hint.css/pull/111

To address the screen-reader concerns: As a proof of concept I was able to swap out `data-hint` for `aria-label` without issue: https://github.com/jdan/hint.css/commit/e6541166ec055c525485...

`aria-label` is essentially used twice here - both to populate the tooltip's contents, and to provide an accessibility label to the element that can be read off by a screen-reader.

I proposed these changes to the maintainers under an existing a11y issue (yay to people thinking about it!), but pointed out that if folks are using this library to supplement the contents of an element with a tooltip instead of labeling it, then the a11y changes are not ideal because a screen-reader will omit the element's contents in favor of whatever is inside the tooltip. My gut tells me that this library is mainly used to annotate things like icons.

As soon as I see "pure CSS" or "CSS only" this is the first thing I think of. This meme that "pure CSS" is a Good Thing is a shame.

On one of the very first tooltips at the very top of the landing page (the download button), my Chrome v48.0.2564.97 browser renders a very thin gap between the triangle of the tooltip and the content rectangle. Not a great first impression...Is anyone else seeing this? I suspect it has something to do with pixel percentages.

yes, but only when i zoom in/out

No such on gap my Chrome, it works great. (v48.0.2564.97, Mac OS X 10.11.3)

It's not really a bug. Just that the rectangle border overlays the triangle.

Ditto. I was also zoomed at 150%, zooming in to 100% makes it go away.

Still worth fixing if possible, since many users browse at non-100% zoom.

> "many users browse at non-100% zoom"

This sounds dubious. Do you have a source for this?

Personally I rarely browse at 100% zoom. I magnify each page until I only have ~20px of margin and no whitespace.

Given there are tens of millions of people on the Internet, even if a small amount like 0,01% did it, it would already be "many people".

I would however appreciate some analytics data on it to have a better idea.

100% zoom is only usable on relatively large monitors with Full HD resolution or worse.

For anything with a higher DPI (including UHD/4k, but also lower resolutions), zoom is required to be able to read the text on most pages.

I run with 125% zoom on the 5+ year old iMac I use at work, and it makes a big difference.

If you'd like to see what size the fonts are with 100% zoom on a UHD monitor, try setting the zoom to 50%. You'll see.

Zooming should be as common a sanity check for web pages as viewing on a tablet or a 320px wide mobile phone should be, IMO.

> Do you have a source for this?

I don't. However it seems odd to think people wouldn't zoom in a document viewer.

Let's get some real numbers though: I just asked Addy Osmani on Twitter if there are stats for this, since window.devicePixelRatio changes with zoom.

Do 90% of web users know that this is a document viewer?

Yes. Most people on the internet have heard words like 'web page' before. Hopefully zooming awareness should on the same order of magnitude as scrolling awareness, although it's probably less since scrolling was implemented first.

I've run into some issues with webpages I've designed where the users are browsing at 150%-250% regularly. I'm not quite sure what to do about it. It's different than when a tablet zooms, which is literally just zooming in... browsers make things bigger (text, images, etc) and it screws with things.

The solution is called "responsive design." From your perspective, my zoomed browser just has different proportions. If your site renders well on a phone due to responsive CSS, then it should be okay in a zoomed browser too.

(I'm browsing Hacker News at 200% right now. It works great since their latest responsive fix.)

Do you have a source to support many users browse at 100% zoom?

Based on discoverability of zoom and the effort cost of adjusting the zoom of every site, I'd bet a lot of money on the vast majority of users in the world browse at 100% zoom over all others setting solely on the basis that it's the default setting (or 'laziest setting') and not easily discoverable.

It is a gap only if you zoom in, at 100% it appears as a grey line: http://i.imgur.com/6uCb0km.png

Chrome 48, Win 7

I thought the small gap that appears at 125% zoom was quite nice looking, actually!

(After some messing around, it only appears at multiples of 75% zoom for me. I am using chrome 'Version 48.0.2564.97 m' on Windows with a 1080p screen.)

What is going on when the tooltip first shows as blurry, then becomes clear? The most obvious example is hovering over the download button. Does CSS scale transform always behave this way?

In the 'download' button case, the download button is itself scaling up which makes the tooltip inside it scale up too. Thats the reason of blur (which comes with scaling elements)

I am seeing blurry text on every tooltip as it animates in, not just the one on the download button. I assume it is related to ClearType rendering the text on non-pixel locations.

Chrome 47, Windows 8, ClearType enabled.

> Small file size. Only 1.5KB minified and gzipped!

Well I guess everything is relative...

In the age of multi-megabyte webpages [1], 1.5KB is definitely small.

[1] http://idlewords.com/talks/website_obesity.htm

It's not like you have to cut off cm of your body for every KB your website is using...

Compared to previous (JS-heavy solutions), yes.

Here's an alternative I wrote a long time ago: https://github.com/bevacqua/hint

- Stylus or plain CSS

- Comes with a bit of JavaScript

  - Auto-docks to browser window edges

  - Multi-line if hint is too long

  - Transitions

Good work!

> "Works in all modern browsers."

It'd be really helpful if you listed which browsers it's been tested to work in.

I think it is IE9+, as I understand from here: http://caniuse.com/#feat=css-gencontent

IE8+ as they’re using the CSS2.1 single-colon pseudoelement syntax rather than CSS3’s double-colon syntax.

They do on Github[1]

"hint.css works on all latest browsers, though the transition effect is supported only on IE10+, Chrome 26+ and FF4+ at present.

   * Chrome - basic + transition effects
   * Firefox - basic + transition effects
   * Opera - basic
   * Safari - basic
   * IE 10+ - basic + transition effects
   * IE 8 & 9 - basic"

[1] https://github.com/chinchang/hint.css#browser-support

An interesting hack in minimalism. They accomplish being able to display user defined text in tooltips without JS by using content(data-attrib) in the CSS rule. I was not away that the content() rule allowed you to query other attributes on any matched tags and use them like variables

If anyone would like to try a live preview on their site, I wrapped hint.css in a quick Eager app: http://bit.ly/202YkC5

So coool! Thanks.

Is there any demo of adding hint to <a href....>..</a>? In desktop browser, I can see the hover events can trigger the hints.

How to make it work on touch browser? Touch should trigger the <a href>, but I also like to see hints shows up somehow.

The tooltip should change position if it's rendered outside the visible area!

Tooltips that flicker as you move mouse on the page feel really cheap. If you look at native tooltips, there is delay that waits for your mouse to "settle" to show the tooltip so that it doesn't flicker.

Hint.css also has a delay before showing/hiding. It can be tweaked as per requirement.

There's also a fork that allows HTML content:

https://github.com/istarkov/html-hint

Beautiful and works great! But I prefer to use stadard (alt,title) HTML tooltip :)

hint--bounce doesn't seem to work properly on Firefox 43.0.4 for OS X (El Capitan).

Don't we already have a title (or alt) attribute for <a>, <img>, <abbr> and other HTML elements?

The title attribute does provide a mouseover tooltip, but for users who are not using a mouse (e.g. they are browsing the web on their phone), there is often no reasonable way to access the title text. For example, as far as I'm aware, iOS Safari will only show title text for images. I see this as primarily an issue with the browser, but until Apple and others implement such functionality into their browsers, it's up to the web developer to ensure those users are able to access the title text.

uh. On mobile the grid is flipped?

"Made with hands by Kushagra Gour in India" - I like this guy, compared to all those "Made with Love" fuck you!

I wonder why all those demo-sites include JavaScript. Doesn't this contradict their purpose of demonstrating a pure-CSS library?

Using Google Analytics to measure traffic does not contradict the purpose of demonstrating their tooltip library.

Reply on news.ycombinator.com