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.
On Wed, Feb 10, 2010 at 2:00 AM, Martin Atkins <m...@degeneration.co.uk>wrote: > Rowan Nairn wrote: > >> Hi, >> >> In the spirit of paving some cow paths I'd like to put forward a >> proposal for a future version of HTML. The behavior I'm addressing is >> sites that replace links to external content with a framed version of >> that content, along with their own overlay of information and links. >> I think with some small tweaks it's possible to create a better >> experience for the user in these situations. I wasn't able to find >> any discussion of this use case in the archives. Please excuse me if >> this has already been discussed. >> >> [snip details of proposal] > > Alternate proposal: > > * 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. > * 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. > * Include a mandatory close button on the infobar panel. > * Have this extra bar disappear if the user navigates away from the page > or chooses the close button. > * Have this extra bar disappear if the infobar document calls > window.close. > * 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. > * If the infobar document causes navigation by a means other than a link, > such as setting document.location, it is just closed. > * 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. > > 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. > > 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. > > 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. > > 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. > > >