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: iframe src=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 scott.gonza...@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 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.
[whatwg] Making cross-domain overlays more user-friendly
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. Popular websites which often frame other sites instead of linking directly: - facebook - ow.ly - stumbleupon - digg Current practice: - User follows a link which may look like it will take them to destination-site.com - Instead they get a page from overlay-site.com with the page from destination-site.com loaded in an iframe - The viewport contains the destination-site.com frame taking up most of the space, plus some chrome from overlay-site.com - The overlay may be completely disjoint from the framed content or overlapping it slightly - The overlay may contain information about the framed content, including URL, title or data specific to overlay-site.com - The overlay may contain links to further act on the framed URL or return to overlay-site.com - The overlay may contain a close this overlay button which sets the location of the window to the framed URL - Performing actions in the overlay may cause it to increase in size relative to the framed content, or show dialogs above the framed content Problems for user: - URL of framed page is often hidden - Navigation in framed page does not get rid of the overlay (without explicit frame breaking) - It may not be obvious how to get rid of the overlay - After the user navigates within the frame, information in the overlay no longer applies to framed content - 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. - Framed content may use javascript to detect and break out of frame, denying the user access to the overlay information - Malicious overlay sites may try to cause the user to disclose passwords or private information to them Requirements: - address the problems above - don't introduce new security issues like susceptibility to phishing attacks - don't rely on a lot of extra effort on the part of web designers - degrade gracefully in legacy browsers 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. iframe src=http://destination-site.com/; main/iframe - Add one new method to iframe: e.g. removeOverlay() Effect of iframe main: - The main URL bar should display the framed URL i.e. http://destination-site.com/ - The browser should display some chrome around any elements from the overlay page that signify them as foreign to the framed content - Possibly the browser should display the URL of the overlay somewhere - The browser should have a built-in button for getting rid of the overlay - Pressing this button would promote the framed content to the top level window, retaining state like scroll position - a iframe.removeOverlay() method should be available in the overlay page which performs the equivalent of this button - Navigation within the framed content should have target=_top implied by default so that navigation always removes the overlay - The framed content should not be aware that it is framed i.e. its window object should equal its top object This proposal would allow current practices to still work but, with the addition of a single attribute, make the experience better for users. Are there any browser vendors interested in implementing such a feature? Cheers, Rowan
Re: [whatwg] Making cross-domain overlays more user-friendly
On Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu 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 iframe main 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 Fri, Feb 5, 2010 at 2:46 PM, Boris Zbarsky bzbar...@mit.edu 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 iframe main 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
[whatwg] a onlyreplace
On Sun, Oct 18, 2009 at 4:30 AM, Ian Hickson ian at hixie.ch wrote: My recomendation would be to follow the process for adding features: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F In particular the bit about experimental implementations. I think this idea looks very interesting, but it's hard to evaluate without concrete experience with a browser implementing this (or, as Jonas suggests, a library that hacks it in). It seems like the kind of thing that we could adopt early on in the next feature cycle, if it turns out to be a good solid model. Yup, was planning on this. Just wanted to hack it out on the list first before jumping down any rabbit holes. If nobody beats me to it, this should be relatively easy to hack in (and may already be hacked in in some form, via mooTools?). ~TJ Hi Tab, I was just about to propose something similar so I was happy to find the recent discussion of onlyreplace on the mailing list. (Should have gotten around to it before Last Call, doh!) My use case is slightly different than yours. You want to do AJAXy replaces without javascript. I want to provide an animated page transition that doesn't break the back button or the URL bar and degrades gracefully in non-javascript UAs. You can see an example of this at http://mrtaggy.com/ . This is a site I launched last year that uses animations to show transitions between search result pages. Leaving aside whether you like this particular set of animations, I think you'll probably a agree that animations are used well in many applications to help users keep track of change. It would be nice if this was easy to do on the web. I was going to propose a similar attribute on links and forms but I hadn't envisioned the automatic scheme from replacing sections of pages. I think the automatic algorithm is great and necessary but I also think it would be useful to let developers customize the transition from one view to another. One way to do this might be a new event, onpagereplace or something, that fires when an onlyreplace link is clicked. If you don't preventDefault() then the automatic algorithm for replacing sections would run. If you do then you can customize the transition yourself. The way this is implemented in MrTaggy is with a hidden iframe. Certain links target the iframe (btw, this suggests that onlyreplace could instead be target=_replace) and an onload event on the iframe triggers the code that animates the transition from the old view to the new. The page that loads in the iframe is a full results page so without javascript (and no hidden iframe) every thing works fine. Also the back button works on all browsers, old and new (try adding a tag to an existing query and then clicking back). The only problem is that the URL bar does not update. Ultimately I made the difficult decision that back/forward was more important than bookmarking/link sending/etc. You can't have both in legacy browsers. ...which is where the (future) spec comes in. I'd love to see this made easier. pushState is fine but it doesn't degrade gracefully like this and it seems a bit too general even. Part of the attraction of onlyreplace+transitions is it forces developers to think about progressive enhancement of pages that work fine without javascript. Let me know if I can help with your formalization efforts. Rowan
[whatwg] Multi-touch events
Hi, I'm new to the list so I'm not sure if this is beyond scope or not but has anybody thought about what kind of mouse events we would like to get, say the iPhone (or similar) passes all the touches on to the DOM? I'm thinking the minimal helpful API change would be a new field for the Event object that uniquely identifies a pointing device for the duration of a mousedown-mousemove-mouseup cycle. Any thoughts? Some more of mine here: http://eurekaman.com/towards-multi-touch-in-the-browser Rowan
