[whatwg] Proposal: target="_reference"

[Matthew Paul Thomas]

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 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 Mon, 30 Apr 2007, Matthew Paul Thomas wrote:
>>
>> For example, forms sporting those "By submitting this form you accept
>> our __terms of service__ and __privacy policy__" links I mentioned
>> earlier are quite often sent over HTTPS. These are not cached by
>> mainstream browsers, because the browser vendors have caved to bank
>> Webmasters who threatened to block them if they were too 
>> HTTP-compliant. So if such a browser was configured to open those 
>> links in the same window, it would necessarily forget everything 
>> you'd entered in the form, which would be annoying.
>
> Yes, one change (reusing the same window) would also require another
> (caching forms in session history). I'm ok with both of these! :-)

So am I. But without finding a way for browsers to escape the economic 
trap of losing market share through being blocked by major sites, 
that's just not realistic.

However, target="_reference" would solve this problem resoundingly. You 
could read through the terms of service and/or privacy policy in the 
same window, without the form disappearing out of the cache. There 
would be no more panic, from people with maximized browser windows, 
thinking the form had disappeared and their input with it. And as a 
bonus, you wouldn't even need to close the terms/policy window 
separately from submitting the form.

>> If _blank is allowed, I would prefer the specification to discourage
>> authors from using _blank when another solution is practical (e.g. 
>> using a <details> element in the original page), and encourage UAs to 
>> indicate when a link will open in a different top-level browsing 
>> context (e.g. by double-underlining instead of single-underlining).
>
> Where would you like such encouragements? I'm worried that the former 
> will get lost easily,

Immediately following the definition of _blank. (Where else did you 
have in mind?)

> and that the second is basically impossible to implement reliably due 
> to scripting (though Safari tries).
> ...

Safari's designers seem to agree with me that it's helpful even if it's 
not completely reliable.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/