Re: [whatwg] Making cross-domain overlays more user-friendly
On Fri, 5 Feb 2010, Rowan Nairn wrote: > > 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. > [...] > A Proposal: > > I would be interested to hear any ideas for addressing this use case > better. My idea is as follows: > - Add one new attribute to iframe > e.g. http://destination-site.com/"; main> > - Add one new method to iframe: > e.g. removeOverlay() > [...] This is an interesting idea. The most effective way forward for an idea like this would be to get some experimental implementations, to see if the security issues that were brought up can be sufficiently addressed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Making cross-domain overlays more user-friendly
I'd like to see if I can move this forward a bit. Let's drop some of my original suggestions and break the solution into two separate simple features that we can discuss independently. Firstly, of the problems with overlays listed in my original email ([1]), I think the following are the most important to deal with: > - Navigation in framed page does not get rid of the overlay (without > explicit frame breaking) > - After the user navigates within the frame, information in the > overlay no longer applies to framed content I propose a "oneshot" attribute for iframe to alleviate this: http://example.com/"; oneshot> This would have the effect of having all links and forms in the framed page have an implicit target="_top". The second most import problem to deal with is the following: > - Getting rid of the overlay means refreshing the framed page, either > losing scroll position, or having navigated to another page, possibly > losing the page entirely. A cooperative overlay needs a way to promote the frame content to the top browsing context without causing a page refresh. In fact I can see how this would be useful in other contexts too so it makes sense to separate it from the other requirements. For this I propose a method of iframe: iframe.makeTop() This has a similar effect to setting top.location = iframe.contentWindow.location (i.e. changing the URL bar, adding a history state, etc.), but it simply promotes the iframe context to the top level without refreshing the page. Are either of those on their own more palatable to implementers? Rowan [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-February/025005.html
Re: [whatwg] Making cross-domain overlays more user-friendly
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 : > 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 > 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. >> >> > >
Re: [whatwg] Making cross-domain overlays more user-friendly
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 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. > > >
Re: [whatwg] Making cross-domain overlays more user-friendly
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.
Re: [whatwg] Making cross-domain overlays more user-friendly
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky wrote: > On 2/5/10 5:40 PM, Rowan Nairn wrote: >> >> - don't introduce new security issues like susceptibility to phishing >> attacks > > > >> - The main URL bar should display the framed URL i.e. >> http://destination-site.com/ > > I'm having a really really really hard time reconciling these two, > especially in the cases when the is not actually visible (e.g. > is visibility:hidden). An alternative is to drop this requirement. It is not necessary to replace the main URL bar as long as the URL of the framed content is available *somewhere*. I wouldn't want to dictate much about the UI to vendors but maybe the requirement would be more like: - The UA must prominently display the URL of the framed page somewhere while making it clear to the user that the main URL is that of the overlay page. I agree that it's a very difficult UI problem. Understanding one URL is hard enough for many users. Rowan
Re: [whatwg] Making cross-domain overlays more user-friendly
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky wrote: > On 2/5/10 5:40 PM, Rowan Nairn wrote: >> >> - don't introduce new security issues like susceptibility to phishing >> attacks > > > >> - The main URL bar should display the framed URL i.e. >> http://destination-site.com/ > > I'm having a really really really hard time reconciling these two, > especially in the cases when the is not actually visible (e.g. > is visibility:hidden). > >> - The browser should display some chrome around any elements from the >> overlay page that signify them as foreign to the framed content > > Is this supposed to address the issue above? If so the problem is, I'm not > sure I see a good way to do this Then again, UI design is not my strong > point. Yes it is and yes you are right, my proposal is vague on that account. I don't have a good suggestion yet which would both provide enough context to the user and not look horrible. One way would be displaying the URL of the overlay page next to any overlaid elements along with an outline. Maybe someone has a better idea? Rowan
Re: [whatwg] Making cross-domain overlays more user-friendly
On 2/5/10 5:40 PM, Rowan Nairn wrote: - don't introduce new security issues like susceptibility to phishing attacks - The main URL bar should display the framed URL i.e. http://destination-site.com/ I'm having a really really really hard time reconciling these two, especially in the cases when the is not actually visible (e.g. is visibility:hidden). - The browser should display some chrome around any elements from the overlay page that signify them as foreign to the framed content Is this supposed to address the issue above? If so the problem is, I'm not sure I see a good way to do this Then again, UI design is not my strong point. -Boris
