[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.
>
> .
>

Received on Monday, 27 June 2005 01:31:10 UTC