[Bug 13583] New: A more practical and semantic use for DIALOG tag

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13583

           Summary: A more practical and semantic use for DIALOG tag
           Product: HTML WG
           Version: unspecified
          Platform: Other
               URL: http://www.w3.org/mid/CAKsv=29DiC3nb3=gcf5aM9vt2i-ZOM-
                    Xk7=kXotHDzAfSL0q-Q@mail.gmail.com
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: mike+html-wg-mailbot@w3.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


public-html-comments posting from: Chris Baker <chris.baker.gr@gmail.com>
http://www.w3.org/mid/CAKsv=29DiC3nb3=gcf5aM9vt2i-ZOM-Xk7=kXotHDzAfSL0q-Q@mail.gmail.com

In the current spec, the <dialog> tag was used to indicate a conversation or
chat log. This tag was removed for various reasons, some people still feel
it ought to be included. I am personally indifferent to this need (I
wouldn't have thought that chat logs in HTML documents are common enough to
warrant their own element group), but I am opposed to the semantics of the
term "dialog" being used to apply to chat logs and the like. To most in the
field, a "dialog" is an interactive or informative popup window element used
for notification and gathering contextual user input.

Currently, the need for such user interaction is provided for by external
javascript UI libraries or through the stock javascript
window.alert()/confirm()/prompt() methods. The standard javascript methods
are inconsistent in appearance between user agents and have the sometimes
unfortunate quality of being a blocking call (execution of script
non-optionally halts upon calling). The library-provided dialogs have the
advantage of using DOM elements and thus CSS for total control of the dialog
appearance, but have the drawback of not being ABLE to block when desired.
When you have such a clear and widespread need for an interface pattern and
two different approaches to providing that need, the dichotomy between what
developers *want* to do using either and what one *can* do with either
leaves a gap in functionality that is ripe for improvement. One should not
have to trade control of appearance just to get a blocking call, and
likewise one should not have to trade blocking just so you can style the
dialog in a manner consistent with the context in which it is being used.

In my view, there is a need for a semantic tag to wrap dialog interfaces to
provide a clear way to wrap, style, and address elements that will be used
for a specific utility. The content of a dialog box is not semantically a
SECTION, an ASIDE, or a DIV. Currently, however, most developers use DIV (or
ASIDE) tags to wrap such user prompts. My proposal on this score is
three-fold:
* bring back the <dialog> tag, but rather as a semantic tag for wrapping and
styling popup dialogs
* extend the existent javascript methods for user interaction to optionally
work with a given DOM element as the interface instead of the standard
OS-level window
* allow calls to standard javascript prompt methods to optionally and by
default block

Thus, we have:

window.prompt(message [, default=false, blocking=true ] )

....where message may be a string (use the default UI) or a DOM node (use
this as the UI instead). This also maintains backward compatibility.

The <dialog> tag could behave essentially like a <section> element with the
additional optional properties "dragable" and "modal":

<dialog id="areyousure" modal="true" draggable="true">
  <header>
    Dialog title
  <header>
  <p>
    Are you sure you want to do that?
  </p>
  <button>Yes</button>
  <button>No</button>
  <footer>
     Dialog footer
  </footer>
</dialog>

<script type="text/javascript">
  var d = document.getElementById('areyousure');

  // make a blocking call
  var result = window.prompt(d, false, true);

  // make a non-blocking call
  window.prompt(d, false, function (result) {
     alert('The result was '+result);
  });
</script>

http://www.whatwg.org/specs/web-apps/current-work/#user-prompts

I feel like the showModalDialog method is trying to achieve this, and I am
excited by the functionality brought to bear.  However, the need for
external files can bring a level of complexity to bear that might mitigate
any benefit; I'm still better served by using a javascript UI library. Given
the indisputable fact that user prompts are an ever-increasingly vital part
of modern web applications, it is astounding that we have to look outside
the core of HTML to find a flexible provider of this need and that even our
best bet is not able to offer a complete solution.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 August 2011 05:48:20 UTC