Skip to content

Inconsistent positioning when whitespace is allowed to wrap & min/max width used #16

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

Closed
mdarens opened this issue Aug 21, 2012 · 5 comments
Assignees
Labels
Bug Software defects or other problems that should be fixed.
Milestone

Comments

@mdarens
Copy link
Contributor

mdarens commented Aug 21, 2012

Thanks for making this plugin!

Here's a jsfiddle: http://jsfiddle.net/GguQF/ . The issue seems to persist if the width is set on an element inside the powerTip div as well e.g. http://jsfiddle.net/GguQF/1/ . Sometimes it appears where it should, but on subsequent hovers appears in an unexpected location.

@stevenbenner
Copy link
Owner

Thanks for taking the time to makes those examples, they really help.

Right now PowerTip doesn't like flexible width tooltips. The tooltips in your examples are elastic (up to the max-width) and they are in a narrow window, so they are impacting the side of the browser view port when the plugin is setting them up. The browser is trying to be nice an wrap them in the window, changing their dimensions. So the final rendered width (and possibly height) of the tooltip is different then the width PowerTip found when it measured the element.

You can see this effect in action here: http://jsfiddle.net/stevenbenner/4MvH3/

I'll try to come up with a solution for this problem, but this is a tough one to solve.

For the current version (v1.1.0 as of this comment) tooltips must not change size when they collide with the right side of the view port, either by explicitly setting the width of the #powerTip div or by setting white-space to nowrap.

@mdarens
Copy link
Contributor Author

mdarens commented Aug 22, 2012

A workaround would likely involve getting the computed style of dummy elements. My current workaround is to make a few presets based on tip content type/length and call different options on them accordingly, which I should probably be doing anyway.

@stevenbenner
Copy link
Owner

I've got something working, but not finished. If I check the tooltip after the plugin has positioned it, and detect a change in the dimensions of the tooltip then I can simply re-position it. Right now it's working smoothly for regular tooltips, but doesn't work as expected when I turn on smart placement. So there are still some kinks to work out.

With any luck the next patch will support elastic tooltips.

@ghost ghost assigned stevenbenner Aug 22, 2012
stevenbenner added a commit that referenced this issue Aug 23, 2012
stevenbenner added a commit that referenced this issue Aug 23, 2012
@stevenbenner
Copy link
Owner

This should be fixed in commit f6b60c2. This change will go out in the next patch.

In the end I did have to fully place the tooltip and test for changes, but it seems to be working well. Though it does not completely fix your jsFiddle examples because the body is almost all padding, forcing any elastic elements contained in the body to try to shrink down to a very narrow column.

I'm marking this as fixed for now. Please let me know if this isn't working right.

@mdarens
Copy link
Contributor Author

mdarens commented Aug 23, 2012

Awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Software defects or other problems that should be fixed.
Projects
None yet
Development

No branches or pull requests

2 participants