Is there a way for automatic "live" binding ? about tooltipster HOT 30 CLOSED

For now, this is my "dirty" solution:

        $('body').on('mouseenter', '.tooltip-class', function(){
        $(this).tooltipster({
            theme: '.tooltipster-shadow',
            updateAnimation: false

        });
        $(this).tooltipster('show');
    });

from tooltipster.

👍 Running into this type of problem using tooltipster in Ember.js. Would love to be able to just specify a selector.

from tooltipster.

+1

from tooltipster.

Another dirty solution, almost the same as diegoviola1's just some logic and dynamic positions.

$('body')delegate('*[title]', 'mouseover', function(){
    $(this).tooltipster('destroy').tooltipster({
        position: $(this).data('position') || 'top'
    }).tooltipster('show');
});

from tooltipster.

Sorry for the delay! This is definitely something I will try and get implemented soon.

from tooltipster.

Hello, AFAIK there is no clean and cross-browser way to tell when a child has been inserted into DOM, which means that there can be no cleaner solution than diegoviola1's. And yes it's dirty, the handler may fire several times per second.

Although quite handy, I personnaly wouldn't encourage this way of doing things. As far as I'm concerned, I believe this snippet should not be included in the tooltipster plugin and that a note in the documentation about this hackish possibility should be enough.

from tooltipster.

Do you mean that there is no solution for this version, or there are no such solution? Because this kind of logic is currently being implemented by other plugins (foundation, bootstrap, but they are not cool as this plugin :P)

from tooltipster.

I do not understand your question. I mean the solution you gave above is the only one, and I say it's dirty. Other plugins, cool or not, are free to implement dirty solutions. I personnaly don't think Bootstrap is "cool" anyway, rather dirty, but that's not the point.

The point is, I personnaly believe that plugins should encourage to write nice code, and people who know what they are doing ought to do trade-offs themselves (dirtyness for handiness). People who know what they are doing can implement this feature in 2 minutes anyway, it's a no-brainer.

Of course I understand that other people can think otherwise on that matter. I gave my opinon, Iamceege will make the decision.

from tooltipster.

No, wait. My dirty solution is not used by bootstrap or foundation (or it is? I'll check their code tomorrow). My dirty solution is only a way to do what I mean. And its a bad solution. My question is if it is possibile to implement other solution but in the clean way.

Il giorno 17/nov/2013, alle ore 13:11, Louis Ameline [email protected] ha scritto:

I do not understand your question. I mean the solution you gave above is the only one, and I say it's dirty. Other plugins, cool or not, are free to implement dirty solutions. I personnaly don't think Bootstrap is "cool" anyway, rather dirty, but that's not the point.

The point is, I personnaly believe that plugins should encourage to write nice code, and people who know what they are doing ought to do trade-offs themselves (dirtyness for handiness). People who know what they are doing can implement this feature in 2 minutes anyway, it's a no-brainer.

Of course I understand that other people can think otherwise on that matter. I gave my opinon, Iamceege will make the decision.

—
Reply to this email directly or view it on GitHub.

from tooltipster.

There events for DOM changes. It can be implemented through that cleaner.
Also the dirty code for fallback for older browsers.
On Nov 17, 2013 4:30 PM, "Diego Viola" [email protected] wrote:

No, wait. My dirty solution is not used by bootstrap or foundation (or it
is? I'll check their code tomorrow). My dirty solution is only a way to do
what I mean. And its a bad solution. My question is if it is possibile to
implement other solution but in the clean way.

Il giorno 17/nov/2013, alle ore 13:11, Louis Ameline <
[email protected]> ha scritto:

I do not understand your question. I mean the solution you gave above is
the only one, and I say it's dirty. Other plugins, cool or not, are free to
implement dirty solutions. I personnaly don't think Bootstrap is "cool"
anyway, rather dirty, but that's not the point.

The point is, I personnaly believe that plugins should encourage to
write nice code, and people who know what they are doing ought to do
trade-offs themselves (dirtyness for handiness). People who know what they
are doing can implement this feature in 2 minutes anyway, it's a
no-brainer.

Of course I understand that other people can think otherwise on that
matter. I gave my opinon, Iamceege will make the decision.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/46#issuecomment-28650465
.

from tooltipster.

True that DOM changes events seem more cross-browser than they used to be, thanks for pointing that out, sorry I missed that. Internet Explorer < v11 do not implement them however, that leaves us plenty of unsupported users. But definitely something to consider in the future.

from tooltipster.

👍

I've come across this serveral times, having live delegation without 'hacks' would be fantastic!

from tooltipster.

Why worry about DOM Mutation events such as DOMNodeInserted or MutationObservers at all? They are heavy on the browser and feel like overkill for a relatively simple jQuery plugin. As mentioned, only the most modern of IE versions implement them anyway. What are the arguments against providing a simple delegation solution similar to Bootstraps?

from tooltipster.

@alexkolson I think something similar to Bootstrap's delegation would be fine. Something like:

$('body').tooltipster({
    selector: '[rel=tooltip]'
});

Obviously we still need to support:

$('.my-tooltip').tooltipster();

I think that's do-able. There will be a basic check to see if the "selector" option has been set - then you go on from there. When using "selector", we'd just need to attach the events higher up like:

$(document).on('event.tooltipster', selector, function() {});

Thoughts?

from tooltipster.

@iamceege I think people are essentially asking for a way to initialize new HTML elements automatically as they are added to the DOM, not so much for the possibility to easily delegate the listening of triggering events (which would require a layer of garbage code all over the place, not mentionning all the edge case issues it would probably cause). People who want to delegate that can just use the custom trigger option and do things themselves easily enough.

There are 2 ways to do it, mutation events and mouseover events. Keep in mind that mouseover events will not work in all cases, because sometimes you don't want to wait for a mouseover to instantiate tooltips, especially if you work with custom triggers, or have race conditions between your events, or stop them from propagating for some reason. Only the DOM mutation events provide a flawless solution, and they're not widely supported yet.

To implement the mouseover events solution, the best and minimal addition to Tooltipster to support automated tooltip instantiation would be to just bind on body (or a custom element) and then check if the hovered element has some '.tooltip' class (which would mean that the element is meant to be a tooltip but has not been tooltipstered yet) and, if so, initialize it. After that, tooltips work as they always have. It's basically what @diegoviola1 proposed to begin with.

The simplest way I see to implement this would be a static delegate method and nothing else, which is more intuitive since we're not actually calling out to any instance of tooltipster on the body. It would not require to edit anything in the current code base. It would be used like this

$.fn.tooltipster('delegate', '#selector', '.tooltip', usualTooltipsterOptions)

But @alexkolson, listening for all mouseover events and checking the css classes of each and every hovered element has a performance cost. It's also lazy programming and I think people should not be encouraged to do lazy programming without understanding the mechanics that it involves backstage.

Again and anyways, people who want to achieve that and understand the caveats of the technique only have to add the 5 lines below somewhere in their own code. You don't need us to include that garbage directly in Tooltipster, and we don't need the extra questions that confused people will come ask in this support section.

$('body').on('mouseenter', '.tooltip', function(){
    var options = { ...your options here...}, $this = $(this);
    $this.tooltipster(options);
    if(options.trigger && options.trigger == 'hover') $this.tooltipster('show');
});

Conclusion, I personnaly think that this thread should now be closed - and reopened in 10 years when no one uses anything less than IE12.

from tooltipster.

@iamceege I like your solution a lot. 👍

@iamceege I think people are essentially asking for a way to initialize new HTML elements automatically as they are added to the DOM, not so much for the possibility to easily delegate the listening of triggering events (which would require a layer of garbage code all over the place, not mentionning all the edge case issues it would probably cause). People who want to delegate that can just use the custom trigger option and do things themselves easily enough.

@louisameline Um, I don't think so. Again, why are we overcomplicating this? Even if some people are, they would be most likely be happy with any way to tooltipsterize dynamically added elements. I'm also interested in you "layer of garbage" code theory. Very subjective and vague. Just trying to understand where you're coming from and why you are so adamant about refusing to provide a solution to what obviously is a desired feature, and one implemented in almost all popular jQuery tooltip plugins. 😄

Yes, others can implement this fairly simply in one spot. And then when they want to do it in another project they have to do it again. And again. and again. EVERY user of tooltipster would then have to write this boilerplate themselves.

But when it comes down to it, we're debating over fractions of milliseconds anyway. 😄

from tooltipster.

Anyway, I'm currently experimenting with a solution similar to @iamceege's in my fork of tooltipster and when I get it somewhere stable I'm going to submit a PR and we can discuss further.

from tooltipster.

@louisameline @alexkolson There are definitely some valid concerns we need to think through. I still think it's worth poking around and trying to find a solution for.

On another note, I just ran across this interesting solution (top answer): http://stackoverflow.com/questions/6997826/alternative-to-domnodeinserted

However, that still wouldn't work in older IE - but it is interesting none the less.

from tooltipster.

@iamceege Yeah I saw that a while back. It does look pretty cool.

from tooltipster.

@alexkolson Forgive me that I was adamant :) I do have a somewhat deep comprehension of Tooltipster and of a number of its use cases. I have rewritten a significant part of it to make v.3 production-ready in complex scenarios, and have been handling the support over the past few months.

Now, I may not have been clear enough in my first paragraph, I think you did not see what I was talking about, but that's ok. The point of my message was after that : the solutions besides DOM mutation events are fundamentally flawed, and I explained why.

You may have simple use cases where those caveats do not matter, and I know most people do too. But when you write a plugin, you do not write code that you know will fail in advanced use cases, with complex debugging for the poor guys behind the app. To anwser your point, everyday I curse the authors of popular plugins who only think about their simple use cases. Don't even try to tell me about jQuery UI. With your proposal, the caveats would be beyond the level of comprehension of most implementors, even if we tried to explain them in the documentation. I like software that delivers at 100% and if I need more, I'll do it myself, then I can only blame myself if something fails.

I know it does not prove anything, but I do have complex use cases, where we're not talking about dumb tooltips that just make the native ones look prettier. I can see how your proposal would fail in my app for the reasons I gave. And milliseconds do count when you are doing animations and transitions meanwhile, and you want them to be as smooth as possible. Again, in my humble opinion, perfect software does not try to do everything, but it works 100% as advertised.

But I'll be happy to see what you come up with on your fork.

from tooltipster.

@louisameline Ok I totally understand where you are coming from now, sorry if I came off abrupt. 😄 Thanks for taking the time to explain it to me. Yeah, I'll see what I can do but I doubt my solution will be as awesome as you need it for super super super super complex apps like what you work with every day. 😄

from tooltipster.

This should not be tooltipster's responsibility IMO. Instead, you can do something like (and this is just a sketch - not tested:

// takes care of everything that's there on document.ready
$(function() {
  $('.tooltip').tooltipster();
});

// takes care of all things AJAX
$.ajaxSuccess(function(event, xhr) {
  $(xhr.responseText).find('.tooltip').tooltipster();
});

from tooltipster.

@jkodroff After mulling this whole thing over a little more, I agree. This shouldn't be Tooltipster's responsibility - just like @louisameline has suggested as well.

@alexkolson You're totally free to keep working on your fork and I'm very interested to see if you come up with any ideas. :) In the end though, we probably won't support this feature since Tooltipster already provides the necessary hooks to accomplish what people need (without kludging up our codebase for a specific use-case).

Thanks everyone! This will now be closed.

from tooltipster.

@iamceege

Yeah after spending some time analyzing the source and trying to come up with a good, general solution that flows well with the rest of the plugin, I'm in total agreement. I'll probably still mess around on my fork and see if I can come up with something that works for MY use case, but it probably wont be anything I'd feel comfortable asking to be merged into the main project. Thanks for at least entertaining the idea. :)

from tooltipster.

There's disappointingly a lot of false information in this thread about the performance cost of event delegation, the difficulty in adding that support, the failure risk of that feature and the subjective brand of "laziness" or "garbageness" in such a feature. Direct targeting and event attachment to a single node by a plugin is only more performant when your content is rather static. If you have dozens of nodes routinely created and destroyed, attaching and destroying event listeners to each individual node is actually the less performant and "dirty" solution. Proper abstraction for a collection of highly dynamic nodes is to attach a single event listener to the nodes' parent.

I don't think the plugin authors are under any obligation to support delegation, but it certainly would be useful and would better support use cases of dynamic node attachment / removal. So I just wanted to clear up some of the misinformation provided earlier in this thread. It's not that complex to support delegation, it isn't automatically less performant, and it isn't more prone to failure. The workarounds listed are still attaching tooltipster event listeners to individual nodes, so those workarounds are not as efficient as supporting delegation in the plugin.

Anyway, I hope you'll reconsider.

from tooltipster.

Thank you for your message. I feel obliged to answer to such argumented messages :) Although I can only agree with your statements from a general point of view, I'm not sure see how it invalidates any of the previous discussion in our particular case.

I'm not saying some kind of "Tooltipster Delegate Manager" plugin, that would initialize and/or trigger the tooltips from the body, should never be used or does not have its pros. Note that it's mostly on the dynamic initializing part that I'm ranting, not so much on the delegated custom triggers, and because of potential unexpected failures more than performances.

The bottom line is that delegating the creation of tooltips is not rock-solid as I want Tooltipster to be, especially since our plugin is getting more and more sophisticated in v4 and will likely be used in more and more complex scenarios. Scenarios where you don't want the tooltips initialized at some random timing and subject to the bubbling of events, sometimes creating tricky bugs due to race conditions. The developers who understand the ins and outs of delegating may have no issue with it, but I believe they are not the majority of us. So I don't want to promise some kind of magic feature that everybody wants to activate blindly and that later bites you in the butt.

Again, I am convinced that many people will love a "Tooltipster Delegate Manager", and probably most people won't ever complain (or even notice the bugs). The way I see it, such a script had better be a standalone plugin with a fixed set of listeners on the body that would initialize all tooltips and manipulate them with method calls (we do provide everything necessary), because the individual tooltips instances shouldn't have to handle this themselves.

So anyone can just publish their own standalone project on Github to do just that, it would probably represent a small number of code lines. But I personaly consider that such a module would not go well with my philosophy of reliability (or should I say Least Astonishment) that I've been trying to add to Tooltipster. And I certainly don't want to provide support for people who don't understand why delegating creates tricky side effects that they will call Tooltipster bugs.

from tooltipster.

I see here two different concepts being mixed, so I rather clarify what I understood and see if it helps in anyway.
Dynamic updating of tooltips is needed for use cases where elements are removed and created on the fly, for example with ajax updates. There are three ways of doing it that are referenced in other comments:

1. Using delegate on parent to initialize.
2. Using delegate on parent to trigger the tooltip.
3. Initializing when the element is created (ajaxSuccess).
   Option 1 was "adamantly" questioned by @louisameline because it adds overhead to events that may trigger all the time. The initialization of tooltipster for an element may not be trivial.
   Option 2 is what I understand @matthew-dean is referencing and I think he makes a good point. What I don't see is how you can implement efficient trigger delegation that works faster than initialization. If there's some way of doing it, it's worth looking into it.
   Option 3 is what people should be aware of and consider before thinking this too much.

I want to make sure that the distinction between 1 and 2 is clear. Again, not sure that 2 is possible or feasible.

from tooltipster.

I've wrote yrs ago to this issue and seems like this issue will never be resolved, so I hope it's not a problem to "promote" my own creation :)

https://github.com/DoclerLabs/Protip

from tooltipster.

No problem @wintercounter, good luck with your plugin :)

But to be fair, there aren't any plugins that can "solve" this issue. They can only offer a different approach to it, with their pros and cons. There are several decent tooltip plugins out there, but switching only for this delegation thing that takes like 10 lines of custom code to implement would not make much sense IMHO.

from tooltipster.

I know, but i still tried a better approach using MutationObserver.

from tooltipster.