Response title
This is preview!
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. 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. 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. 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.
Also it would be nice to have the dialog be destroyed if the original DOM element is destroyedThis 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.
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.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
That's the majority of dialog, what's "the rest of the functionality?"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?
This already happens for all widgets.
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.I don't understand why you would be removing an open dialog. This isn't even easy to do accidentally.
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.That's just bad UX. You should really reconsider your design.
Consistency.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.
"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...That's the majority of dialog, what's "the rest of the functionality?"
© 2013 jQuery Foundation
Sponsored by and others.