[whatwg] Specify href target with HTTP headers

[Ian Hickson]

On Wed, 7 Mar 2012, Christian Schmidt wrote:
>
> 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.

I don't understand why you would want a new window here. Can you elaborate 
on this? Why would you not just rely on the user to decide whether they 
want a new window or not?


> 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.

That seems to me a bit of a weird setup, but ok, I can see the use case 
here. How much of a cost is it to have a single event handler that just 
traps all clicks on links, or a single loop that rewrites all links, to 
point them to the right place, though, compared to the cost of getting all 
the browsers to support this new feature? It's not clear to me that 
there's an obvious win here.

In particular, I wonder how common this kind of setup will be going 
forward. It seems to me that the trend is towards making applications more 
client-server driven with a static HTML page talking to a WebSocket server 
and without loading new HTML for each options page, for instance. So I 
don't know how much value there is in adding features to this kind of thing.

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