- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Aug 2011 05:48:14 +0000
- To: public-html@w3.org
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 on the CC list for the bug.
Received on Wednesday, 3 August 2011 05:48:19 UTC