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.