Re: [whatwg] showModalDialog
Hallvord Reiar Michaelsen Steen wrote: On 1 Jul 2005 at 11:44, Sanghyeon Seo wrote: Concerning recent thread about modal and modeless windows, did anyone mention showModalDialog already? http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/showmodaldialog.asp I believe this functionality does come in handy in some cases. Microsoft wouldn't have implemented it if there wasn't any demand? One of the reasons why modal popup-windows are a very bad feature in a browser is that, unlike a desktop application, you don't really know what other pages you prevent the user from accessing by throwing up a modal dialog. To go with the address book example from the previous thread: I 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. 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 don't think showModalDialog should be in WHAT's spec. Yep, Xforms may be more interesting, yet the web browser should handle at a minimum chromeless windows and if possible modal windows (in os chrome). I think current DHTML/AJAX tricks offer adequate solutions for modal dialogs. I don't think that DHTML and AJAX are the holy grail and offer a solution to just everything. AJAX i.e. breaks the traditional browsing model (and I do certainly not understand why nobody complains in this case!), among others. No doubt that DHTML and AJAX offers some great hacks, but be careful where and how you use them. Beside that, someone of the Xforms fellows has written a blog story that it can be a bit of an overhead to develop and maintain a DHTML/AJAX app compared to Xforms, and I think he is right, though I don't find the link right now.
Re: [whatwg] Re: modal and modeless windows
Matthew Raymond wrote: Karl Pongratz wrote: Matthew Raymond wrote: So I ask you, for this example, where is the benefit of modal windows? I am using the current approach you describe, and as long as you have only a single additional window (the edit form) open it wouldn't be a problem, except if you want the user to explicitly complete a task, then modal would be required. I'm going to be lazy and ask you to provide the use case, since you're the one claiming one exists in the first place. In case of the addresses modal may not be required, it depends if you want to allow the user to delete a contact while the same contact is open in the edit form. Simple way around that. Put the delete button in the editing window. It probably wont harm something in this case but it may in others. /me coughs in a manner that sounds very much like the words use case. The problem starts in the edit form, if you want yet to open another window, lets say you want to attach a file to the address which is opened in the edit window, within the opened edit window you open a HTML File Manager. So you have 3 windows open, the address view in the main web browser window, the edit form in a new window (without chrome) Every indication is that chromeless windows are on their way out. I would be very sad if that would happen. Its currently the only way to keep forms out of history and to unlock them from the back/next button. So I would suggest to keep them and improve them rather than removing them. and the File Manager in another new window (without chrome). Wouldn't you use at least a modal window in case when you open the File Manager, if modal Windows would exist? Assuming the address can only be deleted by opening it in an address editing window and pressing delete, you have no use case in this situation, since the address can't be deleted until you return from the file manager. I would consider that this might be a problem in other situations, but I wonder if there aren't simple workarounds for it. The File Manager is just one case, I face this problem many times where for an external edit form it would be convenient to open a modal sub window. So your use case for modal windows is that there are many convenient situations where you'd want to open a modal window... So, Xforms may be a solution in that case if you don't require being the first window you open to be modal. By the way, I am simulating modal windows within the edit forms I use, but it is definitely a dirty hack to simulate multi web browser and multi os modal windows. Yeah, hacks like this run the risk of conflicting with native UI conventions, I'll give you that. However, it is widely accepted that modal UI is to be avoided anyway. I have no objection to avoid them if they are not really required. Though what doing in the rare cases where you can't avoid them, I guess Apple applications are still using modal windows in the one or other case, and they will remain for another decade or two. Or is it different? .
Re: [whatwg] Re: modal and modeless windows
James Graham wrote: Karl Pongratz wrote: Matthew Raymond wrote: Every indication is that chromeless windows are on their way out. I would be very sad if that would happen. Its currently the only way to keep forms out of history and to unlock them from the back/next button. So I would suggest to keep them and improve them rather than removing them. Well if you can think of an easy way to improve them so that they a) obviously belong to the browser and b) clearly display the full location then I'm sure UA vendors will be happy to hear from you. Otherwise, the internet being the way it is, chromeless windows, on the public internet at least, have a short life expectancy. Yep, I would be very happy with this approach, to lock chromeless windows to the user agent and to always show the full location, and that you can't connect to another domain than of the domain from where you opened the window. This modification shouldn't be that difficult to implement for user agent vendors, I think... and hope. As far as I remember the domain restriction already exists. So, Xforms may be a solution in that case if you don't require being the first window you open to be modal. By the way, I am simulating modal windows within the edit forms I use, but it is definitely a dirty hack to simulate multi web browser and multi os modal windows. Yeah, hacks like this run the risk of conflicting with native UI conventions, I'll give you that. However, it is widely accepted that modal UI is to be avoided anyway. I have no objection to avoid them if they are not really required. Though what doing in the rare cases where you can't avoid them, I guess Apple applications are still using modal windows in the one or other case, and they will remain for another decade or two. Or is it different? It seems to me that two different issues have been conflated here: modal windows (those which prevent their parent window from being focused) and chromeless/navigationless windows. Whilst there are a very few occasions in which I can see modal windows being useful I can also imagine that they would be abused for all sorts of nasty things (even more instrusive adverts, for example). 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.** Yep, I am afraid that modal windows would be abused, as many other things, though I consider some content you find on the web much more harmful than modal windows could ever be, yet you allow authors to publish content on the web :-). Thinking more about it, in my case I would require the modal windows on already opened chromeless windows, that could be a solution, limiting the use of modal windows to already opened chromeless windows, so that you can't open a modal window right away from a regular web browser window, that would make it much more difficult to abuse them. That is something I would be happy with and may cover most use cases where modal windows are required.
Re: [whatwg] Re: modal and modeless windows
Matthew Raymond wrote: Karl Pongratz wrote: James Graham wrote: Karl Pongratz wrote: Matthew Raymond wrote: Every indication is that chromeless windows are on their way out. I would be very sad if that would happen. Its currently the only way to keep forms out of history and to unlock them from the back/next button. So I would suggest to keep them and improve them rather than removing them. Well if you can think of an easy way to improve them so that they a) obviously belong to the browser and b) clearly display the full location then I'm sure UA vendors will be happy to hear from you. Otherwise, the internet being the way it is, chromeless windows, on the public internet at least, have a short life expectancy. Yep, I would be very happy with this approach, to lock chromeless windows to the user agent and to always show the full location, and that you can't connect to another domain than of the domain from where you opened the window. This modification shouldn't be that difficult to implement for user agent vendors, I think... and hope. As far as I remember the domain restriction already exists. 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. 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 have no objection to avoid them if they are not really required. Though what doing in the rare cases where you can't avoid them, I guess Apple applications are still using modal windows in the one or other case, and they will remain for another decade or two. Or is it different? It seems to me that two different issues have been conflated here: modal windows (those which prevent their parent window from being focused) and chromeless/navigationless windows. Whilst there are a very few occasions in which I can see modal windows being useful I can also imagine that they would be abused for all sorts of nasty things (even more instrusive adverts, for example). 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 way why. I was hoping he'd have a use case in there somewhere... Are you sure you need a more detailed use case? Yep, I am afraid that modal windows would be abused, as many other things, though I consider some content you find on the web much more harmful than modal windows could ever be, yet you allow authors to publish content on the web :-). Thinking more about it, in my case I would require the modal windows on already opened chromeless windows, that could be a solution, limiting the use of modal windows to already opened chromeless windows, so that you can't open a modal window right away from a regular web browser window, that would make it much more difficult to abuse them. That is something I would be happy with and may cover most use cases where modal windows are required. Congratulations. You just reinvented xul:dialog. :) Seriously, though, why not just standardize a subset of XUL (sXUL) and use a compound document (XHTML + sXUL). We could make sXUL the standard for browser extensions while we're at it. Pardon, there isn't much I know about Mozilla XUL in detail, XUL always sounded interesting, though as only Mozilla supports XUL ... .
Re: [whatwg] Re: modal and modeless windows
Matthew Raymond wrote: 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. Thanks for explaining what a modal window is. 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.) Let's take again the Wizard example, I think we had it already. I don't want to do the overhead to start synchronizing the client and server state, and I do not understand what sense it makes to have duplicate Back and Next buttons, one pair in the web browser and another pair inside the wizard. And, there is no need to restore the state, why should I do this overhead, open the wizard in a new window, and complete it. Though, we said that the wizard is not modal, but in a chromless window. 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. Take the wizard I mentioned above, in a chromeless window. Within the Wizard you need a.) to open a File Manager and b.) to open a Color Picker and c.) to open a Subform (due to the complexity of the Wizard) The Local File Manager doesn't work in my case, in case that it works for you, there is still b.) and c.) Of course I could just open another chromeless window but if I remember correct modal windows were invented to handle this cases. Anything wrong to use modal windows in a.), b.) and c.)? 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. I think the above wizard example makes it clear why chromeless modeless and modal windows have there advantage. If that doesn't make it clear I am afraid that you don't want to understand and I am just wasting my time. .
Re: [whatwg] modal and modeless windows
James, Sorry that I called you Graham :-). You distinguish between the two that a modal or a modeless window is something entirely different of what is the current browser window, so its not a window, it is a modal_window or a modeless_window. If you currently click on a link for a new html document you could open it in the same window, in a new window or in a new tab. This shouldn't be possible with modal or with modeless windows, the link for such windows should indicate that it is modal or modeless and will always open as new window, preferably without chrome. This way you don't break the browser back/next button in you web browser. So, all remains the same, except if you open a modal or a modeless window. The phishing scams problem. a.) Always indicate the URI in a status bar, which can't be disabled. Though the URI shouldn't be editable, only indicate it. b.) Don't allow to open modal/modeless windows from HTML email. c.) Only allow to connect the modal/modeless window to the same domain as of the document from where you opened the modal/modeless window. I.e. if you click a link on http://www.whatwg.org and you open a modal window, then the content in the modal window can only be loaded from http://www.whatwg/org/modal_1.htm, it wouldn't be possible to establish a connection to a different domain, i.e. to http://www.ufo.com/modal_1.htm. Proving a simple, fixed, navigational paradigm isn't out of date, it's essential to the usability of the web. I don't think it breaks something because you don't touch the web browser back/next button in window, it only doesn't exist in modal/modeless windows, which are different from window. is the WHATWG mailing list subscription form an example of a document or of an app? I would say its a mini app, and the approach you use now, to browse to it, is legal, though I use it as the most trivial example. Let's take the subscription page in case that we would have a modal window. You would still browse to the subscription page, though it wouldn't have any form field on it, instead there is a link Click here to subscribe, clicking on it opens a modal window (smaller than the main window), which contains the form fields for the subscription. Fill in the form, submit it, show some Thank you for your subscription, that's it, then close the window manually. You may not want to do that for very simple forms like a subscription page, but it becomes very handy for complex forms where you use a lot of DHTML, AJAX, Xforms or whatsoever. As far as I know, AJAX applications break your web browser history, though if you do the complex AJAX part, let's say a complex Wizard, inside a modal window then it wont break you web browser history, and you wont have pages in your web browser history which shouldn't be there anyway. Karl J. Graham wrote: On Sun, 26 Jun 2005, Karl Pongratz wrote: Graham, (James actually :) ) My point is, you can browse web documents, but you can't browse web applications, the browsing model is out of date. How do you distinguish the two? If we agree (we may not, I don't think you mentioned this) that it's undesirable to let web sites disable features such as the back button (and, because of phishing scams, this is certainly the direction that UA vendors are moving in - for example chromeless windows are likely to become extinct in the near future) there needs to be a way to distinguish between a web site and a (trustworthy) web app - is the WHATWG mailing list subscription form an example of a document or of an app? You can certianly browse to it and away from it but it has some app-like functionality. If we let that page disable the back button presumably there'll be no way to stop any other site from doing so and we'll suffer all the UI problems I previously described. Proving a simple, fixed, navigational paradigm isn't out of date, it's essential to the usability of the web. If you want to introduce technology that allows authors to break that model in situations where the it doesn't make sense [1] you have to make _really_sure_ you don't allow them to break it anywhere else. [1] These are rarer than people believe - in general you should try to write applications that can deal with the back button and other browser-provided navigation, rather than break when it is used. .
Re: [whatwg] modal and modeless windows
James Graham wrote: Matthew Raymond wrote: Karl Pongratz wrote: Let's take the subscription page in case that we would have a modal window. You would still browse to the subscription page, though it wouldn't have any form field on it, instead there is a link Click here to subscribe, clicking on it opens a modal window (smaller than the main window), which contains the form fields for the subscription. Fill in the form, submit it, show some Thank you for your subscription, that's it, then close the window manually. You may not want to do that for very simple forms like a subscription page, but it becomes very handy for complex forms where you use a lot of DHTML, AJAX, Xforms or whatsoever. As far as I know, AJAX applications break your web browser history, though if you do the complex AJAX part, let's say a complex Wizard, inside a modal window then it wont break you web browser history, and you wont have pages in your web browser history which shouldn't be there anyway. If you have AJAX, why not submit form data via XMLHttpRequest rather than changing the current URL? That way, there is no back button within the context of navigating the application. Indeed, that seems like a reasonable solution that doesn't require multiple types of window (and fits the general HTTP model quite well since a single web-app can be seen as a single resource accessible through a single URL). There are various other pieces of technology in the spec that make this sort of thing even easier (server-sent DOM events, for example, so a system for the server to push data to the client as necessary is easy to set up). Of course all this javascript the downside that accessibility is hard to get right. Well, if you have a Wizard with 6 steps done by AJAX, how do you explain to the user that he/she can't anymore use the web browser back/next button to navigate through the Wizard? Imagine you are at Wizard step 6, have filled in a ton of form fields and accidentally click the web browser back button, it will lead you somewhere, maybe to a resource you have visited before the Wizard resource. Does that sound as a logical browsing model which a user will ever understand? Beside that, how many desktop applications do you know which don't use modal and modeless windows? I know many without a back/next button, but none without modal window support comes into my mind. Is the web browser damned to limit it to back/next only? Will the only alternative be Java Webstart, Microsofts XAML or Flash to get a desktop like user interaction model? Karl
[whatwg] Re: modal and modeless windows
Mark, I appreciate that Xforms supports modal and modeless messages, yet I miss it in the web browser. I could envision that as follows, lets take the address book of Microsoft Outlook, the desktop application, as an example. You have a page (resource) my_addresses.html, a simple document that shows you all your addresses without any form fields. If you want to edit an address you click on it, which will open a modal window, this modal window should then contain the xforms document to edit the address, with a Save and Close and Cancel button. Cancel will close the modal window, no other action is taken. Save and Close will save the form data, closes the modal window and it will update the changes in the underlying my_addresses.html document, i.e. by reloading it. You can do the same without modal windows, the traditional approach, see i.e. Views and Forms: Principles of Task Flow for Web Applications Part 1 (Bob Baxley) http://www.boxesandarrows.com/archives/views_and_forms_principles_of_task_flow_for_web_applications_part_1.php Though I believe the modal window approach would be much cleaner and saver, maybe Bob Baxley would have chosen that way, if modal windows existed. Karl Mark Birbeck wrote: Karl, [I'm not on the WhatWG list, so this will probably bounce.] I had a short look at the webforms and web applications specification at whatwg.org, I didn't find anything about modal and modeless windows. If there is anything to improve for html, xhtml, xforms and compound documents, then, in my opinion, the first missing feature that comes into my mind is the lack of modal and modeless windows. XForms does already have modal and modeless messages, and I know that both X-Smiles and formsPlayer have implemented them in such a way that the message itself can contain other form controls. (I don't know about other implementations, but my guess is they probably do, too.) In other words, you can have a little sub-form that updates the main instance data, but appears to the user as a separate 'window'. The only difference then between modal messages and modeless ones are that modal messages block execution until they have been closed, whilst modeless ones can happily sit on top of the main form. Note also that once again we get a much better model in XForms, since actually what we are talking about is the behaviour of an abstract concept -- a 'message' -- which will act differently on different platforms. We don't say use some method call on the document or window object, as we have to do in current solutions, but which is very difficult to make accessible. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: [EMAIL PROTECTED] t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/ .
Re: [whatwg] Re: modal and modeless windows
Matthew Raymond wrote: Karl Pongratz wrote: I could envision that as follows, lets take the address book of Microsoft Outlook, the desktop application, as an example. You have a page (resource) my_addresses.html, a simple document that shows you all your addresses without any form fields. If you want to edit an address you click on it, which will open a modal window, this modal window should then contain the xforms document to edit the address, with a Save and Close and Cancel button. Cancel will close the modal window, no other action is taken. Save and Close will save the form data, closes the modal window and it will update the changes in the underlying my_addresses.html document, i.e. by reloading it. Where do you need modal windows in this model? Someone clicks on the edit link to bring up an address editing page in a new window. You edit, then click save or cancel, which closes the window. AJAX and server-sent DOM events update the original window when you save. If the address is deleted or altered, server-sent DOM events can update the editing window to act accordingly. (In the event of a deletion, for instance, the editing window could change to a simple page saying This address has been deleted.) Since the dialog is not modal, you can edit multiple addresses at the same time, and you can even do so while the buddy you're sharing the address book with is editing it. As far as links go, the newly created address editing windows don't have a previous window because they were just spawned, and if they don't need links to load inside the window, then don't put any or have them spawn new windows. So I ask you, for this example, where is the benefit of modal windows? I am using the current approach you describe, and as long as you have only a single additional window (the edit form) open it wouldn't be a problem, except if you want the user to explicitly complete a task, then modal would be required. In case of the addresses modal may not be required, it depends if you want to allow the user to delete a contact while the same contact is open in the edit form. It probably wont harm something in this case but it may in others. The problem starts in the edit form, if you want yet to open another window, lets say you want to attach a file to the address which is opened in the edit window, within the opened edit window you open a HTML File Manager. So you have 3 windows open, the address view in the main web browser window, the edit form in a new window (without chrome) and the File Manager in another new window (without chrome). Wouldn't you use at least a modal window in case when you open the File Manager, if modal Windows would exist? The File Manager is just one case, I face this problem many times where for an external edit form it would be convenient to open a modal sub window. So, Xforms may be a solution in that case if you don't require being the first window you open to be modal. By the way, I am simulating modal windows within the edit forms I use, but it is definitely a dirty hack to simulate multi web browser and multi os modal windows.
[whatwg] modal and modeless windows
I had a short look at the webforms and web applications specification at whatwg.org, I didn't find anything about modal and modeless windows. If there is anything to improve for html, xhtml, xforms and compound documents, then, in my opinion, the first missing feature that comes into my mind is the lack of modal and modeless windows. I believe that the current internet web browsing model doesn't work for web applications, the most simple example is to subscribe to the whatwg.org mailing list, that you can i.e. return to the subscription page via the web browser back button. The example is very simple, though can someone tell me why I should want, respectively why I am allowed to return to a form page I just submitted, does that make any sense? That's where most problems start in regard to web applications, this is not the only problem, but probably one of the most significant once, the browsing model. Can we change the browsing model? I think yes, by introducing modal and modeless windows, view documents by using the traditional browsing model, but anything else, manipulating data and form submission, would be done in modal windows, and more. Well, its not that simple, it may require to modify the caching model and other parts as well, however, I consider them as the primer for anything else. Any comments, does anybody know if this issue is somewhere addressed, discussed? Thanks Karl
Re: [whatwg] modal and modeless windows
Graham, I have no objection to use forms via the browser back button if it is useful, I think Google or Yahoo search are typical examples as well. Though I am talking about applications where it is harmful or where it doesn't make sense to display the form again or to access it via the web browser history. So should I allow it just because it is useful in some other cases? That doesn't work for me, simply said, something is wrong and needs to be fixed. I am using pseudo modal windows for data manipulation in a lot of cases (DHTML wizards, etc run in pseudo modal mode), though they are pseudo because I jut open a new window without the chrome, I didn't have a single user which had any problem with it, though I remember one single user which didn't know about the web browser back button :-). By the way, I don't break the web browser button on the regular main browser window, I simply don't use them in the opened pseudo modal windows if it is not necessary, respectively if it could harm something. My point is, you can browse web documents, but you can't browse web applications, the browsing model is out of date. Karl J. Graham wrote: On Sun, 26 Jun 2005, Karl Pongratz wrote: can someone tell me why I should want, respectively why I am allowed to return to a form page I just submitted, does that make any sense? In order: You might want to return to the form page to submit the form with different details. A typical example of this would be a rail timetable application where returning to the form page would allow adjustments to the journey without having to reenter the unchanged data. This is extremely common. You are allowed to return to the previous form page because a) it's more often useful than not and b) because allowing authors to mess about with the back button would cause more harm than good. The back button is widely understood (moreso than links and, especially, the location bar, for example) and therefore important in making the web usable. Unscrpulous authors would take advantage of the ability to disable the back button to prevent users from backing out of their sites. The user would have no clue why the back button worked on some sites but not on others. To improve the UI, browser makers would prevent the back button from being disabled (c.f. popup windows). That's where most problems start in regard to web applications, this is not the only problem, but probably one of the most significant once, the browsing model. Can we change the browsing model? I think yes, by introducing modal and modeless windows, view documents by using the traditional browsing model, but anything else, manipulating data and form submission, would be done in modal windows, and more. Well, its not that simple, it may require to modify the caching model and other parts as well, however, I consider them as the primer for anything else. Having different types of windows doesn't make much sense to me. If you want to do abusable things like disabling the back button (or reading local files or using chromeless windows or...) you need a way for a user to indicate that they trust you not to do anything evil. The most common way to do that at the moment is to run the application locally (although this clearly doesn't work - most spyware runs locally yet is evil) .
