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 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).
`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.
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.
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.
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.)
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.
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.)
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.
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
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.
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.
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