[whatwg] Specify href target with HTTP headers

Wed Mar 14 15:11:34 PDT 2012

On Wed, 14 Mar 2012 19:59:50 -0000, Christian Schmidt <whatwg.org at chsc.dk>  
wrote:
> Bjartur Thorlacius skrev 2012-03-09 10:43:
>> I argue that putting user interface hints into a file transfer
>> protocol does cause problems
> Would it be better if the Window-Target was somehow specified in the  
> <head> of the destination page, or is that just another way of doing the  
> same?
>
>
>> In special, having two identifiers for the same resource, one for
>> when the resource is to be navigated to in an existing browsing
>> context and another for when navigation to the resource implies
>> creation of a new browsing context, breaks identification.
> It was not my suggestion to use to introduce more URLs. But a resource  
> that is designed to be used in an iframe context often does not make  
> sense to load in the entire browser window (pages loaded in an iframe  
> often do not contain navigation, header, footer etc.), so in practice I  
> think a resource is often somewhat “tailored” to a specific browsing  
> context.
>
>
If the response (headers + page) are tailored to the specific browsing  
context already, Window-Target should not create any new problems. But do  
note that the streamlined presentation you describe makes sense for both  
projection and tiny viewports as well. In fact, link collections such as  
Wikipedia's "toolbox" are resources in and of themselves that are often  
embedded in pages (or included by proxies) to optimize out costly  
round-trips. Optimizing for iframes is mostly about trimming  
non-(main)-content.

(For the record, I hunt for made-for-iframes pages, such as the Facebook  
chat pop-out, and load them in a dedicated window to avoid clutter. I  
simply prefer UI that minimizes the amount of on-screen distractions.)

> I'm not sure I understand what you mean. The usual way of doing
> server-side validation of a form (e.g. a login form) is to submit it and
> - in case the validation fails - to show the same form prefilled with
> the same data but with red boxes around the invalid fields, error
> messages, help texts, etc. Of course you can do this by submitting the
> form via AJAX and then manipulate the DOM via JavaScript, but that is
> complex.
>
I agree with all of the above. I find it notable that user agents have not  
standardized on and implemented a form submit and validation protocol that  
every AJAX page reimplements already. The reason is probably because  
implementing said protocol would probably be more difficult to implement  
in user agents, and harder to style by servers for branding reasons.

While I find it notable, I do not volunteer to change this. It would most  
likely not be worth the effort.

--
-,Bjartur