Remember the previous position

[Jako]

Remember the previous position of the select before it is set to position absolute.

[adamcoulombe]

Could you please describe what the issue is?

I'm guessing by the code you posted that if you give a top or left style to the select via anything other than a class or style attribute, they dont maintain alignment?

[Jako]

If the select element is floated, 'position absolute' without setting 'top' and 'left' is not suitable. It could be also defined by css, but since the position already known, an extra css rule does not have to be written.

[adamcoulombe]

Is there a reason to be applying a float to an element that will inevitably be given position:absolute ?

[Jako]

I often style my forms the CSS Drive way. That is the reason for floating the selects.

[adamcoulombe]

@Jako can you please post an example so I can see exactly what issue this is causing? I'm struggling to understand a realistic situation in which this causes a problem. And if the float is causing an issue, why do we not just unfloat it, since it will be given position:absolute anyway?

[Jako]

You could try it on http://jsfiddle.net/8S8AR/

The span is in the right position but the select is too much left because the label and the selects are floated (Sorry, forgot the labels in my first answers).

[enigmatic-user]

Same here, the select shifts to the left as soon as customSelect is applied (I'm using the CSS framework YAML that also uses the same method for styling "columnar" forms), so the select field can't be used if the mouse is in the right part of .customSelect. Setting the left position of the select to the width of the label makes it work again. It would be nice if customSelect could do this on its own.

[adamcoulombe]

Merged into 0.4.2. Thanks @Jako for the patch

[oskarrough]

Now that the plugin has changed to use absolute top/left values, it would be helpful to note in the documentation that a wrapper with position: relative helps getting the correct positioning.

[adamcoulombe]

@oskarrough is the position not set correctly without relative on the container? I am interested in your issue

[oskarrough]

Sure, I'll try to explain with a javascript slideshow. Hope it makes sense.

Before the javascript is initialized the slideshow consist of just images on top of each other. If each image has a height of 200px, the total height would be 400px. After the slideshow javascript is initialized the total height would be only 200px.

If customSelect gets the positioning 'before* the slideshow, it will be wrong after the slideshow.

1. One solution is to get your script order straight but that's asking too much of the user, imo.
2. Another way would be to wrap the selects in a relative continer, effectively rendering the rest of the page (our problematic slideshow) indifferent — since the positioning would be calculated from that container.

[adamcoulombe]

@oskarrough I feel like the positioning patch that was pulled into 0.4.2 may cause more issues than it will solve. I'm wondering if it would be best if we kept it as an option as opposed to copying the position() onto the span by default.

[oskarrough]

Well, positioning like the one in 0.4.2 isn't very reliable, that's for sure. Plus what happens when the window is resized etc. It's better to use methods that don't rely on "magic numbers" in this case.

So what do we have?

a. position: absolute; with no specific values.
b. using offset/position with a dynamically inserted wrapper with position: relative;

or?

[Jako]

A dynamically inserted wrapper with position: relative; by option would be my solution. So the select could be have position: absolute by default and the calculation of position/offset would occur only if needed.

[plusplusben]

I think this issue is causing more issues than it solves. I dynamically insert content above my customSelect. Then when I try to click on it, the clickable area is offset from the visible select.

[maskddingo]

This patch basically broke the plugin imo. It solves one problem by creating another. Fortunately, it was easy to remove even from the minified version. I think this issue should be re-opened until it is solved properly.

[plusplusben]

I totally agree. I removed it from the minified version i'm using as well.

[adamcoulombe]

I also agree and have been planning to revert or make the positioning an
option but haven't had time to make the change. Thanks for the feedback

On Wednesday, July 31, 2013, plusplusben wrote:

I totally agree. I removed it from the minified version i'm using as well.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/38#issuecomment-21896183
.