1

I'm trying to use tipsy

... to add tooltips to a page. So I have prepared the simple HTML example posted below - tipsy seems to run, but unfortunately, when I mouseover the element, the entire document body gets pushed down, which is visually very irritating (and in addition, can cause the element under focus to move and lose the mouseover); this can be seen on the below gif, captured on Ubuntu 14.04, Firefox 43:

tipsy-ffox.gif

How can I prevent this "pushing" of the whole document down, when doing a mouseover on a tipsy element?

The test code:

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <meta http-equiv="pragma" content="no-cache"/>
  <meta http-equiv="x-ua-compatible" content="IE=edge"/>
  <script type="text/javascript" src="../jquery-1.12.3.min.js"></script>
  <script type="text/javascript" src="../jquery.tipsy.js"></script>
  <link rel="stylesheet" type="text/css" href="../tipsy.css"/>
  <style type="text/css">
#_help_refresh {
  display:none;
}
  </style>
  <script type="text/javascript">
ondocready = function() {
  // placeholder - nothing for now...
  $("#_refresh").tipsy({fade: true, gravity: 's', html: true, title: function() {
      return $("#_help_refresh").html();
    }
  });
}
$(document).ready(ondocready);
  </script>
</head>

<body>
  <h1>Testing tipsy ...</h1>

  <div id="testholder">
    <div>Some text here:</div>
    <div>Some more text here:</div>
  </div>

  <span><img id="_refresh" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABIAAAASCAYAAABWzo5XAAAABHNCSVQICAgIfAhkiAAAAQxJREFUOI2l1DtOA0EMBuBPiGMgUBo4AQWioEAkCCpuACUSuQLcgYI+4QJ0NAREkWOkiBBCPBraFLsU6w3L7uZFfsmSx2P/Y8/YQz1a6GKAUcggbAc1/pdlwxb6SGfIEzYi5gpJkWQP3+GYoIc2miFtPMdeinfcFNbjTHKSYZBOwhE+arKkUM4Qa1NIclzXEbUK5UzLJEd+JxWibii9JUjSVeyG090MkjOcysqvxShYm3NkNBErywSXiV5C31yWqB/6yT/iO7IuP2fx589xHDEJdnLjog3ZwFvE3Bc3FhmRfbyG7yfWyw7loX3Ahb9D++i3Ib+wPem0eb6RRHbBjSlZj3GIW9WPrROlVfADiJ5vX7sneXIAAAAASUVORK5CYII="/></span>

  <span id="_help_refresh">Here is the help test that goes in the tooltip</span>
</body>
sdbbs
  • 4,270
  • 5
  • 32
  • 87
  • 1
    I'm guessing it's the `#_help_refresh` taking up space from being hidden to shown. Try giving it `visibility:hidden` instead of `display:none` – Gavin Thomas May 04 '16 at 13:16
  • 1
    I'm testing your code on Firefox and it seems to be working fine. – Cedric Ipkiss May 04 '16 at 13:17
  • Thanks for the suggestion, @GavinThomas - but that's not it, just tried it: the `#_help_refresh` never gets shown anyways, it is just there as an invisible container for the data for the tooltip (in my actual code, I don't even use hidden elements, I read files via AJAX - I just added that hidden element here to quickly simulate) – sdbbs May 04 '16 at 13:18
  • Thanks @che-azeh - what Firefox version is it and on which OS? My gif above was captured in Firefox too... Do you have addons? I'll try it in Firefox safe mode, see if some addons make a difference... EDIT: tried it in Firefox 43 Safe Mode, same problem; also in Firefox 45 (no addons installed), same problem... – sdbbs May 04 '16 at 13:25

2 Answers2

2

Figured what the problem is, thanks to Firebug and Firebug: How to inspect elements changing with mouse movements?.

Basically, when page loads, <h1> is the first element in the <body>. Firebug shows that the system CSS for <h1> in that case is:

margin-block-end: 0.67em;
margin-block-start: 0.67em;

Note that in this case - when <h1> is first, the margin-block-start is automatically disabled by Firefox; but when some other element is before <h1>, then the margin-block-start is automatically enabled by Firefox.

So, what happens is: at start we have <body><h1>..., then a mouseover happens, and tipsy actually inserts a <div> as a first child of <body>, and thus we have <body><div ... /><h1>...; thus <h1> is not the first child anymore, and so its margin-block-start gets enabled, and so this "push down" of content becomes visible.

The easiest fix - without CSS or JS or anything - is simply to insert an empty <div> (or other element) as a first child of <body>, that is, in front of the <h1>:

...
<body>
  <div></div>
  <h1>Testing tipsy ...</h1>
...

Then, as <h1> is not the first child anymore, it will have margin-block-start enabled from the start, and thus tipsy mouseovers will not change this once their respective divs are inserted.

Community
  • 1
  • 1
sdbbs
  • 4,270
  • 5
  • 32
  • 87
1

The problem isn't with your html. It's with the plugin. I ran the code and noticed that the plugin appends the tooltip to the top of the document. This causes the newly added DOM element to take up some space right at the top, thereby causing every other element below it move a few pixels downward: take a look at this code on line 34 of tipsy.js:

$tip.remove().css({top: 0, left: 0, visibility: 'hidden', display: 'block'}).prependTo(document.body);

So when you replace the prependTo() method on that line with appendTo(),

$tip.remove().css({top: 0, left: 0, visibility: 'hidden', display: 'block'}).appendTo(document.body);

tipsy adds its tooltip at the end of the document, preventing the addition of a new DOM element right at the top of the document. So edit the sourcecode.

Edit

Given you fixed your specific problem, it could help to modify the source code as explained, if you would be calling the plugin in other places of your design. I believe problems could occur in other places of your code where you call the plugin, as the plugin adds new elements way at the top of the DOM tree. Making the plugin add these elements at the end of the document should limit the kind of error you encountered.

Cedric Ipkiss
  • 5,662
  • 2
  • 43
  • 72
  • Thanks @che-azeh, but I don't think the element takes up so much space on top, as it's "position:absolute;" and when I mouseover the inserted div in Firefox inspect element, only the tooltip rectangle itself is selected (so the problem isn't the inserted element taking up space at the top). The problem specifically here is the default behavior of the `

    ` element in Firefox, as I noted in my [answer](http://stackoverflow.com/a/37029799/6197439). However, yours is a valid fix too.

     – sdbbs May 04 '16 at 14:23