[whatwg] Proposal: target="_reference"

[Ian Hickson]

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 consider it acceptable fallback, they could use script 
> to replace the new-window behavior with fake-popup behavior in legacy 
> browsers.)
> 
> As a bonus, once it was widely supported, document authors could also 
> start using target="_reference" for footnotes and endnotes. This would 
> be much better than most existing footnote/endnote mechanisms, in that 
> the browser wouldn't scroll or navigate away from the original text 
> while showing the note. This in turn would make it much easier to 
> implement than existing footnote/endnote mechanisms: authors wouldn't 
> need to provide special "Back to article" links, or insert dummy 
> id=/name= attributes to serve as the targets of those links. It would 
> work equally well regardless of where the note text was placed -- at the 
> end of a <section>, at the end of the page, or even on a separate page. 
> And it wouldn't even require adding any new elements or attributes to 
> HTML.

On Sun, 27 Apr 2008, Philip Taylor wrote:
> 
> 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 and why would it be more 
> successful in practice?

On Sun, 27 Apr 2008, Matthew Paul Thomas wrote:
> 
> 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.

On Mon, 28 Apr 2008, fantasai wrote:
> 
> 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.

On Sun, 4 May 2008, Matthew Paul Thomas wrote:
> 
> I don't intend target="_reference" for notifications; that would be 
> quite inappropriate. Firstly, a notification should appear unbidden, but 
> if an author tried to use target="_reference" in that way, the popup 
> blockers in legacy browsers would ensure it never appeared. Secondly, a 
> notification is typically something you read once and then ignore, so it 
> doesn't matter if it scrolls out of view, while part of the point of 
> target="_reference" is to ensure the resource *doesn't* scroll out of 
> view. And thirdly, it usually makes little sense for a notification to 
> have a separate URL, but this is much more useful for help, terms of 
> service, privacy policies etc.
> 
> I intend target="_reference" for the purposes I actually described: 
> help, terms of service, privacy policies, and (eventually) footnotes and 
> endnotes. I chose "_reference" because that term roughly covers all 
> those use cases. But if the name is confusing, which it may be, I'd be 
> happy for it to be "_secondary" or something similarly non-specific.
>
> 
> target="_reference" would be inappropriate for presenting errors, for 
> much the same reasons as it would be inappropriate for presenting 
> notifications.
> 
> The exact presentation is up to the UA, of course, but I imagine a 
> resizable pane at the bottom of the viewport, defaulting to about a 
> quarter of the viewport height or about 12 em, whichever is smaller. 
> (Ideally it would be sized based on the actual height of the linked 
> resource, but that's impractical: impractical for internal fragments 
> because you usually can't tell where the fragment ends, and impractical 
> for external resources because -- just as with target="_blank" -- 
> responsiveness would require showing the pane before the resource 
> finishes loading.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'