The big disadvantage to this proposal is that it won't work until browsers implement the functionality, which would discourage anyone from using it since the fallback is that no overlay/infobar is presented. Rowan's implementation will allow the overlay/infobar to be displayed, but would keep the target page contained in an iframe. I would imagine that almost everybody that wants an overlay/infobar would opt to use a method that forces the overlay/infobar to be displayed, even if that means continuing with their current implementations.<br>
<br><br><div class="gmail_quote">On Wed, Feb 10, 2010 at 2:00 AM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Rowan Nairn wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
In the spirit of paving some cow paths I'd like to put forward a<br>
proposal for a future version of HTML.  The behavior I'm addressing is<br>
sites that replace links to external content with a framed version of<br>
that content, along with their own overlay of information and links.<br>
I think with some small tweaks it's possible to create a better<br>
experience for the user in these situations.  I wasn't able to find<br>
any discussion of this use case in the archives.  Please excuse me if<br>
this has already been discussed.<br>
<br>
</blockquote></div>
[snip details of proposal]<br>
<br>
Alternate proposal:<br>
<br>
 * Add a new attribute on all hyperlink elements which accepts a URL as its value. Let's call this new attribute "infobar" for want of a better name for it.<br>
 * When the user follows that link, create a view where the main browser window contains the page which was the href of the link, but where there is also a smaller docked view, perhaps along the top of the browser window, containing the page which at the URL given in the infobar attribute.<br>

 * Include a mandatory close button on the infobar panel.<br>
 * Have this extra bar disappear if the user navigates away from the page or chooses the close button.<br>
 * Have this extra bar disappear if the infobar document calls window.close.<br>
 * Any links in the infobar document get loaded in the main browser window, which implicitly closes the infobar since this is a navigation in the main window.<br>
 * If the infobar document causes navigation by a means other than a link, such as setting document.location, it is just closed.<br>
 * The infobar document *may* use window.open to open other windows -- subject to normal popup blocker restrictions -- if it needs to display some UI that does not fit into the infobar form factor.<br>
<br>
This proposal compromises the flexibility of UI in what you called the overlay document and what I called the infobar document. The most notable omission is that it does not allow the overlay site to choose how the infobar is displayed, since the main page is given precedence. It may be desirable to provide some means by which the infobar document can request a particular size, though the user-agent must impose restrictions on the size to prevent a situation where the information bar appears more prominent than the main document.<br>

<br>
This proposal, much like the "ping" attribute proposed previously, allows a user-agent to offer a feature whereby the infobar can be skipped altogether. It also causes the Referer header of the request to the main page to be the original linking page and not the infobar page.<br>

<br>
It still has the challenge that the UA must find a way to make it unambiguous that the infobar is *not* part of the main page, to prevent attacks such as including an infobar containing a login form which looks like it belongs to the main page when in fact it does not. One idea, which may be too draconian, is to prevent the infobar frame from accepting keyboard input altogether, and not allow any form elements within it to receive focus. The infobar document may open a new window using window.open if it needs to capture some information; that window will display the URL of the document in its location bar, allowing the user to see what site it's loaded from.<br>

<br>
However, it is likely that these restrictions will cause site implementers to continue with current practice in order to retain the flexibility they currently enjoy.<br>
<br>
<br>
</blockquote></div><br>