Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Position: Add flip-classes. Fixes #5937 - Position: Add ability to de…
…termine if the element is flipped via css
- Loading branch information
1 parent
0245b72
commit d5452c0
Showing
4 changed files
with
205 additions
and
1 deletion.
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
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
d5452c0
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.
We should really back out this commit. We shouldn't be using classes to designate that the element was flipped. Do we have any practical cases where classes are useful?
d5452c0
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.
Especially in the case of the tooltips, yes. I'm am also using it for specific styles for the selectmenu where, if the menu flips to the top, it shows another style.
d5452c0
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.
Can you please provide a demo of this being used? It seems like knowing that it flipped isn't nearly as useful as knowing where it is, e.g., knowing that you're at the top is way more useful than knowing that you flipped vertically.
d5452c0
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.
Here are the tooltips, the site is behind a firewall so only screen grabs: http://dl.dropbox.com/u/39086/tooltips.png
d5452c0
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.
Screen grabs don't help here. I'm not saying that it's not possible to use these classes, I'm saying I don't think they're a good implementation.
d5452c0
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.
Fair enough, the screen grabs should at least give an idea of the situation the tooltips are used.
Not clear on the reasoning for it not being a good implementation, how else do you propose that a developer knows that an element was been flipped? All of the alternatives I used within the tooltip and the select menu code added more overhead to each one of the widgets. Basically, every time one of them opened I'd have to figure out where the element that is being positioned is in relation to the trigger element and then add a class accordingly. So, instead of have roughly six lines of code within the position plugin I had 10+ lines within each one of those widget either by extending or hacking the core codes.
Obviously I am open for discussion, there definitely needs to be a simple way for a developer to know an element has been flipped IMO.
d5452c0
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.
I assume the 10 lines of code you wrote outside of position didn't check if the element flipped, but whether it was on the right or left. That seems much more useful, and is what we should expose. But it shouldn't be exposed as a class, it should be exposed some other yet to be defined way, possibly as additional information passed to the using option.
d5452c0
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.
Maybe we should expose it but just seems like an extra step for the sake of an extra step. If we add a CSS class all the end developer needs to worry about is creating the correct CSS styles based on the flipped position.
If we simply expose the flipped variable then, not only do we expect the end developer to write the CSS styles but they also have to incorporate some logic in an "onBeforeOpen" callback to apply the correct class based on the flip.
So, for the sake of argument, I am building an app that uses tooltip, selectmenu, menubar, and autocomplete (just using those as examples since they all use position at some point in their code) and the designs require a specific look for all the possible views of each one of those widgets, I would need have code for each one of those widgets that does a check before displaying the widget so that they have the correct styles. Let's assume each widget has roughly 12 lines of code to check for flipped top, left, right, bottom, that's 48 lines of extra code at a minimum.
It just seems we can keep everything clean and simple by applying the class right in the position utility IMO.
d5452c0
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.
Unfortunately at this point you haven't proven anything because we still haven't seen any code. We can't use one person's private code as the defining way that we implement a feature.
d5452c0
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.