- From: Vladimir Kelman <vlad@vkelman.com>
- Date: Sat, 07 Jan 2006 20:41:06 -0500
- To: public-webapi@w3.org
Karl Pongratz wrote: > I also want to note that I wanted to propose something simple that > solves the emerging Ajax web application web browser history problem, > something that is strongly tight to the xmlhttp request object and > would be easy to implement by user agent vendors. Karl, I strongly believe that modifying browser's engines to save *state* in addition to URL just cannot be simple enough. I highly doubt it would be implemented any soon. As <isolani/> says here http://www.isolani.co.uk/blog/javascript/FixingTheBackButtonThatAjaxBroke, "Part of the AJAX problem is understanding whether an AJAX enhanced page is actually a web application, or is it still just a web document?" I believe that an AJAX enhanced page should be considered a web application by itself. I also believe, that the best and really easy solution would be to conditionally disable "Back" and "Forward" buttons on an AJAX page. When I said "conditionally" I meant that in case a user clicks one of these buttons a browser should display a confirmation window asking if user really wants to *leave application*. Yes, it would break a "pure HTML ideology", but this ideology applies to web pages, not to web applications. AJAX web pages aren't first pages which would benefit from conditionally disabling "Back" and "Forward" buttons. The same issue arises for any web pages with dynamically modified content: for pages with frames, for pages with Java applets or ActiveX controls. Even plain HTML pages generated by server-side (PHP, ASP, etc.) script often experience troubles with "Back" and "Forward" buttons. Consider a standard situation when a page uses HTML form to POST to itself, or when server-side script uses SESSIONS to save data on a server side. It immediately breaks a normal behavior of "Back" and "Forward" buttons, because document's *state* is not exclusively determined by a URL, it may depend on a session variable or even data, retrieved from a database. So, again, such pages are web applications by themselves - something similar to a graphical Windows desktop application, and they should be able to restrict "Back" and "Forward" buttons' behavior. Internet Explorer does provide a way to do it with onbeforeunload Event http://msdn.microsoft.com/workshop/author/dhtml/reference/events/onbeforeunload.asp. Unfortunately, other browser's vendors consider themselves more "purist" and do not provide such ability. If you try to Google like http://www.google.com/search?hl=en&lr=&rls=GGGL%2CGGGL%3A2005-09%2CGGGL%3Aen&q=disable+back+button&btnG=Search you'll get a long list of messages from people struggling to disable those buttons... I understand that controlling "Back" and "Forward" buttons' behavior from a loaded HTML document may introduce some security risks, but I think that it well worth to implement as standard behavior - advantages are immense. -- Vladimir Kelman http://www.vkelman.com Vlad@vkelman.com
Received on Sunday, 8 January 2006 05:10:04 UTC