View
 

Dialog

Page history last edited by ajpiano 7 mos ago

 

type: widget

release: 1.5

status: in development

documentation: http://docs.jquery.com/UI/Dialog

demo: http://jqueryui.com/demos/dialog

  


 

1 - Description:

 

A dialog is an overlay that is typicaly used in a modal situation to provide a message that the user needs to acknowledge (N1), a decision that needs to be confirmed (N2) or a data entry workspace or wizard (N3). Overlays can also be non-modal, but confirmations and data entry dialogs are always modal in a typical application unless it is an inpector-style window.

 

There is an existing dialog widget in jQuery UI that will need some re-factoring and should leverage the new position utility and Buttons:

http://jqueryui.com/demos/dialog

http://docs.jquery.com/UI/Dialog

 

 


 

2 - Visual Design:

 

 


 

 

3 - Functional Specifications/Requirements:

 

Options/Methods/Events

  • options:
    • autoOpen (boolean, default: true)
      • when set to true, this is the equivalent of calling .dialog('open') immediately after initializing the dialog
    • bgiframe (boolean, default: false)
    • buttons (hash, default: {})
    • closeOnEscape (boolean, default: true)
      • when set to true, pressing escape while the dialog has focus will close the dialog
    • closeText (string, default: 'close')
      • text to be displayed for the close button
      • to be modified when UI fully supports i18n
    • dialogClass (string, default: null)
      • class to add to the dialog wrapper element
    • draggable (boolean, default: true) 
      • when set to true, the dialog is draggable by the titlebar
      • requires draggable plugin
    • height (pixel value or 'auto', default: 'auto')
    • maxHeight (pixel value, default: null)
      • maximum height allowed when the dialog is resizable
    • maxWidth (pixel value, default: null)
      • maximum width allowed when the dialog is resizable
    • minHeight (pixel value, default: 150)
      • minimum height allowed when the dialog is resizable
    • minWidth (pixel value, default: 150)
      • minimum width allowed when the dialog is resizable
    • modal (boolean, default: false)
      • when set to true, an overlay is placed over the document when the dialog is opened, preventing access to other elements on the page.
    • position (mixed, default: 'center')
      • define options
    • resizable (boolean or string, default: true)
      • accepts any valid resizable handle option value or true/false to enable/disable resizing
      • requires resizable plugin
    • stack (boolean, default: true)
      • when set to true, if multiple dialogs are open at the same time, they will stack stack on click/drag
    • width (pixel value, default: 300)
    • zIndex (integer, default: 1000)
  • methods:
    • close
      • closes the dialog, can be cancelled through the beforeclose event
    • destroy
      • destroys the dialog and reverts the element back to its original state
    • isOpen
      • determines if the dialog is currently open
    • moveToTop
      • moves the dialog to the front of all other dialogs
    • open
      • opens the dialog
  • events:
    • open (event type: dialogopen)
      • original event types: none
      • triggered immediately after the dialog opens
    • focus (event type: dialogfocus)
      • original event types: none
      • triggered when the dialog gains focus (opened, moveToTop is called, or titlebar is clicked)
    • beforeclose (event type: dialogbeforeclose)
      • original event types: click, keypress
      • triggered immediately before the dialog closes, returning false will prevent the dialog from closing
    • close (event type: dialogclose)
      • original event types: click, keypress
      • triggered immediately after the dialog closes
    • dragStart (event type: dialogdragStart)
      • original event types: dragstart (mousedown)
      • triggered immediately after the user starts dragging the dialog
    • drag (event type: dialogdrag)
      • original event types: drag (mousemove)
      • triggered repeatedly as the user drags the dialog
    • dragStop (event type: dialogdragStop)
      • original event types: dragstop (mouseup)
      • triggered immediately after the user stops dragging the dialog
    • resizeStart (event type: dialogresizeStart)
      • original event types: resizestart (mousedown)
      • triggered immediately after the user starts resizing the dialog
    • resize (event type: dialogresize)
      • original event types: resize (mousemove)
      • triggered repeatedly as the user resizes the dialog
    • resizeStop (event type: dialogresizeStop)
      • original event types: resizestop (mouseup)
      • triggered immediately after the user stops resizing the dialog

 

Specifications

  • the element that .dialog() is called on will become the content area of the dialog
    • a titlebar and button pane will be generated automatically based on the options
    • the content, titlebar and button pane will be wrapped in a generated div
    • all dialog interactions must be performed on the content element, not the generated wrapper
  • if the title option is null on init, the title attribute on the element that .dialog() was called on will be used
  • dialogs are placed at the end of the body on open to ensure proper display in IE
  • min/max width/height will be enforced for height: auto and for resizable dialogs
    • if height is not set to auto, height will override other inconsistent settings
  • the context of the functions for buttons will be the element that .dialog() was called on
  • pressing escape when a dialog has focus will close the dialog if closeOnEscape is set to true
  • the position option should not allow the titlebar to go outside of the viewport
  • the dialog will always be contained within the document when dragging
  • modal dialogs will prevent access to all elements not in the dialog
    • other dialogs opened after the modal dialog will still be accessible
  • returning false in the beforeclose callback will prevent the dialog from closing
  • focus will be set to the dialog on open
    • focus will be set on the first tabbable element in the content are or the first button in the button pane
    • if there are no tabbable elements, focus will be set on the dialog wrapper div
      • the wrapper div must have a tabindex of -1 to be focusable
        • this will not work in Safari <= 3, but will work in Safari 4
  • tabbing through elements will be contained within the dialog (including titlebar and button pane)
    • F6 will toggle focus between the dialog and the rest of the page
    • if there are multiple dialogs open, F6 should cycle between the dialogs and the page
  • calling open when the dialog is already open will result in no action being taken
  • calling close when the dialog is already closed will result in no action being taken

 

See DHTML style guide for dialogs.

 


 

4 - Markup & Style:

 

4.1 Initial markup examples

 

(Pre-enhanced HTML markup structure that will be transformed into the final widget. There may be multiple possible HTML markup options per widget: for example, for a slider, radiobuttons, inputs or selects could all be used. )

 

4.2 Recommended transformed HTML markup demo with html and css (live view of svn):

 

View Demo Page: http://jqueryui.com/demos/dialog

 

 

 

 

     (The HTML markup structure and classes that will be used by the scripts in the enhanced version) 

 

4.3 Markup & style browser QA status

 

As of 12/12/08, static markup for this widget renders correctly in the following browsers.  (Correct rendering = true to design, with only small differences across browsers owing to differences in support of rounded corners, and native OS form element and font rendering.)

 

Please update this list as more browsers / platforms are tested.

 

  XP          Vista      Mac 10.5
IE 6
     
IE 7      
IE 8 beta      
Firefox 2.0.0.18      
Firefox 3.0.4      
Safari 3.2      
Opera 9.1
     
Opera 9.62
     
Chrome 1.0      

 

 

 

 

 

 

 

 

 

 

 

 

 

    

4.4 Accessibility recommendation

 

(Detailed recommendations for ARIA, HTML markup, CSS and javascript that will contribute to universal access and full section 508 accessibility for screen readers, mobile devices and any other devices) 

 

Issues default:
  1. cannot (appear to be ableto) move or resize via the keyboard.
  2. close icon disappears when high contrast mode is enabled.
  3. dialog role not conveyed consistently.
  4. arialabelledby used but interaction mode (for JAWS is incorrect), so label and dialog text content not announced consistently.
  5. In JAWS users are informed they can use the spacebar to activate the x button, but this is not the case.
  6. frame present that is announced by JAWS, but has no user content, recommend adding role="presentation" and suitable title for older AT.
additional for modal:
  1. Not modal for AT (JAWS( users, can still interact with page content using the keyboard.

 

 

4.5 CSS & Theme

 

(Description of the CSS classes to be used for all states, how custom theming and Themeroller support will work.) 

 


 

5 - Latest version of plugin:

 

(Link to the latest version in the jQuery UI trunk here)

 


 

6 - Open issues being discussed

 

(Use this area to place things that we're hashing out like featuresand options we're not sure we should include, questions about how this fits into UI and relates to other widgets and utilities, known problems, whether features should be broken across multiple releases, etc.)

 


 

 

 

 

Comments (26)

profile picture

Scott González said

at 3:37 pm on Jan 17, 2009

should be able to specify ARIA role (dialog or alertdialog)

profile picture

Jonas Flint said

at 9:26 am on Feb 5, 2009

Not sure if this is the place to post this. But Richard and I were discussing templating for the dialog box, in which a user can configure some of their out putted html. So for example: if we wanted to change the title (instead of hardcoding the jqui core file) we would do this:

add a titleTemplate: '<div class="ui-dialog-title">{ dialog.title }</div>'
titleTemplate: '<h1 class="ui-dialog-title">{ dialog.title }</h1>'

This would allow more flexibility. I'm told there will be further discussion on this for the next release, and would be interested to be in that discussion.

profile picture

Bohdan Ganicky said

at 9:00 am on Oct 19, 2009

Hi all again,

I miss one thing a lot. It would be really nice to put something like .ui-dialog-focus class on actually focused dialog so we can easily hook our CSS to visually distinguish between focused and not focused dialogs. Now I have to use focus event on each dialog to add an appropriate class and it's not so comfortable.

What do you say? Can I make a request ticket for this? :)

profile picture

Scott González said

at 12:20 pm on Oct 19, 2009

Is this a common enough feature to add? This seems like it would be pretty easy to implement as an extension (outside of the core plugin).

profile picture

Richard D. Worth said

at 2:49 am on Oct 20, 2009

This doesn't seem common enough to me. The most common use case is for one dialog to be open at once. I agree with Scott this could be developed as an extension.

profile picture

sompylasar said

at 2:53 pm on Oct 26, 2009

Common usecase to have a form in one dialog and a confirmation message on submitting that form in another that would pop up. Example of such a form might be a grid row editing dialog.

profile picture

Bohdan Ganicky said

at 1:27 pm on Oct 19, 2009

Seems to me it could be pretty common feature. It would be nice to have it in dialog core so it could be supported in Themeroller for example.

profile picture

Benjamin Neau said

at 10:25 am on Oct 23, 2009

What about MDI RIA.. are there that uncommon?

Also, on the latest SVN version of jquery.ui.dialog.js, there is a spelling error (positon instead positIon) regarding the position option processing. Here's a quick patch:
373c373
< if (position && (typeof positon == "string" || typeof positon == "object")) {
---
> if (position && (typeof position == "string" || typeof position== "object")) {

profile picture

Richard D. Worth said

at 11:36 am on Oct 23, 2009

The point is not how uncommon MDI RIA is, it's how much less common it is than single. If it were more common than single (and I'm arguing that it's not), it might make sense to build something like this in. In any case this seems more of a window management feature to me, rather than a dialog feature.

profile picture

Bohdan Ganicky said

at 2:37 am on Oct 26, 2009

My point is, that we already have the "focus" state built-in, right? When I click the dialog, it's focused and I can work within it or close it by pressing ESC. Giving the dialog an appropriate class seems to be the next logical step. Moreover, there already are state classes in other jQuery UI widgets, so why not be consistent?

profile picture

Scott González said

at 6:52 am on Oct 26, 2009

This seems like a stretch for the semantic meaning that ui-state-focus has. The dialog itself doesn't usually have focus, it's an element within the dialog that has focus. There aren't any other UI plugins that use the focus state in the way you're describing.

profile picture

sompylasar said

at 2:50 pm on Oct 26, 2009

The class may be ui-state-active, not -focus, but IMO the idea is not so bad.

profile picture

sompylasar said

at 2:55 pm on Oct 26, 2009

Visually distinguishing active dialog will also help to provide feedback to where above said ESCape keypress will currently go.

profile picture

Bohdan Ganicky said

at 10:06 am on Oct 29, 2009

Well, from the user experience point of view the dialog is focused/active, no matter what element is really focused at the moment.

profile picture

kyprus said

at 11:31 am on Dec 25, 2009

I'm having a problem with a selectmenu inside a dialog. When the dialog is opened via a button the first time it is fine. dialogopen is fired and it works great. After closing and reopening the dialog, dialogopen is not called. I have isolated the problem to be when I destroy the select menu beforeclose of the dialog. Commenting that out fixes the dialogopen event.

/****** Load Data ******/
$("#dialog").bind("dialogopen", function(event, ui) {

alert("dialogopen called");

$.ajax({

async: false,
url: "**********",
dataType: "json",
success: function(data, status) {

$.each(data.items, function(element, item) {

$("#selectMenu").append("<option value='" + item+ "'>" + item + "</option>");
});
}
});

//Have to create select after all data has been inserted
$("#selectMenu").selectmenu({style: "dropdown"});
});

$("#dialog").bind("dialogbeforeclose", function(event, ui) {

$("#selectMenu").selectmenu("destroy");
});

profile picture

ezanker said

at 3:54 pm on Feb 24, 2010

I would like another option for specifying the element to which the dialog container will be appended. For ASP.Net programming we often need the dialog to remain within the FORM element in order for postbacks to work. The default should definitely remain BODY.

profile picture

Richard D. Worth said

at 4:03 pm on Feb 24, 2010

This was discussed here http://dev.jqueryui.com/ticket/2409 some time back. I'm not of so strong a mind I couldn't ever see us adding an appendTo option to dialog, but my take is, this option would allow you to create a dialog that could be obscured by other elements, which is against the design of the dialog widget. Doesn't mean it shouldn't be possible, but I'm satisfied for now having it be achieved by means of a work-around rather than a built-in option.

profile picture

Wichert Akkerman said

at 1:40 am on Feb 25, 2010

Is there any reason not to use the form itself as the dialog, or put the form inside the dialog? That is the pattern I've always used, and it works well.

profile picture

Richard D. Worth said

at 2:12 am on Feb 25, 2010

That's a good general solution, and one I recommend. The specific problem here (related to ASP.Net) is the form is created by ASP.Net and it contains all the controls on the page. It's not your traditional form. It's a framework wart.

profile picture

Wichert Akkerman said

at 2:28 am on Feb 25, 2010

In other words: jQuery does the right thing here, and this should be taken up with Microsoft :).

As a workaround it is always possible to move the dialog nodes in the DOM to another place after opening the dialog.

profile picture

ezanker said

at 9:52 am on Feb 25, 2010

It is easy enough to append the dialog container to the form after initializing the dialog. I can live with that.

profile picture

davidmpaz said

at 11:43 am on Apr 13, 2010

Hello, I've followed these thread on and I know from previous conversations that MDI like app, due to its uncommonness, is not in your priorities, also because it is not on the scope of a dialog plugin, but we have to admit that actually it is the best starting point so far. So since with the dialog plugin can be achieved easily a similar aproach, I would like to know how difficult could be to add another button, next to the close button for collapse the dialog similar to the functionality on http://github.com/idlesign/ist-ui-panel. I don't know how far is this from your plans and development ideas, neither if you will find attractive. I think that could be an initial approach (first steps) for other widget as the taskbar and to get closer to desktop like app, on the other side I would like to give users a way to edit data in multiple windows minimizing then at will to get extra space on the explorer window. I'm not an versed developer with jquery neither javascript but I have made some little variation on the dialog plugin to achieve the result desired, but the work is not as should be, no efects when resizing, etc... I don't know how to share the file here so if considered usefull give me directions.
thanks for listen, David

profile picture

Adam said

at 1:08 am on Apr 14, 2010

"focus will be set on the first tabbable element in the content are or the first button in the button pane"

Would it not be possible to have a selected option to buttons, with focus set to the first button that had selected=true (or the first button if no selected specified). I frequently find myself creating "Are you sure" type dialogs (or sometime others with more than two buttons) where I sometimes want to control which button has focus.

profile picture

sasquatch said

at 1:38 pm on May 17, 2010

Would it be nice to have optional buttons in the dialog title? To have an method to add icon buttons for actions like minimize, maximize for example.

profile picture

Scott González said

at 2:27 pm on May 17, 2010

You can easily do this after init by just appending the elements yourself. Adding an API for this won't actually make it much easier.

profile picture

sasquatch said

at 2:37 pm on May 17, 2010

Ok, that's right. But at least an maximize method would be nice. I found that maximize(fullscreen) method would be very useful.

You don't have permission to comment on this page.