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. 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.)
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.
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.)
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
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?
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.
`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.
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.
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.
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.
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).
63 comments
[ 2.7 ms ] story [ 115 ms ] threadStill worth fixing if possible, since many users browse at non-100% zoom.
This sounds dubious. Do you have a source for this?
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.
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.
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.
(I'm browsing Hacker News at 200% right now. It works great since their latest responsive fix.)
Chrome 48, Win 7
(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.)
> "Works in all modern browsers."
It'd be really helpful if you listed which browsers it's been tested to work in.
"hint.css works on all latest browsers, though the transition effect is supported only on IE10+, Chrome 26+ and FF4+ at present.
[1] https://github.com/chinchang/hint.css#browser-supportThis 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
Also checkout the pseudo counter: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Lists_a...
Edit: A quick test reveals these tooltips are not accessible at all.
Screen readers sometimes read out generated content. Léonie has more info: http://tink.uk/accessibility-support-for-css-generated-conte...
`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.
Chrome 47, Windows 8, ClearType enabled.
Well I guess everything is relative...
[1] http://idlewords.com/talks/website_obesity.htm
- Stylus or plain CSS
- Comes with a bit of JavaScript
How to make it work on touch browser? Touch should trigger the <a href>, but I also like to see hints shows up somehow.
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).
https://github.com/istarkov/html-hint