This repository has been archived by the owner on May 29, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat(tooltip): added appendToBody to $tooltip
Tooltips and popovers can now be appended to the body of the HTML document instead of directly after the element on which the directive was invoked, by setting `appendToBody` to true through $tooltipProvider.options(). The tooltip specs were refactored slightly to bucket all provider-related specs under a single `describe` for cleanliness.
- Loading branch information
Showing
2 changed files
with
76 additions
and
33 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1ee467f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This behavior limits the equivalent 'container' option to the body element instead of any element; in Bootstrap we can pass a selector for the option:
container string | false false Appends the tooltip to a specific element container: 'body'
Is there a specific reason why angular-ui/bootstrap is choosing to deviate from the Bootstrap option?
1ee467f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klebba the main reason is that we don't require dependency on jQuery and the jqLite baked into AngularJS supports only tag selectors.
1ee467f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I forgot about that. In my case I have a dependency on jQuery already (using the angular-ui select2 directive, which is great) and it was not immediately apparent that angular-ui/bootstrap did not have this dependency. I'm midway through a project and upgraded to 0.2.0 from 0.1.0 to fix a problem with the modal directive and found that tooltip position broke as a result of upgrading. I realize ui/bootstrap is still ironing out kinks but right now its usefulness is diminished to me with this kind of difference from Bootstrap formal which does depend on jQuery. Is there any hope of getting a 1:1 feature parity over time or will these kind of differences have to persist? Thanks for your quick reply!
1ee467f
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klebba There's a difference between feature parity and API parity. In this case, what we really care about is that the tooltip plugin will be able to do everything that the Twitter plugin does; but due to the differences in how AngularJS and jQuery work, the implementation in terms of the API will be different in many cases.
Twitter introduced the
container
option not as a feature but as their way of solving some positioning issues with the way the plugin adds elements to the DOM. We chose to fix that same placement issue with the more AngularJS-friendlyappendToBody
option.That said, there are still some outstanding bugs which we do very much want to fix. The modal issue has been documented in #265. But actually, I've tested it and the case works with the Twitter plugins without using the container option, so this is a bug in our code which we will fix.
Can you confirm that #265 is also your issue?
To directly answer your question: yes, we intend 1:1 feature parity, but how we solution bugs and how we implement the API to get to the same features will, at least in some cases, be very different.