Autocomplete _create assumes zIndex

Just assign the z-index to the .ui-autocomplete-input class instead. Why is that a problem?

Because even when I set the z-index to the .ui-autocomplete-input, or in my case the #search, the autocomplete menu will still be over it. Since it ads one to the zIndex of my input. And unless I set the zIndex with javascript (and only after the _create method is called), its impossible to make my input be over the autocomplete. That may not seem like a big problem, but when the autocomplete uses box-shadow, the shadow is projected over the input, which is undesirable.

Assuming an arbitrary zIndex of the autocomplete on _create is unnecessary, anyway, and forces someone to use !important on .ui-autocomplete z-index, or to change it by javascript, which shouldn't be the case.

After all, an element with position:absolute or position:relative (which is .ui-autocomplete) will already be over the other elements on the page, and if the developer wants something customized, it's his responsability and right to do so.

zIndex is a notoriously difficult problem. The current system of auto-setting to +1 has worked the best for us (our users) so far. Applying a shadow does create an interesting problem. Can you work around that by using the appendTo option and having multiple stacking contexts?

Thats what I'm doing right now, but that introduces other issues, since my input has fluid position and width, and autocomplete must follow it and there are a lot of relative positioning going on and many other things. It's really not a problem for my case in specific, since I can simply change the zIndex of my input after I create the autocomplete widget, but the ideal scenario would be allowing the developer to control the zIndex of the .ui-autocomplete.

Anyway, I think UI CSS, should be responsible for that and not the JS itself. But as well as you can't predict every scenario, I'm not predicting them all either, so in some other cases, zIndex on JS may make much more sense.

Based on your last comment, I'm not inclined to change this. We've tried several different ways of handling z-index. Setting a static value in the CSS based on the class didn't work out too well when we ran into use cases like autocompletes or datepickers inside dialogs.

I've got an idea for how to handle this more gracefully, but I haven't tested it to see if it will actually work. My plan is the have a class, such as .ui-front, which has a z-index on it. Anything in jQuery UI that needs to be layered would use this class. That alone doesn't actually get us anywhere, but if all of these elements also default to checking for ancestors with .ui-front and appending to them, then we can stay in the same stacking context. So if you've got an autocomplete on a text field which is just sitting on the page, there's no ancestor of .ui-front, so the menu gets appended to the body. But if the text field is in a dialog, which has .ui-front, then the menu gets appended to the dialog. In both cases, the menu element would also get the .ui-front class, giving it a z-index that brings it in front of the other elements in the dialog. All of these elements would still have an appendTo option that you can explicitly set to change the default behavior of searching for .ui-front ancestors. This would get us back to having the z-index set solely in CSS, but will hopefully avoid the pitfalls of static z-indexes and multiple stacking contexts.

If you're ok with what we've got today and the .ui-front idea seems reasonable to you, then I'd like to close this ticket as wontfix.

It makes sense that removing z-index would cause lots of issues with dialogue and other elements that may be positioned out of the default flow.

I like the idea of .ui-front. But it would be interesting to extend it a bit further to .ui-container, or something like that, which would be any ui element that has an absolute or relative position and may contain other ui elements. And any ui element would search for a .ui-container parent and append itself to that .ui-container instead of body.

That fixes some dynamic positioning issues. For instance, if we resize the window while a dialogue is open (with fixed width and margin auto), the dialogue changes position, but the autocomplete doesn't follow it, since its appended to body. If it was appended to that element, instead, it would follow the dialogue position.

On fluid layouts, these repositioning of elements is pretty constant. Thats quite an interesting case to study a bit further.

The dialog issue you mention is a bug. In general, you should only be interacting with one widget at a time. Elements that popup shouldn't stay active if you switch your context to another widget. As such, there's no reason for the autocomplete to stay open when you start resizing or draggaing the dialog that it's contained in. There's a ticket for this somewhere...

I didn't mean to resize the dialog widget, but the browser window, instead. Cause when you have a dialog that uses margin:auto, it would change position when you resize the browser window, and if the input is inside that dialog and the autocomplete open and appended to body, it wouldn't follow its input position, and that .ui-front or .ui-container could fix not only fix the z-index issue, but this one either.