Consider add container option, that solves some bootstrap issues

[marcospassos]

Hello,

The container option was introduced to solve some issues of tootip and popover (like style break in btn-group, popover hidden on modal, etc). So, IMO, it also could be implemented here.

Reference:
twbs/bootstrap#5768

I would be happy in submit a PR if you agree.

Thanks!

[pkozlowski-opensource]

Yes, this was discussed already in #132

@marcospassos a PR would be awesome. We still got massive code duplication between the tooltip and popover so be warned! We are up to cleaning this (extracting common parts), but ok, not yet there...

[joshdmiller]

These are my initial thoughts, subject to revision:

I don't feel it solves any problems, but it would provide a workaround to a couple of issues, which is why it was added upstream.

I think this exposes one of the (few, but sticky) challenges in porting jQuery plugins line-for-line to angular: I'm not sure how I feel about passing DOM references in as attributes to directives.

Plus, I'm not entirely sure how it would work. ui/bootstrap does not depend on jQuery, so the selectors we could even pass are very limited. So the other option would be passing in a jqLite object, and I can't see how that could work without referencing a DOM object in a controller, which is bad juju.

So my instinctual reaction is something along the lines of "egad!". Maybe it's just me. :-)

@marcospassos Did you have an idea of how this might work?

[pkozlowski-opensource]

@joshdmiller Josh, actually you are completely right, my brain is half-asleep today. Switching off my laptop, shouldn't do coding anymore today :-)

[marcospassos]

@joshdmiller I agree with you. But the issues solved with this workaround are very relevant (e.g. if you use the popover inside a modal probably it will be cut due the overflow-y, if you use a tooltip it will move the scrollbar always you hover you cursor over, etc). So, an Angular-way workaround should be provided. I think it should be limited just by id and name selector, mainly due to performance issues. Once jQuery selectors are not supported, IMO, their use should be discouraged to avoiding misunderstanding of new users. So, instead of containter="body" or container="#identifier", we can use container-name="body" or container-id="#identifier", estabilishing a precedence rule (e.g. container-id takes precedence over container-name)

It sounds good for you?

[joshdmiller]

@marcospassos I didn't mean to imply that the issues shouldn't be resolved. I agree they should, but they should be solved in an "angular way". Unfortunately, this kind of thing doesn't have a great solution yet. It's not super common, but it's vexing when we do encounter it.

My personal recommendation is always that new AngularJS coders avoid jQuery like poison. From my experience, it just causes more problems than it solves because their philosophies are just too darned different - so different in fact to be, in some cases, bordering on mutually exclusive. But the philosophy of ui/bootstrap is to have "pure AngularJS" widgets based on Twitter Bootstrap. So while the jQuery selectors would work if the user chose to include jQuery (angular.element would just pass through), they would not out of the box, so we can't rely on them in a bug fix.

But angular.element will only take a DOM node or a string representation of code. So in order to implement your container-id="#id" idea, we'd have to hack through the DOM manually with document.getElementById; that's not in and of itself totally awful, but it's a trifle frail. For container-name="body", I'm not sure how that would be implemented at all, save manually traversing the DOM, which is no good - unless I'm missing something. In these cases, we'd basically be emulating jQuery in a directive!

I'd love to solve this, but I'm not quite sure how to do it yet.

[marcospassos]

Josh, yes, my idea was use angular.find for the container-name and getElementById for the container-id. I avowed that isn't the most elegant solution, but was the best I've thought for now.

IMO, a good Angular-way high-level solution would be something like the scope declaration(@, =, &, etc) but for passing DOM element in attributes.

[joshdmiller]

jqLite.find() is from a starting element. Are you suggesting it starts with $window? What about apps that don't own the whole document? And find takes only the node name, so it would work with 'body' but would never work with, say, 'div' or 'header'. If you're comfortable with a workaround in your use case, that's cool - each developer can obviously asses and weigh it appropriately - but I want to make sure we really think through how this should work before we include it as a default behavior for everyone.

As for scope-like declaration, I'm not sure I follow. Regardless of the declaration syntax, wouldn't we have the same challenges of locating nodes we're struggling with currently?

To take a step back - for what it's worth, I'm not sure we're even asking the right question. We're asking "how do we pass a DOM element to a directive?". I think we should be asking "do we need to pass a DOM element to a directive?".

Right now, the tooltip inserts the tooltip node (in a very jQuery-like fashion) directly after the element on which it is applied when a mouseenter is hit. Is this the right approach? Should we be inserting a DOM node at all? Perhaps there is another approach that would avoid these challenges.

[marcospassos]

Yes, you're right, but with this issue we cannot use the tooltip and popover in many cases (modals, button groups, div with overflow: auto, etc). The perfect solution can take a long time, so IMO, I think that a intermediary solution may be used for now until a better idea.

[pkozlowski-opensource]

While @joshdmiller points are very valid I agree with @marcospassos that we should try to find a pragmatic solution here. At the end of the day we need to stick this DOM element somewhere... I don't know, maybe we should have an option like tooltip-container="true" and is specified stic this tooltip next to http://docs.angularjs.org/api/ng.$rootElement?

Unless there is some other, elegant solution here...

[joshdmiller]

My problem is that this doesn't actually solve the problem - it merely relocates the problem someplace else. The issue is with the last-child psuedo-class; so if the tooltip is moved out of the immediate element, then it will no longer mess with the last-child pseudo-class...except if $rootElement also uses last-child. Then what?

I'm all for a pragmatic solution, but it should actually solve the issue rather than just making it somewhere else's problem.

If we can figure out a way to identify a DOM node to use as a container (that doesn't make us all cringe) then I feel that is the better placement-based solution. On the to-do list is a configuration service for the tooltip and popover to provide default values. Perhaps we could place a container property there that takes a generic selector string. When the configuration service is first requested, that element could be (inefficiently) resolved to a DOM node that is returned to the directive. The benefit of this approach is that we only have to do nasty DOM stuff once; also, we have abstracted all of that out of the view, controller, and directive, so it's a trifle less gross. The usual downsides dealing with ID uniquness, etc., would all still apply, but it's a pragmatic solution.

Another potential solution is to make the tooltip a child element of the directive. This would be much less likely to encounter issues with pseudo-classes, but may have other downsides - I haven't put enough thought into it to formulate a strong opinion.

Anyway, my point is that there are multiple potential solutions and this issue is only a few days old. While Twitter pushed a fix last week, the issue was open for more than a year. I'm not sure why we feel the need to rush a solution into the code without due consideration of the ramifications of said solution.

My two cents...for what it's worth. :-)

[marcospassos]

@joshdmiller as I've pointed out, the last-child is not the only issue. Try putting a tooltip inside a modal with scrollbars, hover the cursor over and see what happens (or just put a popover that overflows the modal's body). These issues require to set a correct container to be solved.

[joshdmiller]

@marcospassos - @pkozlowski-opensource had mentioned allowing either adjacency or $rootElement. I pointed out that $rootElement wouldn't solve the pseudo-class issue. Regardless of any other issue, that still stands. Can you post a Plunker with the other issues, please?

But thank your for responding to 5% of my comment. What about the rest? Like the part about how to work in a custom container element... :-)

Edit: In retrospect, that last part may have sounded rude, but I intended it to be taken humorously. Just in case, I wanted to clarify.

[marcospassos]

@joshdmiller, sorry I was very busy in the last days. As I've said, I really don't know how it can be made. I was thinking about in the last days, I don't have a good solution yet.

I was posting the plunk when I noticed this simple example is not working:
http://plnkr.co/edit/ZgtuJP?p=preview

Is this a known bug?

[joshdmiller]

@marcospassos No worries - I've been pretty busy too. Looking at that Plunker, the issue isn't really the tooltip placement in this case, but the constant re-evaluation of the expression-based array in the ngRepeat. Every time we mouseenter, the tooltip is triggering a $digest, forcing a re-evaluation... But when you place the array on the scope instead, it works just fine: http://plnkr.co/edit/h0a9cD?p=preview.

Can you post a modal example?