Re: [whatwg] Proposal: target=_reference
I haven't added target=_reference. Though I think it's a good idea, we would probably need more browser vendor buy-in before going ahead with this. If anyone wants to see if we can get this moved further along, I recommend trying to follow the steps described here: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F In particular, step 4 (getting experimental implementations). On Sat, 26 Apr 2008, Matthew Paul Thomas wrote: Summary: I propose target=_reference, which would open a link in a secondary viewport, for example a closable pane at the bottom of a browser window. This would be much less annoying and intimidating than target=_blank. It could be used immediately for providing help, and for linking to privacy policies, terms of use, etc within forms. Eventually it could also be used for footnotes and endnotes. [...] For a vanilla form -- a vertical series of labelled text fields, checkboxes, and so on -- there are indeed friendlier ways of offering help than in a popup window. For example, a (What's this?) link next to a control might make visible a section under the control containing extra help, without obscuring the rest of the form. That is what we planned initially. But in a page that's less like a form and more like an application, there often isn't room to do this. The example that defeated our expanding-section plan was needing to explain the eight possible choices for a select menu, where the menu was the sole contents of each cell in a table column. The help link for that belonged in the column's header cell, but then where should the help itself appear? Not enough room in the header cell, or anywhere else in the table itself. And displaying it below the table risked it being off-screen and not seen, if the table was tall enough. There's a similar problem with help links that appear in any small sidebar or other narrow area. So our current plan is to use a Facebook-style fake popup window, a box that floats above the rest of the page content and is dismissed with an OK button. This has two important advantages over target=_blank: * If you close or navigate away from the page, the help doesn't need to be closed separately. * If you switch to a different window or tab, the help isn't flopping around unneeded. But it also has three disadvantages compared with target=_blank: * It's impossible to arrange the application and the help side by side, such that they don't obscure each other. * Whatever interface we provide for closing the help window, it's inconsistent with someone's platform conventions, and inconsistent with other Web sites that do something similar. * It's literally thousands of times harder to implement. What would an interface look like that avoided these disadvantages? It would disappear whenever the page was closed, navigated away from, or switched away from. It wouldn't obscure the page content. It would be consistent with platform conventions. And it would be just as easy for authors to implement as target=_blank is. The obvious solution, for large-screen browsers, is a pane that appears at the bottom of the browser window -- like the docked palettes in some drawing programs, or the Firebug add-on in Firefox. This pane would disappear along with the rest of the page as soon as you went to a new page. The browser would be in charge of giving it a Close button that matches OS conventions. And a browser might also (but wouldn't need to) let you drag it from the bottom to the side of the window, or even undock it into its own floating window (though this should still disappear when you closed the main page or navigated to another page). For small-screen browsers, such as those in phones, it would be a separate screen that -- unlike target=_blank -- had a browser-supplied OK button, and when closed always returned you to the screen whence it was opened, preferably in exactly the state it was in when you left it. To support this, I propose target=_reference, referring to a secondary viewport that is strongly associated with the primary viewport from which it is opened. A browser must provide an obvious mechanism for closing this secondary viewport separately from the primary one; for the author to do so should be non-conformant. And if the primary viewport is closed, or navigates to a new resource (not just a separate fragment of the same resource), the secondary viewport should close automatically. Only one secondary viewport should be available per primary viewport: within the secondary viewport, target=_reference should refer to the same viewport, not to a new one. Web application developers could start using target=_reference immediately for providing help, since the way current browsers treat it -- opening a separate window -- would be an acceptable fallback. (If developers didn't
Re: [whatwg] Proposal: target=_reference
Křištof Želechovski wrote: How about target=_guide instead? A reference is usually lengthy and unreadable; the designer should know better than to treat the poor user with a reference. Or _notification. Most of what Matthew wants to use it for seems to be notifications. How are you supposed to figure out the size of this thing? If it's for footnotes and TOS and errors and help and what's-this all at once.. they have different layout requirements. Footnotes fit fine at the bottom, but notifications should be at the top. Small help content could be anywhere, but extensive help content would fit better on the side, especially on wide screens. Squeezing significant amounts of text content into a top or bottom panel would make it hard to read: that space is wide and short. And TOS pages need more space than any of these if you're actually planning to read them, but they don't need to be side-by-side with the original page: in that case a floating box in the middle of the page would be ideal. Etc. ~fantasai
Re: [whatwg] Proposal: target=_reference
How about target=_guide instead? A reference is usually lengthy and unreadable; the designer should know better than to treat the poor user with a reference. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Paul Thomas Sent: Saturday, April 26, 2008 2:24 PM To: WHAT WG List Subject: [whatwg] Proposal: target=_reference Summary: I propose target=_reference, which would open a link in a secondary viewport, for example a closable pane at the bottom of a browser window. This would be much less annoying and intimidating than target=_blank. It could be used immediately for providing help, and for linking to privacy policies, terms of use, etc within forms. Eventually it could also be used for footnotes and endnotes.
Re: [whatwg] Proposal: target=_reference
Philip Taylor wrote on 27/04/08 18:30: ... IE6 supported target=_search and target=_media, to open pages in sidebars (closable panes at the side of the browser window). Nobody uses those target values (in 130K pages I see 3 pages with either), and http://msdn2.microsoft.com/en-us/library/ms534659(VS.85).aspx says _media was dropped in XP SP2 and _search was dropped in IE7 (for security reasons). _reference sounds functionally very similar, so how would it avoid those security problems The problem with _media and _search was that if you gave them an invalid URL, the resulting error page res://blahblahblah was in the My Computer zone, but could still be manipulated (e.g. have malicious code inserted in it) by the remote page. That could be avoided by not treating error pages as being in the My Computer zone. I guess Microsoft didn't bother with this because they knew that media was going to be, and search already was, handled differently in IE7 anyway. and why would it be more successful in practice? Because it would be cross-browser. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
[whatwg] Proposal: target=_reference
Summary: I propose target=_reference, which would open a link in a secondary viewport, for example a closable pane at the bottom of a browser window. This would be much less annoying and intimidating than target=_blank. It could be used immediately for providing help, and for linking to privacy policies, terms of use, etc within forms. Eventually it could also be used for footnotes and endnotes. On Apr 21, 2008, at 6:21 AM, Ian Hickson wrote: ... On Sat, 28 Apr 2007, Lachlan Hunt wrote: ... * Opening help windows. e.g. for help with forms. - There are much more user friendly ways of offering help to users without popups. ... I agree with your comments. ... I've changed the spec to make _blank legal but to also encourage browsers to not create a new window when one is requested. I've just come across this problem myself when designing a Web site's help system. For a vanilla form -- a vertical series of labelled text fields, checkboxes, and so on -- there are indeed friendlier ways of offering help than in a popup window. For example, a (What's this?) link next to a control might make visible a section under the control containing extra help, without obscuring the rest of the form. That is what we planned initially. But in a page that's less like a form and more like an application, there often isn't room to do this. The example that defeated our expanding-section plan was needing to explain the eight possible choices for a select menu, where the menu was the sole contents of each cell in a table column. The help link for that belonged in the column's header cell, but then where should the help itself appear? Not enough room in the header cell, or anywhere else in the table itself. And displaying it below the table risked it being off-screen and not seen, if the table was tall enough. There's a similar problem with help links that appear in any small sidebar or other narrow area. So our current plan is to use a Facebook-style fake popup window, a box that floats above the rest of the page content and is dismissed with an OK button. This has two important advantages over target=_blank: * If you close or navigate away from the page, the help doesn't need to be closed separately. * If you switch to a different window or tab, the help isn't flopping around unneeded. But it also has three disadvantages compared with target=_blank: * It's impossible to arrange the application and the help side by side, such that they don't obscure each other. * Whatever interface we provide for closing the help window, it's inconsistent with someone's platform conventions, and inconsistent with other Web sites that do something similar. * It's literally thousands of times harder to implement. What would an interface look like that avoided these disadvantages? It would disappear whenever the page was closed, navigated away from, or switched away from. It wouldn't obscure the page content. It would be consistent with platform conventions. And it would be just as easy for authors to implement as target=_blank is. The obvious solution, for large-screen browsers, is a pane that appears at the bottom of the browser window -- like the docked palettes in some drawing programs, or the Firebug add-on in Firefox. This pane would disappear along with the rest of the page as soon as you went to a new page. The browser would be in charge of giving it a Close button that matches OS conventions. And a browser might also (but wouldn't need to) let you drag it from the bottom to the side of the window, or even undock it into its own floating window (though this should still disappear when you closed the main page or navigated to another page). For small-screen browsers, such as those in phones, it would be a separate screen that -- unlike target=_blank -- had a browser-supplied OK button, and when closed always returned you to the screen whence it was opened, preferably in exactly the state it was in when you left it. To support this, I propose target=_reference, referring to a secondary viewport that is strongly associated with the primary viewport from which it is opened. A browser must provide an obvious mechanism for closing this secondary viewport separately from the primary one; for the author to do so should be non-conformant. And if the primary viewport is closed, or navigates to a new resource (not just a separate fragment of the same resource), the secondary viewport should close automatically. Only one secondary viewport should be available per primary viewport: within the secondary viewport, target=_reference should refer to the same viewport, not to a new one. Web application developers could start using target=_reference immediately for providing help, since the way current browsers treat it -- opening a separate window -- would be an acceptable fallback. (If developers didn't consider it acceptable fallback, they could
