It's wouldn't be possible if you're only using CSS. See this stackoverflow post [1], or more specifically the spec it references [2] on the CSS content property (used by this library).
Very clever. FWIW There are some issues when the node is near the edge of the window. The browser will display the contents of a title attribute atop the browser chrome, but your tooltip will be hidden.
For reference: Doesn't work on Internet Explorer 7, always shows the hints on Internet Explorer 8 and works fine on Internet Explorer 9 (Minus the animations.)
The double hyphen is actually part of a pretty common naming convention (BEM-style) for distinguishing between separate components, component modifiers, and component sub-objects.
On the other hand, having to include two classes seems sloppy. Why not just roll the core styles into the position classes, or include a default position in the 'hint' class?
Thanks. I thought of putting the core into the position classes but that seemed to duplicate some styles in the generated CSS. Though having a default position surely seems a nice idea. Will work on it :)
The one downside to any library that uses before/after pseudo elements is that they take over the pseudo elements and can no longer be used for other purposes.
I would say that they should only be used for styling and not functionality.
one caveat, any approach like this (one that just uses css) will hide the tooltip if the thing it is tipping (or one of it's parents) is clipped by overflow:auto/scroll/hidden. the only way to get around that is using javascript (the tooltip needs to be inserted into the dom outside of the element with constrained overflow, eg: as a child of body). I've found that in any decent size project I've done, eventually I run into that scenario, so I usually just start with a JS based approach from the beginning (bootstrap, jqueryUI, etc)
I was going to say the exact same thing, but you beat me too it!
I started with this approach when I built our tooltip library for my company, but eventually there were just too many gotchas. We switched to using JavaScript and inserting the generated element as a child of `body`.
Just thinking aloud here. Could that problem be avoided by putting the tooltip element outside of the thing it is tipping, and then using a CSS selector like ".tipped-element:hover + .tooltip-element"?
I'm sure there are some other caveats that would reveal themselves later even if this one is avoidable...
I really like it, but part of me thinks the better way would be to just use whatever's on the title attribute of an element, which would of course need JavaScript. I guess this would be better for lighter sites.
Edit- I misunderstood how this works, I thought you actually had to add <span>s (extra markup) but it seems not! This is really great!
My only complaint is that it messes with elements if you're doing the :before/after thing for font icons.
Thanks Andrex. The issue with using title attribute is that its hard to suppress the default tooltip that shows up with just CSS. Any idea if it can be done?
It'd be interesting if you could just apply CSS to title attributes rather than have to add stuff to the DOM to reimplement a basic browser feature. Certainly these types of tooltip libraries look and behave better, but I wonder if it's really the best solution.
Well, Tipsy, bootstrap tooltips and similar javascript based tooltips require you to initialize them.
It's fine if you have a mostly static page, so you can initialize all fo them on domready.
But if you are in a very dynamic page with pjax or a Javascript MVC app, you always have to initialize them again on any page change.
It's costly and error prone. This pure CSS solution in the other hand do not require any initialization. You put the HTML with the proper classes and it will just works.
57 comments
[ 5.8 ms ] story [ 70.2 ms ] threadcontent: attr(data-hint);
see: https://developer.mozilla.org/en-US/docs/CSS/attr
The acceptable values are:
You might think, maybe you could insert html by putting the html on an attribute and using the attr() value, but reading further:This function returns as a string the value of attribute X for the subject of the selector. The string is not parsed by the CSS processor.
[1] http://stackoverflow.com/questions/4505093/css-content-prope...
[2] http://www.w3.org/TR/CSS21/generate.html#propdef-content
http://s3.postimage.org/8d3zodcur/Screen_Shot_2013_02_04_at_...
Examples: https://gist.github.com/1309546 http://nicolasgallagher.com/about-html-semantics-front-end-a... http://csswizardry.com/2013/01/mindbemding-getting-your-head... http://engineering.appfolio.com/2012/11/16/css-architecture
On the other hand, having to include two classes seems sloppy. Why not just roll the core styles into the position classes, or include a default position in the 'hint' class?
Double dashes in class names are also annoying.
I would say that they should only be used for styling and not functionality.
I started with this approach when I built our tooltip library for my company, but eventually there were just too many gotchas. We switched to using JavaScript and inserting the generated element as a child of `body`.
I'm sure there are some other caveats that would reveal themselves later even if this one is avoidable...
Edit- I misunderstood how this works, I thought you actually had to add <span>s (extra markup) but it seems not! This is really great!
My only complaint is that it messes with elements if you're doing the :before/after thing for font icons.
http://www.paciellogroup.com/blog/2013/01/using-the-html-tit...
I just took a quick look at it, and it seems like a nice tooltip library.
It's fine if you have a mostly static page, so you can initialize all fo them on domready.
But if you are in a very dynamic page with pjax or a Javascript MVC app, you always have to initialize them again on any page change.
It's costly and error prone. This pure CSS solution in the other hand do not require any initialization. You put the HTML with the proper classes and it will just works.