[whatwg] showModalDialog

[Matthew Raymond]

Hallvord Reiar Michaelsen Steen wrote:
> On 1 Jul 2005 at 13:27, Karl Pongratz wrote:
>>>click "edit" in my fancy address book application, a modal window pops
>>>up, I want to go to the tab where my E-mail lives to copy the address I
>>>wanted to put in my address book and ... ouch, can't get to the E-mail
>>>because I use an integrated browser/mail client application and the modal
>>>dialog blocks access to all the tabs.
>> 
>>If you want to copy an email address you will have a problem with any web
>>app I think, traditional and Ajax based once.
> 
> Perhaps you misunderstood that? I as a user expect to be able to 
> switch between tabs to copy and paste information between different 
> pages. A modal dialog breaks that.

    Yeah, and I can't really see a way around that. If you can change 
the z-order so that the parent window is above the child, you've already 
violated one standard UI convention regarding modal windows. So even if 
the modal nature of the dialog only applied to the HTML viewing area, 
back/next buttons and the address bar (and bookmarks, et cetera), which 
violates UI conventions right there, you'd still have the z-order 
issues. So the simplest way to go is to have chromeless windows instead 
of modal ones.

    However, in the scenario where chromeless windows are permitted, we 
still have to deal with tricks involving simulated chrome designed to 
trick the user and other stuff. We definitely need to decide how to 
handle chromeless windows.

>>If you want to do that in a
>>nice way you may need to use at least chromeless windows, yet you could
>>use modal windows from the already opened chromeless windows, then you can
>>access your main page even if a modal window is active.
> 
> I see, you expect your app to live in a window of its own and not in 
> a tab. Only to get rid of browser UI like back button and address 
> bar? 
> LOL, I'm your web app's user from hell, I routinely duplicate windows 
> to go back in history and see what I wrote and if I use IE and you 
> open a poup without address bar I view properties and copy the 
> address just to get my normal UI back. I know it is hard to keep up 
> with such behaviour from the backend, but I expect your app to 
> manage.

    Thank you. It's important to point out that users may not be using 
chrome by accident. This is what I meant by "user hostile" in previous 
messages. Modal dialogs block access to the UI that the user needs to 
control the browser. The whole point is to limit user control so that 
your application doesn't need to be as robust and doesn't have to deal 
with multiple input scenarios. If the user MUST do something a specific 
way, then you don't have to write code for any other way the user might 
try to accomplish the task. It's shifting part of the cost of 
development from the developer to the user.

> Is it possible to keep the two discussions chromeless windows and 
> modal dialogs separate, please?

    If you're talking about modal dialogs, chromeless windows have to 
come up because modal dialogs must be chromeless. However, the modal 
conversation can be put on hold until we figure out whether chromeless 
windows are acceptable in one form or another.