[whatwg] modal and modeless windows
karlhp at karlhp.com
Mon Jun 27 01:31:10 PDT 2005
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.
J. Graham wrote:
> On Sun, 26 Jun 2005, Karl Pongratz wrote:
> (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  you have to make _really_sure_ you don't
> allow them to break it anywhere else.
>  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.
More information about the whatwg