W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2005

[whatwg] Re: modal and modeless windows

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Tue, 28 Jun 2005 14:15:36 -0400
Message-ID: <42C193C8.70505@earthlink.net>
Karl Pongratz wrote:
> Matthew Raymond wrote:
>>  Did it occur to anyone that this is all hostile to the user? You 
>>prevent the user from accessing controls for browser (buttons, menus, 
>>et cetera). You prevent the user from going to another domain. You 
>>block their access to an underlying window. This all smacks of "let's 
>>control the users, because the users are stupid".
> 
> I wouldn't call users stupid, I would call web browsers stupid if they 
> are not capable to let the user complete a task in the most productive 
> and logical manner.

    How do modal windows let a user complete a task in a more productive 
way than a non-modal window? If you had two identical windows, except 
one is modal and one isn't, how would they be function differently from 
one another if the user never bothers to click on the parent window? 
Being modal has nothing to do with the content of functionality of the 
new window, and has everything to do with preventing the user from 
interacting with the parent window, which is obviously not designed to 
be used while another window is up, or you wouldn't need the modal 
window in the first place.

    Now, consider an AJAX app, using the address example. In the main 
window, you have a list of addresses. This is the Address-List state. 
When you click on an item to edit it, the application switches to the 
Address-Edit state and changes the UI to reflect what you can do in this 
new state. You edit the fields, then press "save", "delete" or "cancel". 
The appropriate operation is performed, and the state returns to 
Address-List with the UI being dynamically changed accordingly. The UI 
is managed by AJAX rather than a series of web documents, so there's no 
browser history to worry about, and even if you do hit the back button 
or go to another URL, the state and other information can be stored on 
the server, so that when you go back to the web app, the state is 
completely restored. (Actually, thinking about it, you could use AJAX to 
fetch HTML and implant it into the current document to change the UI.)

> However, I thought we are talking about web 
> applications, or do you want start reading your newspaper within 
> Dreamweaver, a Color Picker or your File Manager? Is that what you 
> intend :-) ?

    (I'm not exactly sure what you mean, but I'll take a stab at it.)

    Why do we need a modal file dialog at all, especially in a browser? 
Browsers can view files and directories (see Internet Explorer), so 
what's the point. Just have "Open File..." take you to the system 
directory in the browser and add some associated panes for the directory 
tree, et cetera. Then you can open multiple files in tabs and still have 
the last directory I was on open.

>>>The case where you require modal windows may be rare, yet they are 
>>>extremely useful in those cases, I remember they are on the web 
>>>applications wish list at "Joel on software" as well, 
>>>http://www.joelonsoftware.com/oldnews/pages/June2004.html , section 
>>>Thursday, June 17, 2004.**
>>
>>   Yeah, but he really doesn't [say] why. I was hoping he'd have a use 
>>case in there somewhere...
> 
> Are you sure you need a more detailed use case?

    There isn't a use case at that URL, so far as I can tell.
Received on Tuesday, 28 June 2005 11:15:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:41 UTC