https://bugzilla.wikimedia.org/show_bug.cgi?id=57144
Web browser: ---
Bug ID: 57144
Summary: Tipsy: suport for user class borks positioning of tip
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: JavaScript
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected]
Classification: Unclassified
Mobile Platform: ---
Created attachment 13815
--> https://bugzilla.wikimedia.org/attachment.cgi?id=13815&action=edit
patch to file jquery.tipsy.js
Tipsy allows adding a user class for specific tips.
one of the uses of this feature is to change the dimensions of the tip: e.g.,
when you want to display more in the tip, sometimes the default max-width (25em
on mw deployments) may not be enough, and you want to use, say, 35em.
so you can open the tip with "className: wideTip" in teh options, and then add
to your css something like
.tipsy.wideTip, .tipsy.wideTip tipsy-inner { max-width: 35em; }
this scheme works, but the problem is that tipsy adds the user class *after* it
calculates the tip's dimensions (so the dimensions are calculated with the
default class), so when you go through these motions, the tip ends up in the
wrong place: it's upper left corner will be in the right place for the
tall-and-thin default tip, but the tip itself becomes shorter-and-wider (if the
gravity is "south", this will cause the tip to float too high above the
element, basically missing the whole point of widening the tip to make it
shorter)
the fix is very simple: add the user class immediately after resetting the tip
class in function show(), instead of after the location calculation.
patch attached.
peace.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l