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

[Rowan Nairn]

Right.  With this type of proposal we lose the "degrade gracefully"
property which means implementors have to do twice the amount of work
or more.  I also think an attribute on hyperlinks is not the way to go
(at least not the only way).  Remember that the entity that is
providing the infobar will not necessarily have control over the
hyperlink that brought you there.  Many of these overlays are
triggered from a link on Twitter for example.

Rowan

2010/2/10 Scott González <scott.gonzalez at gmail.com>:
> 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.
>>
>>
>
>