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

[Scott González]

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 <mart at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100210/8a783efd/attachment-0002.htm>