[Solved] position.adjust.screen = true shifting way too far

[kiddailey]

I've got a series of qTips that position themselves over the center of the trigger, completely obscuring the original item (a sort of mini, in-position zoom). The triggers are all floating list elements with a fixed width and height, displayed as block. The qTips are also fixed widths but have minor variations in height. I use position.absolute.screen to tweak the qTip on items that reside on the far left and right of the page to keep them in the window. Here is my position fragment:

JS Code

position: {
	adjust: {
		screen: true
	},
	my: "center",
	at: "center"
},

This works great, aside from what appears to be a bug with the screen adjustment calculation. Specifically, it seems to shift the qTips WAY too far. More precisely, it seems to be shifting 30x+ farther than it needs to.

For example, on the left side of my pages it only needs to move the qTips 5-10 pixels to the right but instead, it shifts the qTip to x:138.5 pixels! The same over-adjustment applies to qTips on the right side of the page and near the bottom of the window. I haven't tested against the top although I suspect it would exhibit the same behavior there.

Here is an illustration of the positioning of my qTip as it appears in Firefox with both the x and y coordinates affected (created by drawing boxes over actual screenshots, so it's pixel accurate). The green box is the trigger, blue represents the qTip when screen adjustment is turned off, and red when it is on. The white dotted line indicates the minimum adjustment that is actually necessary:

In this example, it's adjusting the x-coordinate by 106 pixels and the y-coordinate by 198 pixels more than it needs to. The behavior is the same in Firefox/Windows, Firefox/OS X, Chrome/Windows and Safari/OS X using jQuery v1.4.2 and qTip 2.0.0pre (sorry, I can't seem to figure out which build it actually is, though the comment header says "Date: Wed Aug 25 22:13:40 2010 +0100").

Is there any way to adjust the amount of adjustment so that it's closer to the white dotted box's positioning rather than so far out into the rest of the page?

EDIT: FYI, I just upgraded to the "Date: Wed Nov 3 01:57:34 2010 +0000" build of 2.0.0pre and it exhibits the same behavior.

[Craig]

Hmm this soudns odd... could you possibly setup a bare minimum test page to show this in action? Really want to get screen adjustment nailed before the proper release so this would be a godsend!

[kiddailey]

As I was putting together the sample page I did some experimentation and found that there's definitely some inconsistencies about the adjustment behavior when using center/center positioning without a tip. Particularly if you mess with the border or dimensions of the tooltip, which I am doing. Here are some things I believe are consistently observed:

• Using the default dark style, the x and y axis are sometimes over-adjusted and sometimes not. Behavior appears random.
  
  
• The x-axis over-adjustment seems to happen almost all the time even when using the default dark style.
  
  
• Setting the border width on the wrapper via CSS causes the over-adjustment on the y-axis to always happen
  
  
• If the height of the contents in the tooltip is fixed, or the tooltip height itself is fixed, the y-axis will always be over-adjusted.
  
  
• If the width of the tooltip is fixed via CSS, the x-axis will always be over-adjusted.
  
  
• If only a small portion of the trigger is visible, adjustment does not occur at all.

I've attached a hopefully thorough, ready-made test page that has elements similar to my layout with a nearly identical qTip initialization. There are triggers/tooltips positioned near the top-left and lower-right corners of the pages with plenty of extra scrolling room. The tooltips are of varying lengths and content so you can see the differences. Lastly, I've put in the HTML a couple of overrides to the dark style that is similar to what my site is doing.

This screenshot shows the sample page illustrating the issue. The mouse cursor is currently hovering over the bottom-right trigger box:

Note that I'm only seeing this behavior on center/center/notip style qTips. Other tooltips with the corners on them and not at center/center appear to reposition correctly.

Let me know if you need anything else.

[Craig]

Hmm can you test you the latest commit kiddaily? I've been optimizing the adjustment code a bit so this should fix some of the issues you're experiencing, at least from my tests anyway.

[kiddailey]

Just gave it a run in my sample page from above and am not seeing any noticeable difference. I updated the CSS and the JS... is there something else I should be doing?

Also, I hate to be the bearer of bad news... but I stuck this into my development site and the tooltips that were triggered by floating list elements are now severely broken -- all of the tooltips are shown in the same, fixed spot at the far upper left of the floating list elements block. The ones that aren't on floating elements display correctly (albeit, still with the extra shifting on items near the window edge). Here's an illustration to communicate this a little more clearly:

Edit: On further experimentation, it looks like the tooltips are positioning at the upper left corner of the containing element. I have a page with tooltips (whose triggers are floated) way down on one page in another case and the tooltips appear way back up at the top, left corner of the div they are contained in. I thought they weren't working at all until I scrolled up just a tad and saw the bottom edge of one.

---

Just another note. Not all floating lists are affected. I think it may be only floating lists whose container is not the left-most float. Not sure yet. Trying to nail down the exact cause, but apparently, almost all my qTips are positioned over floating elements

---

I also have a breadcrumb widget on the site and each crumb has a qTip that expands down from it. Its position is correct horizontally, but it's now positioned above the breadcrumb bar. The breadcrumbs are a set of floating unordered list elements as well.

Let me know if you need anything else to figure this out.

[Craig]

Do these problems disappear when you set adjust.container to false?

JS Code

position: {
   adjust: {
      container: false
   }
}

[kiddailey]

After a quick trial, yes, it appears so. Adding adjust.container: false to the 11/09 builds resolves the issue. But just FYI - your latest commits from 11/10 no longer exhibit the problem without the adjust.container tweak.

The over-arching issue of too-much adjustment still exists though.

[kiddailey]

Craig:

I've been testing with the latest build (v2.0.0pre Mon Dec 6 20:09:48 2010 +0000) and thought I'd give you an update.

Seems you have made some improvements on this. Yay! The x-axis adjustment appears to be greatly improved, though it is still sometimes 15-20 pixels or so more than it needs to be.

Can't tell if there's any difference visually on the Y-axis though -- it still appears adjusted about the same as before, or an extra 200pixels too much in most cases.

[Craig]

kiddaily, would you be able to setup a test case over at jsfiddle.net please? Here's one you can fork: http://jsfiddle.net/craga89/fDavN/

[kiddailey]

Done:

http://jsfiddle.net/kiddailey/NF3H3/4/

Edit: Removed the padding from the body just to be clear

[Craig]

Introduced a slight refinement to the reposition method that should fix this. Thanks kiddaily!

[kiddailey]

Woohoo! Almost there. I did a bit of digging and testing and have the last couple of issues (with fixes) below

Issue #1: X and Y are still shifted a bit too much when adjust.x or adjust.y is applied in center/center positioning

In line 1018, you have:

JS Code

adjustX = -2 * posOptions.adjust.x

If you use center/center position and adjust X or Y, this will result in the tooltip being shifted 2 * the X/Y adjustment. With center/center, this should be halved just like you do with the width and height calculations. Line 1018 should be something like:

JS Code

adjustX = my.x === 'center' ? posOptions.adjust.x / 2 : -2 * posOptions.adjust.x,

Likewise, line 1036 should be:

JS Code

adjustY = my.y === 'center' ? posOptions.adjust.y / 2 : -2 * posOptions.adjust.y,

With those changes, I get the same (and correct) results whether adjust.x and/or adjust.y is 0, -10 or 10. Note that it's not negatively signed for the center adjustment and also that I didn't test with all the other position configurations.


Issue #2: Y screen adjustment still sometimes shifts too far

Wow. This one really gave me a hard time. In particular because I didn't use real images in the jsFiddle.net sample I put together for you -- and that made all the difference in figuring it out. After much experimentation, I've discovered that the issue is due to an incorrect atHeight value which is the result of the calculation at line 1035.

In my dev/testing site, I have something like:

JS Code

<li>
	<a>
		<img style="width: 140px, height: 105px;" />
	</a>
	<span class="toolTip" />
</li>

I happen to be using the A as the qTip trigger (ie. "at"). Examining the value of atHeight after the calculation executes, I discovered that qTip thinks my images are 12px tall rather than the expected 105px.

Aha! Obviously, it is returning the font-size/line-height of the parent A element -- despite Firefox and Chrome showing a computed height of 105px for both elements.

I'm not sure if you'll be able to (easily) resolve this issue in code, but thought I'd mention it here in case you can, and in case anyone else stumbles on this thread. A relatively simple, but imperfect, workaround is to change the inline parent to block and add dimensions:

JS Code

<li>
	<a style="display: block; width: 140px, height: 105px;">
		<img style="width: 140px, height: 105px;" />
	</a>
	<span class="toolTip" />
</li>

With the above changes and this adjustment to my markup, I'm finally seeing the screen adjustment working as expected for center/center qTips. I know this has been a bit of a pain. Thanks for all your hard work in getting this perfected.

[Craig]

Hey kiddaily,

The first issue was a good catch! Implemented a similar fix in the latest commit so check it out. The second issue is easily avoided by giving all your images height/width attributes, which is good practice anyway and speeds up page rendering.

Keep the bug fixes coming!

[kiddailey]

You're welcome - but just to be clear, my image *DID* have dimensions. That wasn't the issue.

It was the container A HREF tag that didn't have dimensions but required them (as well as block display obviously) to in order to fix the issue.

[Craig]

I was referring to the width/height attributes, not the CSS. The problem probably wasn't the fact its parent was inline, but that <img /> tags tend to be a bit odd dimension wise before they're partially loaded, even if you have CSS applied to them with set height/width.

[kiddailey]

Ooooooooh! Sorry. I've gotten so out of the habit of using that bad, ugly markup on HTML elements that I completely forgot about it

FWIW, you're right -- it does indeed have the same result. Thanks for the clarification.

[kiddailey]

Sorry to post here again Craigh, but I just updated to the latest build and the Y-axis is back to shifting way too far down when the tooltips are center/center positioned and the trigger is near the top of the window. In fact, it's shifting down even farther than before.

Still seems to be working okay on the bottom, left and right though.

---

FYI - The revision I upgraded from (which worked properly still) was the Tue Dec 7 05:56:17 2010 +0000 build.

[kiddailey]

It appears that this may have something to do with position.adjust.y being set. When I set it to 40 pixel (as in my development site), tips near the window top are pushed down too far. Here's a jsFiddle illustrating the issue:

http://jsfiddle.net/898VN/

Note that the top qTip is shifted down instead of being nudged up the upper-left corner. The other two display fine.

Edit: Setting position.adjust.y to a negative value also causes it to mess up at the top of the container.

[kiddailey]

Just a note that I misspoke when I said the Dec 7th revision was working properly. I reverted to that particular build for some testing and discovered that it will also shift tips at the top of the window down too far when the offsetting is applied.

I must have been looking at a tip that didn't have adjust.y set at the time, sorry. Good news is that it's only the top of the window.

[Craig]

Hmm can you try out the latest commit please kiddaily? Should now be fixed hopefully!

[kiddailey]

Looks like now the top and the bottom are a little off instead of just the top. Left and right still look good though. See the JSFiddle:

http://jsfiddle.net/898VN/

[Craig]

Hmmm kiddaily, what is it that's "off" exactly? I'm currently seeing the top and bottom being adjust properyl by 40 pixels, depending upon which way they were originally adjusted i.e.

The top tooltip was adjusted downwards, so the y value was minussed
The bottom tooltip was adjusted upwards, so the y value as added

This seems logical to me at least... what is it you were expecting?

[kiddailey]

Probably easiest to explain with a picture This image should be self-explanatory, but let me know if not.

The real issue here comes into play when you use position:fixed (which I am) so that the user can interact with the tooltip. In some cases, the over-shift completely breaks the ability to navigate down into the tooltip.

I'm not sure if the X positioning also displays the same behavior for center/center. It seems a little different, but I'm not sure how yet.

Let me know if you think my expectations on how this is supposed to behave is wrong.

[kiddailey]

Just an update that it does appear that the X adjustment on center/center positioning is also behaving this same way. It wasn't obvious to me before because I had only done it in small amounts. (and please forgive my grammar above )

[kiddailey]

Craig:

Sorry to bump this old post, but it looks like you never got a chance to reply to my last question before it got moved off the first page of threads and the issue with viewport over adjusting of center/center tips isn't totally resolved in the latest build.

The Y-adjustment on the tips is still way off when you are near the top/bottom edges of the viewport. The X-adjustment sometimes over-adjusts as well, but it seems to behave better. When adjust:x/y is used, the offsetting becomes more pronounced. This over-offsetting frequently breaks fixed positioning/interaction with the tooltip.

The image in post #23 above illustrates what is current happening and what I think should be the correct
behavior.

My question was if my expected behavior for center/center tips was correct. Thanks for your time.