- From: Rowan Nairn <rnairn@gmail.com>
- Date: Thu, 4 Mar 2010 22:14:13 -0800
I'd like to see if I can move this forward a bit. Let's drop some of my original suggestions and break the solution into two separate simple features that we can discuss independently. Firstly, of the problems with overlays listed in my original email ([1]), I think the following are the most important to deal with: > - Navigation in framed page does not get rid of the overlay (without > explicit frame breaking) > - After the user navigates within the frame, information in the > overlay no longer applies to framed content I propose a "oneshot" attribute for iframe to alleviate this: <iframe src="http://example.com/" oneshot> This would have the effect of having all links and forms in the framed page have an implicit target="_top". The second most import problem to deal with is the following: > - Getting rid of the overlay means refreshing the framed page, either > losing scroll position, or having navigated to another page, possibly > losing the page entirely. A cooperative overlay needs a way to promote the frame content to the top browsing context without causing a page refresh. In fact I can see how this would be useful in other contexts too so it makes sense to separate it from the other requirements. For this I propose a method of iframe: iframe.makeTop() This has a similar effect to setting top.location = iframe.contentWindow.location (i.e. changing the URL bar, adding a history state, etc.), but it simply promotes the iframe context to the top level without refreshing the page. Are either of those on their own more palatable to implementers? Rowan [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025005.html
Received on Thursday, 4 March 2010 22:14:13 UTC