[whatwg] Making cross-domain overlays more user-friendly

[Martin Atkins]

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.