stevenbenner / jquery-powertip Goto Github PK

This is follow up for #27 ticket

offset = 10px (by default) can be replaced with margin in CSS. That's seems to be better separation between code & representation.

There is a hundreds of tooltips plugins on this planet and only one or two support this.
Its good idea to make possible edit content that will be displayed while ajax request processing.

Btw, thanks for hover intent :)

There doesn't seem to be any way to remove the current tooltip, unbind the event handlers, or conditionally suppress the tooltip being displayed. There are a couple of possible approaches here - one is to offer a "manual" option that doesn't bind any event handlers (this is something the Bootstrap popover offers), leaving that to the developer. I have that in this branch, but it's a pretty blunt instrument as it stands, and can't actually remove the tooltip.

This issue is followup to #27.

Pinning point should be selected, depending on popover location. Then, if content grows, popover will change in proper direction without additional position recalulation.

1. Use-case for corners:

We load content in 2 stages:

• show dummy popup with "loading" progress
• substitute content

If popup grows on second step, then it overlap link (now). So, now we have to call recacculation, to move it up. But if you pin popup with bottom left corner, then it will automatically extend in proper direction (up and right).

IMHO, in practice, it would be very convenient to select "proper" pinned corner for each gravity option. Then it will change inproper direction without additional JS call.

2. Comments about side-placed (left-right-top-bottom) popups:

For side-placed tooltip there are no unique pinning solution. But it's limited to 2 possible choices, instead of 4. I don't have strong opinion, how to choose the best corner of 2.

IMHO, rigth now you can select any of 2, and if someone will have the real case in practice, then you could improve it. IMHO, if someone have top or bottom placed popup, he will fix width. Then content change will only affect height - no problem.

Currently developers have to download the entire PowerTip package and run it in a suitable test environment if they want to evaluate the plugin. It would be nice to have an official demo in jsFiddle so developers could fiddle with the plugin and evaluate it without having to download an run it.

Rules:

• jsFiddle demo should use the current release
• jsFiddle demo should be linked from the project page and readme in the repo
• jsFiddle demo should be updated whenever there is a release

Currently PowerTip exists in it's own isolated little closure with no way for developers to know when it does something. It would be nice if developers could attach code via jQuery events.

Suggested events

• Tooltip open
• Tooltip close

I am trying to use Powertip's on elements inside iFrames and they are positioned incorrectly because they don't take into account the position of the iFrame(s). Any help in resolving this is much appreciated.

-Neville

I have a Select element as content in a PowerTip, and if I change the value of the Select, that value isn't "remembered" the next time the PowerTip is opened. See this for an example of what I'm talking about: http://jsfiddle.net/uE2dZ/

Timers in browsers are best effort and cannot be relied on for millisecond accuracy. Right now the tests compensate for this behavior by adding or subtracting arbitrary numbers to the timer duration to account for the expected deviation. However this method is not only hacky, but prone to unexpected failures when running tests in real browsers.

Many of the tests that are currently using timers can be refactored to use PowerTip events or other callbacks to determine if the desired action took place. This would be preferable in almost all cases because the test results will be far more reliable.

The only problem that I can see happening because of this is that when asynchronous tests using callbacks fail to reach the start() invocation the tests will hang until they timeout instead of simply noting a failed assertion. Personally, I see this as an acceptable waste of time because even if it does take longer for a test to fail in this scenario at least you don't have to worry about a false failure, or sporadic false failures taking up time or breaking your thought process at random.

Note: Remember to expect() results when using callbacks.

I've noticed a problem where I call showTip() in my own on( 'mouseenter' ) code and hideTip() moves the tip just shown. This happens when showTip() is called as the mouse moves from element to element and the interval between calls is less than the closeDelay option.

This happens inside the fadeout() callback function that moves the tip. A related issue with hideTip() executing after showTip() is the tip arrow gets removed.

My work-around is to call $.powerTip.closeTip(); before calling showTip().

What's the browser compatibility of PowerTip? What versions of IE and Safari are supported?

A common task for implementing PowerTip is styling the tooltips for the project. It would be helpful if the documentation provided some information, hints, and guidelines for developers wanting to adjust the styles, implement one of the packaged themes, or custom craft their own tooltip design.

The jQuery Plugin Registry has reopened after a very long hiatus. The process of publishing a plugin is a bit more technical than last time, but it is worthwhile to put PowerTip in their database.

When a powertip is enabled on an element with a z-index that is greater than 1 (or is contained within a parent element that has a z-index greater than 1) the powertip displays behind the element. For example, I have a popup that is given a z-index > 100 (depending on its place in the popup stack) and has buttons inside of it with powertips. All of these powertips appear behind the popup

Currently tooltips are not accessible to visually impaired users or users who navigate with the keyboard. Accessibility features should be added to make tooltips useful to those users.

• It has been suggested that PowerTip implement ARIA standards (intro, spec) similar to this example.
• Tooltips should open on focus and close on blur to support keyboard navigation.

As discussed on #26, this would suppress the attachment of event listeners, leaving that to the implementing developer.

I should be able to submit a pull request for this sometime this week.

From #55

From @stevenbenner

This is pretty straight-forward:

window.document becomes document
window.setTimeout becomes setTimeout
window.clearTimeout becomes clearTimeout
window.setInterval becomes setInterval
window.clearInterval becomes clearInterval
window.SVGElement becomes SVGElement.

I want to do this in a separate PR.

If I launch PowerTip with the ".my_class" selector, I should want to have tooltips on existing element with the class "my_class" AND on element added with Ajax later.

The integration tests were originally written to test the built version of PowerTip, which didn't expose anything but the core function, options, and the API. This means that the tests were mostly testing the effects of the plugin and validating the expected behavior of a fairly complex system.

Since that time the project source code was split up into more testable objects and a fairly comprehensive suite of unit tests were created. However, the integration tests were never removed. As a result most of the integration tests are either duplicates of unit tests or redundant observations of stuff that is already covered in unit tests.

The few cases where integration tests are testing code that is not covered in unit tests probably needs to be rethought. The actual effects that are tested in these cases probably can be converted into unit tests.

So it's time to give a hard and critical look at the integration tests.

• Remove duplicate tests
• Refactor complex integration tests into simple unit tests
• Try to end with a test suite that no longer has integration tests

Hey,

i'd like to suggest to add a onClick open option to the tooltips. The Tooltips are working great, but for some Buttons i'd like to have the tooltip to open click not hover. That would a great addition!

Thanks & keep up the good work!

If the element that triggers a tooltip spans across two or mores lines the tooltip appears centred on within the viewport rather than positioned close to the appropriate target element.

So you may have a paragraph containing "Some Link" which triggers a tooltip and the browser is at a particular width that causes the link to be split over two lines, i.e., "Some" at the end of line 1 and "Link" at the beginning of line 2. That's when the issue occurs.

I couldn't see anything in the docs that mentioned this as a known limitation.

$this.removeData() in destroy() does not include DATA_POWERTIP, DATA_POWERTIPJQ or DATA_POWERTIPTARGET.

This showed up as problem where I have one powertip for hover and another for click on the same element. The hover tip just uses the title property and the click tip uses DATA_POWERTIP. Because DATA_POWERTIP isn't removed a subsequent hover used DATA_POWERTIP instead of the title.

-Neville

When a user is navigating a page with the keyboard they will see the tooltips open when the element receives focus, but the tooltip will not close until the user tabs off of that element. This is not optimal for keyboard navigation because the tooltip may be covering something that the user wants to see and the only way for them to close the tooltip is to navigate to the next tab stop.

It is a common convention that the escape key will close any open modal or overlay items, so the escape key should close tooltips as well.

This is related to the keyboard navigation work implemented in issue #3.

When tooltips that are set to follow the mouse become trapped in the bottom-right corner of the browser view port they just stay there, blocking any content that may be present in the corner of the view port. It would be better if they flipped to a top-left orientation so that they do not cover the content the user is trying to point their cursor at.

PowerTip is getting larger, and the tests are getting more hacky and difficult to implement. It might be time to setup a build system and refactor the project into separate logical (and unit testable) chunks.

Grunt seems to be the most popular build tool for JavaScript projects, and is probably the best choice for PowerTip. Grunt is also used by jQuery, so it is more likely that developers familiar with jQuery development will understand the project structure.

Investigate setting up a build system for PowerTip.

Requirements:

• Contributors should be able to run and test the project as it exists in the repository without having any unrelated development tools installed (e.g. node.js, grunt).
• Project and file structure should lend itself to unit testing.
• Built version of the project should maintain the exact same namespaces and use of closures.
• Built project should not expose any of the variables or objects that are currently protected by scope.

Right now, when tooltip has collisions from all sides, the last gravity from the list is chosen.
It would be much better if powerTip will calculate the the most "easy" collision instead (the one which has more space for a tooltip).

Grunt 0.4.0 has been released. It has a lot of changes and significant improvements. But the upgrade process looks like it might take more than the usual version++ to upgrade the configuration files in the PowerTip project.

Investigate what will need to be changed to migrate to the latest version of Grunt and implement those changes.

When you move off of a tooltip which uses mouseOnToPopup it is possible that both closeDesyncedTip()and closeTooltip() call hideTip() and it posts two powerTipClose events etc.

I wasn't sure how best to fix this. Testing session.isClosing at the start of hideTip() isn't right. The test needs to be at the element level I think.

-Neville

I have a single page js app where html is added and removed without a page refresh. Therefore I need to re-invoke powerTip quite often depending on what I'm displaying.

Take for example:

function enable_tips() {
   $('.contextual_tips').powerTip({placement: 'ne', mouseOnToPopup: true});
   $('td.some_other_tips').powerTip({placement: 'w', mouseOnToPopup: true});
}

I don't believe it is the calling that enable_tips function causes the issue, but at somewhere along the way powerTip will add both ne and w to the class of the powerTip element causing a visual defect, like a black bar through the powerTip popup.

I trace it to the offending piece of code in tooltipcontroller.js

tipElement.addClass(finalPlacement);

which was causing the powerTip class to show:

class="ne w"

I don't know if this is the best fix, as it blindly overrides the class attr, but in my testing changing the above to:

tipElement.attr('class', finalPlacement);

Resolved the issue for how I use powerTip.

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.

The Grunt plugin grunt-contrib-jshint has been bumped to version 0.2 and now uses JSHint version 1.0. This is worth taking advantage of asap because JSHint 1.0 has some useful improvements.

There have been some changes to JSHint that will probably require some minor changes to the PowerTip source code and/or JSHint config files to get the code passing through the linter again. The most obvious example of this is that commas are now required to separate rules in /*jshint */ directives.

Requirements:

• Bump grunt-contrib-jshint dev dependency to 0.2.
• Reformat JSHint directives (or move them from the source code to the .jshintrc file).
• Clean up the code that the linter dislikes where possible.
• Adjust JSHint configuration to compensate for code that cannot pass linting (e.g. indentation in built js).

The window width/height and scroll x/y offset are used a lot in PowerTip, but they don't change very often. When they do change there is always an event fired letting us know. So it only makes sense to cache those values to avoid repeated lookups and update the values when the appropriate event fires.

This should provide a significant performance boost, particularly to mouse-follow tooltips.

Sometimes the tooltip top and left position CSS is being updated as the mouse moves around the screen, even though the tooltip is closed and the mouse is not over an element with a tooltip associated to it.

While this doesn't break any functionality, it is a waste of browser resources when it occurs.

Currently PowerTip ships with one very basic CSS layout. While that layout is simple and effective, it isn't exactly the most beautiful tooltip to have ever graced the world wide web, and it doesn't have optimal contrast when used with very dark web designs.

It would be nice to have some ready-made alternative CSS themes so that developers have some design options for PowerTip packaged with the release. Hopefully this will provide developers with tooltips that may work better for their web site designs without them having to custom craft their tooltip design using some fairly advanced CSS techniques.

If a link has a tooltip and the target attribute is set to _blank (which causes the linked resource to open in a new tab/window) the tooltip will not close by itself when the user activates that link. This is a minor problem for a fixed placement tooltip, but if the tooltip is set to follow the mouse it is a much more objectionable problem.

Probable cause:

• This is probably happening because the activated link receives focus and does not blur when used.

Desired behavior:

• When the user activates a link that opens a new tab or window the tooltip should close.

Possible solutions:

• Perhaps tooltips should close when the window looses focus or the mouse leaves the window.
• Maybe mouse-follow tooltips should not respond to keyboard navigation events.

It has come up that we can make tooltip arrows work in Internet Explorer 8 by adding RGB color fallbacks for the RGBA border colors. IE8 still has a significant market share and it shows no sign of disappearing anytime soon so it's probably a good idea to implement this.

Currently there is no way to open or close tooltips other than by hovering on them. It would be nice if there was an API that would allow developers to open and close tooltips on demand.

Use cases

• Close tooltip button.
• Let users without a mouse (e.g. tablet & mobile) open tooltips.
• Informational links.

bower/bower#150

I'm trying to user jquery-powertip via bower. Any chance we can have a built version kept in repository?

Hi,

I would like to know if there is any way of adding a class to a tooltip main div. I think this would be very useful because everyone could do a number of styles (colors) and then apply them with adding a class to the tooltip main div. Personally I wanted to use it for forms. If an input field is filled in incorrectly a red tooltip appears. If someone needs more info on an input field a blue tooltip appears. How can I achieve it?

regards
HoGo

The current smart placement feature is effective, but it might be overkill for some situations. It would be nice to have a option where tooltips would "slide" into a fully visible position instead of shifting to another placement entirely.

For example:

• If a tooltip set to east placement would hit the bottom of the viewport it could move up however many pixels are necessary to keep it in the viewport (instead of shifting to north-east placement).

Maybe/maybe-not:

• If a tooltip set to north placement would hit the right side of the viewport it could move left however many pixels are necessary to keep it in the viewport. Though this effect is nearly the same as standard smart placement.

Gotchas:

• Choice and positioning of CSS arrows.
• Unusually large tooltips.

Tooltip will not open when when the element receives focus (via the tab button) if the element has the mouse cursor hovering over it.

I am using my own on( 'mouseenter' ) code to call showTip() as I need to set various options specific to each tip. In order to get the hover intent code working you also need to pass the event ie.showTip( element, event ) IMO this should be added to the documentation.

Thanks,
Neville

I am using a manual powertip as follows:

$('body').on('click', 'a', function( e ) {
    $(this).data( 'powertip', $(some content) );
    $(this).powerTip( { mouseOnToPopup: true } );
    $.powerTip.showTip( $(this) );
});

When the user clicks on an <a> link the power tip is shown. And when the powertip closes I have:

$('body').on('powerTipClose', 'a', function( e ) {
    $(this).powerTip( 'destroy' );
});

The problem is that quite often while I move the mouse from the <a> link on to the powertip, it closes before the user can interact with it.

I've not been able to pinpoint any specific cause and it almost seems to occur at random.

-Neville

Currently, stack tracing errors often shows a list of function() references, making it a bit more difficult and time consuming to determine where an error originated. This makes the already difficult task of diagnosing problems with timers and callbacks more difficult.

All anonymous functions should be named so that it is easy to identify what piece of code is referenced in a stack trace.

2 space indents is becoming more prevalent (aurajs/aura#82 (comment)), but regardless, an .editorconfig (http://editorconfig.org) in the root of the project will editors to have their indentation set.

If going with tabs:

core.js line 11
displaycontroller.js lines 34, 62, and 103
tooltipcontroller.js lines 144, and 164
utility.js line 17

Or should we switch?

PowerTip is officially in use on live, consumer facing web sites. So it's time to get a little more formal with the development process and write some unit tests to guarantee that everything is working properly.

Important tests:

• Verify that powerTip() is hooked to jQuery
• Verify existence of and access to default settings and smart placement lists
• Verify mouse interactions
• Verify keyboard support
• Verify that the various ways to set tooltip content are working
• Verify API is exposed an functioning
• Verify that all of the PowerTip events are firing

QUnit would seem to be the logical choice for the unit testing suite.

I'm trying to implement to power of your jquery-powertip for my wordpress loop, but the tooltip only shows content for the last post in the loop.

Is it possible to use your jquery-powertip with the wordpress loop? If so, can you provide a loop example featuring your powertips please?

The powerTip() function does not currently check if the tooltip system has already been setup on an element before it does its work. This can lead to unpredictable results if powerTip() is run on the same element more than once.

PowerTip should check if the element has already been setup with tooltips, and if it finds that the element has had the plugin run on it then PowerTip should do one of the following:

1. Skip the element entirely, or
2. Destroy existing tooltip instance, event handlers, and options then replace it with a fresh instance configured with the requested options

Currently fixed tooltips are not constrained to the browser view port. It would be nice to have an option where tooltips would always be displayed in the most visible position.

Use cases:

• Users with small browser windows (e.g. tablet & mobile environments)
• Tooltips attached to inline text where it is difficult to predict where that element will render.
• Tooltips for large elements that may be partially obscured below the fold.

Right now there is no automated code quality or error detection being run on the PowerTip CSS files. This is a problem because the CSS rules are so fundamental to the function of the plugin.

It just so happens that the grunt-contrib-csslint task has just been released. This task uses the csslint project to handle the actual linting, which has some very dubious rules (e.g. "Don't use IDs in selectors"). So while the contrib-csslint plugin is probably the best choice, each rule that is enforced needs to be carefully considered.