W3C home > Mailing lists > Public > www-forms@w3.org > November 2006

RE: The close action seems not quite right for portal scenarios

From: Klotz, Leigh <Leigh.Klotz@xerox.com>
Date: Wed, 1 Nov 2006 10:27:43 -0800
Message-ID: <E254B0A7E0268949ABFE5EA97B7D0CF40267F46E@usa7061ms01.na.xerox.net>
To: "Aaron Reed" <aaronr@us.ibm.com>, <www-forms@w3.org>

I think that we need an info event and a cancellable event with a
default action for document level closes.
These would parallel HTML4/JavaScript onunload and onbeforeunload.

The onunload JavaScript handler cannot be cancelled, so that makes it an
Perhaps call it document-unload XML event, or check with DOM3 for an
existing event?
An HTML4/JavaScript page can have an onunload handler to shut down
server-side resources.
It's not clear when to shut it all down completely, but the browsers
must have worked this out already since they do have these handlers.  We
just have no access to them from XML Events.

The onbeforeunload JavaScript handler can be cancelled, so that makes it
an event with a default action of closing the document.
Perhaps it would be the document-close XML event or check with DOM3 for
an existing event?
An HTML4/JavaScript can have an onbeforeunload handler to query the user
and either allow or cancel the event based directly on the users's
response.  The form of the dialog is fixed by the user agents in
We would probably use XForms 1.1 conditional @cancel operations to do
this, along with the XForms 1.1 confirm action.
We would need to work through the points of control to make sure that
the pieces (event handling, event cancellation, confirmation, @if,
@cancel) do provide the chain of control necessary to do this.

Received on Wednesday, 1 November 2006 18:28:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:54 UTC