3

I've been working in this tooltip library since yesterday. I don't know if this problem is for my sleep or what, but I can't figure what's happening.

The subjacent idea about this tooltip library is simple: The user adds in any HTML element the custom data attribute (I mean data-) with the message that he wants to display in the tooltip, and it has to appear. There are some options to add, like the orientation of the tooltip and if the user wants to "cut" the words inside the tooltip.

Here's an example:

<div data-msg="Hi, I'm a tooltip with a text veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeery large" data-orient="right" data-break="yes">Hover me and the tooltip will show!</div>

Everything is fine with bottom, right and left orientations, but when I add the top orientation, the browser adds a species of "border" at the bottom of the tooltip.. I don't know why, but I can't fix it.

Is strange because in the others orientations the problem don't occur.

You can see the problem in the below image (the first tooltip has data-orient="top" and the second tooltip has data-orient="right".

enter image description here

If anyone knows how fix this problem, I'd like to explain me what happens.

Here's the Fiddle.

Thanks, Leo!

EDIT: I'm working with Chrome 28 version and my OS is Windows 7.

leoMestizo
  • 1,469
  • 9
  • 15
  • Webkit. I'm working with Chrome. – leoMestizo Jul 14 '13 at 19:01
  • don't see any border in chrome. Which OS are u using and if any CSS Reset/Normalize is employed? – Jawad Jul 14 '13 at 19:04
  • Windows 7. No, I don't use another CSS stylesheet. All the code involved are in the fiddle. **BUT**, I use Google Fonts. I think that this isn't the problem, because I quit the font and the problem still occur. I'll edit the post with an image of the problem. – leoMestizo Jul 14 '13 at 19:09
  • There seems to be some kind of problem with the Z-order, looks like the drop shadow is rendered on top of the callout. – Ilmo Euro Jul 14 '13 at 19:17
  • @IlmoEuro I just remove the `z-index` property and the problem still occurs =/. But if that were the problem, why occurs only in the top tooltips? – leoMestizo Jul 14 '13 at 19:22
  • 1
    @leo I took a closer look with Magnifier; the drop shadow or Z-index isn't the problem. – Ilmo Euro Jul 14 '13 at 19:26
  • 1
    Seems something's going wrong in the `opacity` transition. Set starting opacity to 1 (or 0.9 for that matter), and there's no border. Set it back to 0, but remove the transitions, and there's also no border. – JimmiTh Jul 14 '13 at 20:07
  • Yes @JimmiTh, that's right, but... Why only in the top tooltips? That's very strange =/ Besides, I don't want to remove neither the `opacity` property and `transition` property. – leoMestizo Jul 14 '13 at 20:11
  • 1
    Yes, that's why I wrote it as a comment, not an answer. :-) It was meant to help finding the cause of the problem, not to solve it. So is this: http://jsfiddle.net/R27Sq/2/ - more minimal example, which hopefully *keeps failing this time* (previous revision seems to be Heisenbuggy). – JimmiTh Jul 14 '13 at 21:42

1 Answers1

2

This is a workaround, not a real solution - but shouldn't have any serious side effects in this case (no guarantees, though, see below). And I have little explanation other than this appears to be a Chrome rendering bug.

Add this to [data-msg]::before:

-webkit-backface-visibility: hidden;

backface-visibility tends to fix quite a few Chrome rendering bugs, regardless of the fact that it actually has to do with 3D transforms - it appears to fix this case too.

The reason that it fixes problems possibly has to do with Chrome using a different (hardware accelerated) transition engine the moment you add anything to do with 3D transforms to your element. This may have performance penalties, which leads us to another non-sensical rule that at least used to improve performance if you run into problems:

-webkit-transform: translate3d(0,0,0);

ETA: -webkit-transform alone actually seems to be enough to fix the problem. Experiment with the two, and see if any of them cause other problems.

There have been reports of -webkit-backface-visibility crashing iOS. So do test it there, and try with translate3d instead - or disable the fix specifically on iOS (and live with the bug if it appears there).

As posted in the comments, here's a more minimal example of the problem - although it sometimes fails to... fail, it should mostly have the unwanted darker border at the bottom:

JSFiddle

The bug seems to be caused by transitions combined with border-radius and opacity. Possibly inline-block and padding have a role in the bug too, but sometimes their removal fixes the border, sometimes it doesn't. I hope the backface-visibility workaround is more consistent.

Community
  • 1
  • 1
JimmiTh
  • 7,389
  • 3
  • 34
  • 50
  • This fix the problem! I don't know how could I pay you for the help. Thank you very much! – leoMestizo Jul 14 '13 at 22:39
  • 2
    No worries - the upvote, as usual, works fine as payment in this place. Also, might be worth looking more into this workaround... As long as we don't know what *exactly* makes it work, who knows when Google is going to fix the workaround without fixing the bug? :-) – JimmiTh Jul 14 '13 at 22:50