iframe shim to cover select boxes... doesn't completely work!?

[shadedecho]

So I am well aware of the long standing problem with how select-boxes cannot be covered up by standard div elements simply with z-index'ing tricks, and that this problem plagues IE6, but was fixed in IE7.

And I'm aware of the 2 main strategies for dealing with this problem:

1. iframe shim behind div, above select-box
2. hide/disable selectboxes that fall even partially within the rect bounds of your div.

However, I was just playing around and noticed that #1 doesn't work entirely, and moreover, the same problem even exhibits itself on all other major browsers too.

Basically, if you have a select box, and you click the drop-down, and open the little menu, the MENU ITSELF cannot seem to be covered up, even by an iframe shim, even though the main part of the select box IS covered up. So basically, while the select box is open, it CANNOT be completely covered up.

I'm wondering if anyone knows a workaround for this? In other words, if a user opens a select box, and I happen to have a tool tip or some other sort of floating div thing that I want to position where it might overlap the actual dropdown part, is there anyway to cover up the drop-down menu part?

 

[Vragabond]

Sorry to question your attempts, but do you think it is a smart thing to vest your energy into? I can't fathom a practical moment, where a user would desire to use an elements that hovers over a select box, while the box itself is being used, i.e. is open. I would simply classify this as something that cannot be fixed but probably won't happen in more than 1% of the cases.

___________________________________________________________
[small]Do something about world cancer today: Comprehensive cancer control information at PACT[/small]

 

[shadedecho]

I understand your perspective on asking that question.

Let me just answer by saying, floating (ie, fixed position divs, menus, etc) often times find themselves in proximity to select boxes in sometimes unpredictable ways, and for consistency sake, I was hoping there was a way to never have them covered up unnecessarily by the select box. For instance, the jGrowl type style of alert-messaging, where you have a persistent fixed-position div that shows alert messages... that is something that you'd probably not ever want to have covered up by a select box.

Also, consider this: If you can cover up PART of a select box (ie, the combo-head part of it), but not the menu, doesn't that create a pretty inconsistent UI/UX for web authors and users?

But moreover, the biggest application reason I had, as I eluded to in the post above, is the idea of having a "tooltip" type div that could show up over one or a group of items in a drop-down menu. To me that seems like a real, helpful type use-case, but seems impossible to achieve (unless you can guarantee the tooltip is to the side of the menu, which is hard to do).

I also know the other argument, which is, just find some replacement UI element for the selectbox... yeah, there are tons out there, and they're way better than the native one for this and many other reasons.

But, there's one thing they all don't have that the native one does... the ability to have them all consistently skinned (along with the rest of the native form elements) by the user's OS/browser.

From a user-experience standpoint, I tend to feel that form elements should often be just that, form elements, without styling, so that users can understand visually and predict what they're dealing with -- it's more comforting on a base user-psychology level.

And, whenever you change ONE TYPE of form element to some custom control, you have to replace all the others so you get consistent skinning. And when you do, your page's form elements are now divergent from what that user knows and trusts from a lot of other sites.

Say for instance if you were creating a site that required a high degree of user trust, like finance/banking... the last thing you would want to do is have a bunch of cute, custom stuff floating around, subtlely giving the hints that this site may not be as rock solid as you would want it to be.