Continuing with the API redesign, we have some changes planned for the Dialog widget. We know that API changes like this are not without cost to our users, so we'd like to make it clear that except where specifically noted, jQuery UI Dialog in 1.9 will support the 1.8 API as well, and the deprecated APIs will not be removed until jQuery UI 2.0. Read more about the full jQuery UI API redesign.

API Redesign

Contain focus in dialog

We currently only contain focus inside modal dialogs. We will be changing this behavior to always contain focus, even in modeless dialogs. This will bring us more in line with the DHTML Style Guide. We're not sure about implementing a key command to move the focus out of the dialog (such as F6) since that would require defining a system to track where focus should move.

Allow disabling dialogs

Dialogs don't currently support being disabled. They do inherit the default behavior of adding the ui-state-disabled class, which makes the dialog look disabled, but the user can still interact with elements in the dialog. In order to support disabling a dialog, we will place a div over the dialog to prevent mouse interaction.

Ability to configure which element gains focus

When opening a dialog, we search for which elements are tabbable and we focus the first element that we find. If there are no tabbable elements, then we focus the dialog itself. We will be adding an autoFocus option, which will allow customizing which element gains focus. The option will accept a function which will return the element to focus. The default value for the option will be the current implementation. If no element is found using the option, the dialog will be focused.

Move dialog back to original DOM position on destroy

When dialogs are created they are moved to the end of the body. When dialogs are destroyed, they currently stay at the end of the body. We will be changing this behavior so the dialog is returned to the original position, if possible. This will be done by tracking either a sibling or the parent on create.

Automatic stacking

The stack option controls whether a dialog will move on top of other dialogs when it gains focus. Since this should always be the case, we will be removing the option and forcing the behavior. In addition, we will probably remove the moveToTop method since the proper dialog(s) should always be available to the user based on when they were opened and whether they are modal or modeless.

Saner modality

The current implementation for managing modal dialogs is a bit unwieldy, comparing the z-index of elements and often causing problems. We plan to simplify the implementation and switch to a hierarchy-based solution instead of a style-based solution.

Feedback

We'd love to hear your feedback on these changes. We want to make sure we address any issues the community may have before we finalize and implement these changes. If you have any feedback, please leave a comment here. Thanks.

Setting the default focus component is definitely an added bonus. Some other thoughts/feature enhancements:

1. Close-on-escape can be disabled via the API so it seems only natural that the API also provide a means by which to prevent the close button (in the upper right corner) from appearing - unless there was a different rationale for disabling the escape button.

2. Building on #1, both pieces of functionality arguably "cancel" the dialog and while they fire the right events in the API, there's no event fired specifically for cancelling out of a dialog. One needs to check to see if the escape button or close button was hit and then redirect flow (or mimic) to a cancel button function handler.

3. Finally, it would be really cool to see some stock dialogs (perhaps even extensible): Yes/No, Yes/No/Cancel, Save/Cancel. One could argue that these are VERY common functions.

2. It's fairly simple to track this with a flag that you clear on open and set in your own buttons. You could extend the dialog to have cancel functionality if you want, but that's not necessary to be in the core.

3. These may be common, but I don't know how you think these would be useful for us to provide. We can't possibly provide an API that's simpler than the buttons option as a hash. Unless you're asking for helper methods that create dialog singletons (created from text, auto destroy on close, etc), which is not something we will do.

Move dialog back to original DOM position on destroy is a great addition. Also it would be nice to have the dialog be destroyed if the original DOM element is destroyed (or closed if it happens to be a dialog). Of course calling all beforeClose handlers prior. This is important when you have "nested" non modal dialogs that should not exist if the parent dialog is closed. Also if each dialog knows what its parent is, it can dispatch the events properly. I have put some working code together for my project. It is simple.

Another thing - is how the buttons are created for the dialog. Right now the way the buttons are created in the buttons pane of the dialogs - user passes options that simply convert into the html attributes or elements of a button element. IMHO the buttons option should accept just the same list of options as the regular button uses to create itself: text, label, icons, disabled. But a regular button should accept also a click option to pass the click handler and an html template option which can be used to create a button markup in the dialog instead of just hardcoding <button type=button> in the _createButtons method

One more thing - is it useful to add a parent widget to dialog called "form"? Basically this could be a dialog less title bar and close button and all floating functionality ---- just the framing, formatting, dynamic resizing, and buttons panel. And then dialog wold just add the rest of the functionality on top?

Also it would be nice to have the dialog be destroyed if the original DOM element is destroyed

This already happens for all widgets.

(or closed if it happens to be a dialog). Of course calling all beforeClose handlers prior.

I don't understand why you would be removing an open dialog. This isn't even easy to do accidentally.

This is important when you have "nested" non modal dialogs that should not exist if the parent dialog is closed. Also if each dialog knows what its parent is, it can dispatch the events properly. I have put some working code together for my project. It is simple.

That's just bad UX. You should really reconsider your design.

Another thing - is how the buttons are created for the dialog. Right now the way the buttons are created in the buttons pane of the dialogs - user passes options that simply convert into the html attributes or elements of a button element. IMHO the buttons option should accept just the same list of options as the regular button uses to create itself: text, label, icons, disabled. But a regular button should accept also a click option to pass the click handler and an html template option which can be used to create a button markup in the dialog instead of just hardcoding <button type=button> in the _createButtons method

Why would you possibly want to limit what you have control over here? This is one of the very rare cases where having an infinitely large API has no conceptual overhead, no docs to dig through, and no difficult technical implementation.

As for using something other than a <button>, what is the use case?

One more thing - is it useful to add a parent widget to dialog called "form"? Basically this could be a dialog less title bar and close button and all floating functionality ---- just the framing, formatting, dynamic resizing, and buttons panel. And then dialog wold just add the rest of the functionality on top?

That's the majority of dialog, what's "the rest of the functionality?"

I don't understand why you would be removing an open dialog. This isn't even easy to do accidentally.

Maybe I did not explain this clearly enough. What I meant is the following. Each jquery UI widget is created as an object for an existing DOM element. If this DOM element or its parent element is removed using jquery methods, then the widget is removed too. This is also true if the parent element toggles its visibility mode, etc. Since jquery UI dialog node is taken out of its natural DOM tree and appended to body, the dialogs don't follow these patterns, and act independently of their original DOM locations.

That's just bad UX. You should really reconsider your design.

Quite honestly I don't see anything bad here. This is how it works everywhere else. You have dialog windows that may open other dialog windows, non-modal, so you can switch between them, but you can't close the parent dialog without evaluating if you can close the child dialogs first. To me a dialog can be as well a child object as any button or anything else. You will not probably have any arguments against removing a button that was a part of a dialog when the entire dialog is closed or destroyed? And again, if the dialog was not moved to body, this functionality would probably have come out of the box.

Why would you possibly want to limit what you have control over here? This is one of the very rare cases where having an infinitely large API has no conceptual overhead, no docs to dig through, and no difficult technical implementation.

Consistency.

All this API allows me - only to pass a markup, but does it is a very unusual way - by letting me send key-value pairs and converting these pairs into the html markup. The only exception is a "click" property which becomes a click event handler code. If I need to make this button simply a button with an icon, I would have to reverse engineer the main button widget to find out what do I need to pass in that key value pair in order to display that icon, or abandon the button panel and create something similar but using a standard way of creating these buttons.

Regarding the <button> - I might have preferences about the way the button is created, again, for look consistency, for some other reason, for an ability to pass the attributes in a straightforward way and not through a key value pair. To be able to create <button type="submit"> instead of type="button" in the end. May I ask you your own question: "Why would you possibly want to limit what you have control over here?"

Update: Just realized that Dialog was in the jQuery UI before Button was added to the bundle and the buttons option implementation in Dialog just reflects the way it was done back then.

That's the majority of dialog, what's "the rest of the functionality?"

"The rest of the functionality" is draggable, title bar, shadows, modal, etc. Essentially the idea is that the dialog almost always is a form that has learned how to float, obtained a nice frame and a title bar, and can become modal. Maybe all I wanted in the "form" widget is a button panel and consistent css classes from a dialog widget...

I realize that this may be a bit late in the day, but could there be some simple means for specifying (in options) the required inner dimensions of the dialog box?

Scenario 1 :I have a page containing a number of links to 'example pages', each link actually opening that 'example page' in a dialog box containing an iframe 700x400px (which is what the example pages are crafted for).The page also has a UI Theme selector, so any theme could be in use at the time.Problem is, I can't just tell the dialog to open at width 700px and height 400px because the iframe won't then fit the available inner space of the dialog.

Scenario 2 :I have a 'large' image of known dimensions that I want to display within a dialog when the visitor clicks a certain link/thumbnail on my page.Once again, I can't open just the dialog with the image's dimensions and leave it at that, because the image won't fit within the dialog.

In these cases I have had to override/extend dialog with my own version that does a 2-stage open, hiding the first stage, calculating the actual width/height options I need to set based on discovered inner dimensions, resizing the dialog, then eventually showing it. Having to maintain my own version becomes a bit a of pain when it comes to UI version updates.I'm not unaware of the need to be able limit the dialog box based on external dimensions, but I also think that mine is not a unique situation. After all, the dialog's purpose is to display content, and if the size of the content is known then is it unreasonable to expect the dialog to be able to handle that from the outset?

I have tried to modify the jQuery Dialog widget as I added a minimize button of the DialogTitlebar in order to add a minimize functionality of the dialog widget. You can see the demo here and the problem I have is following:

When dialog is shown and I hit the minimize button the dialog act normally it changes its height and is minimized successfully. But when I resize it (even a little) and hit the minimize button again the content of the dialog disappears but the height of the dialog stays the same. Where I go wrong ?

I will kindly ask you if someone has some fix of the bug to email me at 4okito@gmail.com ! Thanks in advance

Thanks for your immediate answer David, but I am afraid that you have misunderstood me. I don't want to hide the titlebar or close button. As a matter of fact just opposite I want to create a new alternate button (next to the close button on the titlebar) which will fire an entire new functionality of the dialog widget respectively - minimizing (hiding the dialog body as long as showing only the dialog titlebar) and maximizing (showing the dialog body). You can see what I mean on this link. I want kindly to ask some of the jQueryUI team to post an opinion