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/
