Shropshire, Andrew A wrote:
> We need to standardize the standardization process... Never heard of
> WHATWG. I note that Microsoft isn't a participant. What
> page is it on?
WHATWG is the origin of the HTML5 spec. Is it now a joint effort with W3C.
You find the same spec at:
http://dev.w3.org
Shropshire, Andrew A wrote:
One could simply deprecate the onunload (but still support it) and
create a new version onDestroy that is called as well. Old apps won’t
know about onDestroy so it will be harmless and won’t break them. New
apps simply don’t need to implement onunload and will us
Shropshire, Andrew A wrote:
These pages deserve to be broken :)
That's true of most pages on the web if you apply that criterion. In
fact, I have yet to run into any real-life (not example, not testcase)
web page that wouldn't be true of.
Breaking sites like that is a non-starter for UAs,
r leaves a page due to
hitting the back button or typing in a URL or going to a favorite
2009/1/6 Shropshire, Andrew A
These pages deserve to be broken :)
Unfortunately, the user doesn't know that little fact. Instead it knows
that with IE6 or FF2 or Opera9.5 it worked, with the lates
2009/1/6 Shropshire, Andrew A
>
> These pages deserve to be broken :)
>
Unfortunately, the user doesn't know that little fact. Instead it knows that
with IE6 or FF2 or Opera9.5 it worked, with the latest browser it doesn't.
And will complain with the browser vendor, and will keep the old browser
#x27;Boris Zbarsky'
Cc: public-webapps@w3.org
Subject: RE: Proposal: Detecting when the user leaves a page due to
hitting the back button or typing in a URL or going to a favorite
Shropshire, Andrew A wrote:
> 1. Allow the unload event to be cancelled. This could be
> done in a way
These pages deserve to be broken :)
-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Sent: Tuesday, January 06, 2009 12:29 PM
To: Shropshire, Andrew A
Cc: Mike Wilson; public-webapps@w3.org
Subject: Re: Proposal: Detecting when the user leaves a page due to
hitting the
Shropshire, Andrew A wrote:
For those that don't, making the unload event cancellable won't break
anything (it won't be fired multiple times because the first time it's
fired is the last for the page because it gets unloaded on the first
fire since these existing web apps don't know that it can
Cc: Mike Wilson; public-webapps@w3.org
Subject: Re: Proposal: Detecting when the user leaves a page due to
hitting the back button or typing in a URL or going to a favorite
Shropshire, Andrew A wrote:
> It would appear that there are countless ways to crash the browser
> and/or lose navigati
Shropshire, Andrew A wrote:
> 1. Allow the unload event to be cancelled. This could be
> done in a way consistent with other cancellable events
I'll reiterate what Boris has said, and I think most will
agree:
There is already an event for cancelling "leaving the page"
and that is the beforeun
Shropshire, Andrew A wrote:
It would appear that there are countless ways to crash the browser
and/or lose navigation history
Depends on the browser. If your browser allows web pages to do this,
either complain to the vendor or vote with your feet and switch to a
better browser. ;)
2. A
Shropshire, Andrew A wrote:
One use case for this is to customize the text in the dialog. For
example, right now the developer is forced to use "Are you sure you want
to navigate away from this page? ... Press OK to continue, or Cancel to
stay on the current page."
>
This doesn't make sense i
ed an onunload() event.
Andrew
-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Sent: Monday, January 05, 2009 3:05 PM
To: Shropshire, Andrew A
Cc: Mike Wilson; public-webapps@w3.org
Subject: Re: Proposal: Detecting when the user leaves a page due to
hitting the back butt
d. As it
is now, one needs to use 2 confirm calls:
1. Proceed?
2. Save Changes (if user choose to proceed).
-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Sent: Monday, January 05, 2009 9:53 AM
To: Shropshire, Andrew A
Cc: public-webapps@w3.org
Subject: Re: Proposa
Shropshire, Andrew A wrote:
I am working a dialog problem now and I have discovered another problem
with Onbeforeunload:
It is called even for javascript URLs which clearly aren't exiting the
page.
I believe this is only the case in some browsers. For example,
IE/Windows does this, but Geck
ecting when the user leaves a page due to
hitting the back button or typing in a URL or going to a favorite
Boris Zbarsky wrote:
> Shropshire, Andrew A wrote:
> > 1. Allow the unload event to be cancellable from script. This
> > will allow web designers to recreate the modal flavo
On Mon, Jan 5, 2009 at 10:44 AM, Adam Barth wrote:
> On Mon, Jan 5, 2009 at 9:06 AM, Bil Corry wrote:
>> My demo that is listed (http://www.corry.biz/neverleave.lasso) will require
>> you forcibly terminate
>> your browser, so open it with a browser you want to forcibly terminate.
>
> Chrome le
On Mon, Jan 5, 2009 at 9:06 AM, Bil Corry wrote:
> My demo that is listed (http://www.corry.biz/neverleave.lasso) will require
> you forcibly terminate
> your browser, so open it with a browser you want to forcibly terminate.
Chrome lets me leave that page without terminating the browser (or th
Giovanni Campagna wrote on 1/5/2009 10:48 AM:
> This control would be useful also in case of infinite loops or 10'000 alert
> windows: user presses STOP and JS is disabled temporary
This problem was recently discussed on WHATWG:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-
Giovanni Campagna wrote:
What if we follow completely Andrew's proposal? That is, we allow
cancellation of beforeunload events, but we add an UI control that may
be used to froze JS (in HTML5 terms), preventing a further beforeunload
to be handled and canceled.
That places UI requirements on
Shropshire, Andrew A wrote on 1/2/2009 8:36 AM:
> I'd like to propose an onNavigateToNewPage event for the window object.
> This would be distinguished from the onUnload event in that the event is
> only fired when the user navigates to a new page whereas onUnload is
> fired additionally for when
Boris Zbarsky wrote:
> Shropshire, Andrew A wrote:
> > 1. Allow the unload event to be cancellable from script. This
> > will allow web designers to recreate the modal flavor of
> > desktop apps like MS Excel that prompt with "Yes/No Cancel"
> > when there are unsaved changes.
>
> Doesn't the
2009/1/5 Boris Zbarsky
> Giovanni Campagna wrote:
>
>> Probably treating the onbeforeunload as a real cancelable event
>>
>
> But the key is that the page must not be able to prevent navigation away
> from itself without explicit OK by the user. In other words, while the UA
> needs to be able to
Giovanni Campagna wrote:
Probably treating the onbeforeunload as a real cancelable event
But the key is that the page must not be able to prevent navigation away
from itself without explicit OK by the user. In other words, while the
UA needs to be able to cancel the unload, the page has no
2009/1/5 Boris Zbarsky
>
> Shropshire, Andrew A wrote:
>
>> 1. Allow the unload event to be cancellable from script. This will
>> allow web designers to recreate the modal flavor of desktop apps like MS
>> Excel that prompt with "Yes/No Cancel" when there are unsaved changes.
>>
>
> Doesn't the
Shropshire, Andrew A wrote:
1. Allow the unload event to be cancellable from script. This will
allow web designers to recreate the modal flavor of desktop apps like MS
Excel that prompt with "Yes/No Cancel" when there are unsaved changes.
Doesn't the onbeforeunload event do this? Or is your
confirm dialog problem mentioned above, the
browser entered a modal state and did not allow the user to go to any of
the other tabs.
Andrew Shropshire
-Original Message-
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
Sent: Friday, January 02, 2009 3:13 PM
To: Shropshire, Andrew A
Cc: public-w
Shropshire, Andrew A wrote:
4)Should a web page designer cancel all navigations away from the
page just to be malicious, the user can still close the page (since
closing the page does not fire the onNavigateToNewPage event).
That loses the user's navigation history in that window, so does
I'd like to propose an onNavigateToNewPage event for the window object.
This would be distinguished from the onUnload event in that the event is
only fired when the user navigates to a new page whereas onUnload is
fired additionally for when the user closes the web page or browser.
When the use
29 matches
Mail list logo
