Keeping hover state css with fbTooltip

Page: 1

Author Post
Member
Registered: Apr 2013
Posts: 6
I was wondering if there was a 'simple' way to keep css hover classes active when hovering over fbTooltip content.

EXAMPLE CASE
As an example case, imagine 5 icons inside of divs with other elements and text. When the icon/divs are hovered they:

a: trigger a group of css sophisticated hover classes for multiple elements (gradients, transitions, cross-browser conditions, etc.)

b: open a fbTooltip with navigable/intractable content.

PROBLEM
When the mouse is over the fbTooltip the css state of the triggering icon/div is lost because we are now hovering over the fbTooltip.


SOLUTION
While it is possible to employ ideas like jQuery calls via afterBoxStart and afterBoxEnd, the whole process is overly complicated; especially for those of us who are not java savvy and depend on such amazing products as Floatbox to do the grunt-work and heavy lifting. As well it can become quite unruly and obtuse for code maintenance; especially if used over many pages and or with using many fbTooltips in this manner.

Perhaps a future version of Floatbox could provide for a built in 'keep trigger element active' option.

Also, when using fbTooltips in this way in order to use hover triggering instead of a click, clicking on the trigger element causes very erratic floatbox behavior. Therefore it would be great if the fbTooltip opened on either click or hover but closed on mouseOut/mouseLeave.


Lastly, it is quite possibly, the proper and simple solution/methods for handling these issues is in the documentation I overlooked or misunderstood.

Thanks for your time!
Administrator
Registered: Aug 2008
Posts: 3382
I can't think of any way to 'telegraph' mouse hover status from one element to another. We've got event handlers on the host element and it's entirely up to the O/S (aka, the browser) when to fire them. Ditto for :hover pseudo-classes. There's no way I know of to make the css behave as if an element is hovered when it is not. As you suggested, this is job for some custom javascript.

I would be very interested in seeing an example of the 'very erratic floatbox behaviour' that results from a click. Anything that fits that description should be fixable.
Member
Registered: Apr 2013
Posts: 6
The 'telegraphing' was a big wish. But in practical terms, I've been hunting for a java solution that could toggle a hover state on or off as I could then just call that with the BoxStarts. I'm trying to find out if the Firefox Inspector uses a java solution for its toggling of hover/active/focus states as I could just integrate it ...

As to the erratic behavior of a fbTooltip, the effect is most noticeable the longer the content takes to load. However, it can be seen to some degree in your Tooltip demo with the train tracks. Click the tracks while train is showing and it closes. Keep clicking and it will not come back. The situation with the train is that it loads quickly so you would at least know that something was trying to show up.

So the issue is that users won't know that a click or hover should cause an event. When they hover quickly onto such an element that takes a moment or so to load and click, or move the mouse away, then it's quite easy for an important-content-filled fbTooltip to never show.
Administrator
Registered: Aug 2008
Posts: 3382
If you're trying to hook the :hover pseudo-class state, and style via css from that, it's probably the wrong approach and doomed to failure.

Most folks doing this sort of thing put mouseover and mouseout handlers on the element(s) of interest, have those handlers add or remove class names from the element(s) or a parent, and style against those class names.

If this toggling of class names was done by a named function, the same function could be assigned to mouseover and mouseout on floatbox's fbBox element from the afterBoxStart callback.

I can't get the train and tracks tooltip demo to mess up.
Quote
"Click the tracks while train is showing and it closes. Keep clicking and it will not come back."
If opened from mouseover, clicking doesn't close it for me - only a mouseout (or esc key) closes it. If opened from a touch gesture on the tracks, it will close with another touch on the tracks, and then open again with a third touch. All is proper and intended behaviour.

Maybe worth mentioning...
fbTooltips have delay and mouseSpeed options which default to 80 msecs and 120 px/sec respectively. The primary pupose of these is to prevent irritating flashes of tooltip content as the user transits across an element on the way to clicking something else. You can set delay:0 and mouseSpeed:99999 to get immediate tooltip invocation. (The mouseSpeed option is dropped in the next major release, leaving only delay to control transitory mouseover behaviour.)
Administrator
Registered: Aug 2008
Posts: 3382
Let's revisit this.

1. Clicking the host element when a tooltip is opened by mouseover.

Ah-hah! Works just fine in Chrome (or more accurately, webkit browsers) but closes on click as you reported in IE and Firefox. I'll trace through the events and their handlers to see what these two browsers are doing and will have this behaviour eradicated in the next major release. I don't have any tricks I can offer to make the current version not close the tooltip. And no, I don't know when that new release will come out. There's still a couple of significant features I would like to add and a long list of quirks to subdue.


2. 'Telegraphing' hover state to the host element.

Actually, there is a fairly straightforward way to do this, for certain host elements. Floatbox has an 'attachTo' option which sets the parent element of the displayed floatbox. The original purpose of this option was to keep displayed content sequential for folks using screen readers. The default attachTo location is at the bottom of the body.

Not all element types can accept block elements (such as a floatbox) as children. The current Floatbox version limits attachment points to 'div', 'form', 'li' , 'td' and 'body'. If the requested attachTo element is not one of these, the chain of parent elements will be walked until one is found, and the found one used as the attachment point. The next release will be more liberal and will simply try to attach regardless of element type. If the browser doesn't accept the new block child, the parent will be tried, and on up until the body is sure to accept it.

You're using 'li' elements for your fbTooltip menu, so you're good to go. Put an id on the host 'li' and put "attachTo:id" in your tooltip options. Now a hover over the floatbox is a hover over the host element, because the floatbox is a child of the host element.

Note that you may have to fiddle with the styles of the floatbox content to override some inheritable styles which can now come from the host. For example, line spacing may differ when inherited from a 'li' host instead of from the body.

Using attachTo in the right context can allow you to throw away the javascript and classNames assigned via afterBoxStart.
Member
Registered: Apr 2013
Posts: 6
Point #1 (clicking) is not the end of the world, but if it can be dealt with would be great. Mostly I'm glad to know I wasn't experiencing a Twilight Zone episode.

If point #2 is true with regards to 'attach' you've made my #1 wish for a 'telegraph' come true. Wow! Bless you my man! I will say again though that in a worst case situation, my 'solution' is 'seemingly' useable and manageable.

Page: 1