[whatwg] Specify href target with HTTP headers

[Christian Schmidt]

On <a> and <form> elements you can specify a target attribute, e.g. 
_blank. But sometimes you don't know whether to open in _self or _blank 
at the time the link is clicked/the form is submitted.

I suggest that a server can specify a link target in an HTTP header, 
e.g. "Window-Target: _blank". The page would be equivalent to specifying 
the same value in the <form> or <a> tag leading to the page. It should 
probably be subject to some kind of restrictions, e.g. the header could 
be ignored if the link destination and the referring page had different 
origins, unless the referring page specified some special value in the 
target, e.g. _server (this value would indicate that the link 
destination is a somewhat trusted resource whose Window-Target header 
should be honoured). This ensures that the referring origin is always in 
control of the target.

It seems there was such a header (to some extent, at least) back in 
Netscape 4:
http://lists.w3.org/Archives/Public/www-html/1998Jan/0010.html
https://bugzilla.mozilla.org/show_bug.cgi?id=97459

The Content-Disposition: attachment/inline header does something related 
not entirely. Its was originally invented for use in MIME mails.


Use-case #1:
Sometimes the form target cannot be determined until after the form has 
been submitted. Assume you have a form of some kind. If the server-side 
validation fails, you want to load the same page again (this time with 
an error message) in the same window, but if the server-side validation 
succeeds, you want to open a new window, e.g. containting a PDF or some 
application-like window. This behaviour is sometimes done using 
window.open() on the target page, but many popup blockers prevent this.

Use-case #2:
In Drupal 8 the administrative pages are opened in an overlay/lightbox 
on top of the frontend pages. For each URL it is specified (by means of 
wildcard patterns in hook_admin_paths()) whether it should open in the 
overlay or in the entire browser window, i.e. whether the URL is an 
administrative page or not. For each link on a page the target attribute 
should be specified accordingly (this is handled client-side using a 
click handler on <a> elements that matches the current href against the 
wildcard patterns and dynamically alters the target attribute - see 
Drupal.overlay.eventhandlerOverrideLink in [2]). Contrary to use-case #1 
it /is/ possible to preprocess all links, but it is a lot of work for 
all links on a page. It would be easier if the server could determine, 
whether the link that was actually clicked on should open in the overlay 
or not.


[1] 
http://api.drupal.org/api/drupal/modules!system!system.api.php/function/hook_admin_paths/7
[2] 
http://drupalcode.org/project/drupal.git/blob/HEAD:/core/modules/overlay/overlay-parent.js#l530

-- 
Christian Schmidt