-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hide tooltip of origin is fully hidden on scroll #631
Comments
Hello, the idea is that, if the upper half of the origin is hidden by an overflow for example, the tooltip will look weird if it's positioned at |
I will not add an option for that as it's a bit of an edge case, and I can see that there could be other behaviors that you might want when scrolling. So the current behavior is not universally good but should satisfy most. It will stay that way but you can always listen to scroll events to apply your own tweaks. The following does play a little with internal values (the ones that start with a double underscore), you could refine the code to avoid that, but a solution for what you ask for would be like: $.tooltipster.on('scroll', function(e){
var event = e.event,
geo = e.geo,
$origin = $(e.instance),
$tooltip = $(e.tooltip),
$originParents = $origin.parents();
if (event.target !== window.document) {
var overflows = false;
// a fixed position origin is not affected by the overflow hiding
// of a parent
if ($origin.css('position') != 'fixed') {
$originParents.each(function(i, el) {
var $el = $(el),
overflowX = $el.css('overflow-x'),
overflowY = $el.css('overflow-y');
if (overflowX != 'visible' || overflowY != 'visible') {
var bcr = el.getBoundingClientRect();
if (overflowX != 'visible') {
// THIS IS WHAT YOU WANT TO TWEAK
if ( geo.origin.windowOffset.left < bcr.left
|| geo.origin.windowOffset.right > bcr.right
) {
overflows = true;
return false;
}
}
if (overflowY != 'visible') {
// THIS IS WHAT YOU WANT TO TWEAK
if ( geo.origin.windowOffset.top < bcr.top
|| geo.origin.windowOffset.bottom > bcr.bottom
) {
overflows = true;
return false;
}
}
}
// no need to go further if fixed, for the same reason as above
if ($el.css('position') == 'fixed') {
return false;
}
});
}
if (!overflows) {
$tooltip.css('visibility', 'visible');
// reposition
if (e.instance.options('repositionOnScroll')) {
e.instance.reposition(event);
}
// or just adjust offset
else {
// we have to use offset and not windowOffset because this way,
// only the scroll distance of the scrollable areas are taken into
// account (the scrolltop value of the main window must be
// ignored since the tooltip already moves with it)
var offsetLeft = geo.origin.offset.left - e.instance.__Geometry.origin.offset.left,
offsetTop = geo.origin.offset.top - e.instance.__Geometry.origin.offset.top;
// add the offset to the position initially computed by the display plugin
$tooltip.css({
left: e.instance.__lastPosition.coord.left + offsetLeft,
top: e.instance.__lastPosition.coord.top + offsetTop
});
}
}
}
}); |
Sounds reasonable to me. We made some tweaks for our cases including this one, and I guess they are too specific. Thank you anyway. |
You're welcome, thanks. |
Comment from sources :
This doesn't work well in my case. I'd prefer to hide tooltip only if origin is fully hidden.
If I understood sources correctly, this behavior could be easily changed in
__scrollHandler
by tweaking the wayoverflows
is computed (and small change actually fixed my case).I suggest adding an option for this. I could make pull request if needed when I'll have time.
The text was updated successfully, but these errors were encountered: