A Dialog Widget

[petyosi]

Quite similar to the window, but missing some window specific behavior. We can use the react dialog as a reference implementation - https://github.com/telerik/kendo-react-dialog

[petyosi]

Items to take into consideration when deciding on the requirements:

http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback/suggestions/6858197-prevent-tabbing-out-of-a-modal-window (careful with this one, @gyoshev said it may break things)

http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback/suggestions/3214910-confirm-alert-widgets-or-window-widget-modes

[petyosi]

And this one too - http://kendoui-feedback.telerik.com/forums/127393-kendo-ui-feedback/suggestions/3214910-confirm-alert-widgets-or-window-widget-modes

[gyoshev]

Regarding the "prevent tabbing out" functionality, this generally breaks things when modal dialogs are opened within other modal dialogs. For example, if a dialog contains an editor widget, and tabbing out is prohibited, the user may not be able to use the editor dialogs to insert links. Letting users disable the handler that prevents tabbing out of the dialog is a good enough solution.

[petyosi]

Makes sense, mostly because of our popup implementation, which we have to take into account.

[yordanov]

Below is a preview of the different Dialog modes that cover the widget's basic use cases:

[nlazarov]

Dialog widget specification

Overview

The dialog widget is a modal popup that brings information to the user. It also provides actions through the action buttons to prompt the user for input or to ask for a decision. The component can also contain more complex UI elements that require the focus of the user.

The dialog widget is a subset of a window widget. Nevertheless it serves specific needs, thus it makes sense to have it as a standalone component. The most prominent difference is the added functionality for actions (buttons) at the bottom of the dialog.

Use cases

Here are some of the use cases that we will aim for with the dialog widget. In all cases the dialog is a modal popup.

Alert / confirm / prompt substitutions

Through the dialog widget the developer could open an equivalent of the browser's alert, confirm or prompt dialogs. The modality of the dialog in this case serves the purpose of preventing any input to other UI elements.

The only features that is not possible for this scenario is the ability to prevent the JS execution - something the browser dialogs do.

Customize actions

There are cases where the application should provide a number of options for the user.

Using the dialog widget the developer can define numerous action buttons that correspond to the various actions. Each action could have a custom handler that links to a specific application function.

This scenario correspond to the dialogs with multiple actions from the following post - https://github.com/telerik/kendo-ui-core/issues/1664#issuecomment-228718837

Rich-text content

Some use-cases are described in the following item telerik/kendo-ui-core#1695.

Developers should be able to add any UI elements in the content of the dialog. They should also be able to apply custom formatting and full customization of the title element. The difference between the two cases is that content could be made scrollable, while the title should not allow scrolling. The better option for larger titles would be to add ellipsis to denote excess content.

Functionality / Features / Properties

Title

Developers should be able to add text content as title of the Dialog. It should be possible to add formatting to the content.

{ title: "" }

Close button

The close button is used by the user to close the dialog. It is positioned at the top-right corner. Developers should be able to hide the close button.

{ closable: true }

Content

It should be possible to add any content in the content container of the dialog:

{ content: "" }

Action buttons

Action buttons provide specific interactivity for the dialog widget. They have text and action handler attached to them. It should be possible to define action buttons as primary. All buttons close the dialog as their last action. However this could be cancelable from the custom action handler.

{
    actions: [
        "Ok", //define action through button text only
        { text: "Action", action: function() {} } //define action options
        { text: "Primary", primary: true } //define primary action
    ]
}

Modality

By default dialogs are modal. This means that an overlay will be rendered behind the dialog, covering the whole page, making it inaccessible. There should be no way to navigate away from the dialog, except the designed approaches (close button or actions), both with mouse and keyboard.

We should trap the tab key on the keyboard from focusing any other element but the dialog itself. This could be done through JS by capturing keypress and traversing for all focusable elements in the dialog. If the last such element is focused, then the tab key should focus the first one from the list.

{ modal: true }

Animations

Animations should be used when the dialogs opens and closes. These animations should be as close to the window animations as possible. http://docs.telerik.com/kendo-ui/api/javascript/ui/window#configuration-animation

Predefined dialogs

The kendo suite should offer predefined dialogs that resemble the browser's built-in dialogs alert, confirm and prompt.

For prompt and confirm dialogs the Ok button should be primary.

We could expose method through the kendo object with the same names:

kendo.alert("String to alert"); kendo.confirm("Continue?"); kendo.prompt("enter value", "123"); //123 is the default value

There is not way to interrupt the current thread as the browser can, so we should simulate similar behavior with the confirm and prompt dialogs. The suggestion is to use Promises.

kendo.confirm("Continue?")
    .done(function() { console.log("Ok") })
    .fail(function() { console.log("Cancel") });

kendo.prompt("enter value")
    .done(function(value) { console.log(value); }).
    .fail(function() { console.log("Cancel") });

If a developer needs a reference to a predefined dialog, then we should expose a constructor:

var dialog = new kendo.ui.ConfirmDialog(options);

Events

initOpen

This event is raised the very first time the dialog opens. It is most useful when we want to do huge initialization of UI elements (grid, listview, treelist, etc.) only once during the lifetime of the dialog widget and not on every open event.

open

Raised every time the dialog is opened.

close

Raised when the dialog closes. Clicking an action in the dialog should provide data of the action clicked in the event handler parameter.

UI

HTML structure of the Dialog

<div class="k-dialog k-window">
    <span class="k-x-close">Close button (X)</span>
    <div class="k-window-titlebar k-header">
      <span class="k-dialog-title">Dialog Title</span>
    </div>
    <div class="k-content">Content container</div>
    <ul class="k-dialog-buttongroup">
      <li class="k-button">Button 1</li>
      <li class="k-button">Button 2</li>
    </ul>
  </div>

Inherited existing Kendo UI classes:

• k-window
• k-window-titlebar
• k-header
• k-content
• k-button

New classes:

• k-x-close
• k-dialog-title
• k-dialog-buttongroup

K-X-Close

Font icon X at the top right of the Dialog used for closing the Dialog window.

K-Dialog Title

Span used for styling the title text

K-Dialog-Buttongroup

A UL element containing a varying number of button LI elements styled by the k-button class.

Accessibility

Accessibility is an important part of the dialog widget. It is important to present the widget to people with disabilities as a real dialog with all its functionality and options.

The WAI-ARIA specification has discussed dialogs in great details.

WAI-ARIA attributes

Dialog container should have attribute role="dialog".

The action buttons container should have attribute role="toolbar".

Action buttons should have attributes role="button".

When modal all other content on the page should have attribute aria-hidden="true".

Predefined dialogs should have role="alertdialog".

Predefined dialogs should point to its content with the aria-describedby="#message" attribute.

Focus

Opening a dialog should focus the first focusable element in the content of the dialog. This is especially important for modal dialogs, because this will ensure correct tab functionality and will direct the assistive technology to the correct place on the page.

Closing the dialog should focus the last focused element before the dialog was opened.

Above requirements may not always be possible as a built-in functionality and we should investigate the options here.

For predefined dialogs focus should be moved to the first element of the form. For alert and confirm this is the Ok button, for prompt - the input.

Keyboard support

Esc key should close the dialog.

Enter and space keys should trigger the focused action and the close button if focused.

Developers should be able to assign keys to actions. It is not necessary to use the accesskey attribute, because browsers have different solutions. Better handle the keyboard ourselves.

Modality

A modal dialog should expose only its content to the screen reader. All other content should be marked with aria-hidden=”true” so that it is not read by the screen reader. This simulates the modality behavior for visually impaired users.

Tabbing

Since modal dialog is considered the only content on the page, keyboard navigation should be trapped within the dialog container when navigating with the Tab key. This means that when the last focusable element of the container is focused, the Tab key should go to the first focusable element. The same logic should apply for the first element and Shift+Tab key.

The close button element and all action button elements should have the same tab index as the dialog itself. This ensures sequential tabbing.

References

telerik/kendo-ui-core#1695 https://github.com/telerik/kendo-react-dialog

[spatarinski]

I have a question about the events, which are triggered after the close or open animation ends. The corresponding events in the window component are activate and deactivate. However I believe that these names are misleading. Are we able to come up with better ones. For example ready and hide or hidden.

[jlchereau]

Looks great although I am not sure about the buttons which are inconsistent with the following dialogs from the spreadsheet and the gantt widgets among others. Unless you intend to replace them, I suggest a consistent UI:

I also do not see any button icon and primary button (k-primary).

[yordanov]

@jlchereau Yes, these dialogs will receive an update once the new Dialog component is released.

Dialog action buttons will inherit the Button component styles for icons and primary state.

Silver theme preview:

[petyosi]

Implemented and available in the master branch

[Vasim-DigitalNexus]

Hello, on the demo page where is an example of the Media and Responsive mode? http://demos.telerik.com/kendo-ui/dialog/index

BTW: Excelent component!