[whatwg] The target="" attribute

[Ian Hickson]

Summary:
 * Added name="" to <object> and <iframe> as a hook for target="".
 * Made _blank legal again.

Hallvord R M Steen wrote:
>
> often a page needs to interact with a plugin and tell it to load 
> another file. Today this is of course done with JavaScript, which is 
> difficult because most plugins have different JS interfaces, and there 
> are also differences between the plugins' ActiveX based interfaces in 
> IE and the NPAPI plugin ones.
> 
> Hence I thought it would be a great simplification if we could do the 
> following:
> 
> <object type="application/x-shockwave-flash" id="myMedia" 
> data="init.swf" ></object>
> 
> <a href="animation1.swf" target="myMedia"> load movie 1 </a>
> 
> A compliant UA would detect that the target was a plugin and not a 
> window, and call the plugin's NPP_NewStream method (I think, I don't 
> know NPAPI well at all) to notify it of the new file to load. I think 
> backwards compatibility is pretty good since a non-compliant UA would 
> open a new window for the new file.
> 
> What do you think of this idea?

I think this is an interesting idea, though I don't know how much demand 
there is for this. I would recommend following this up with the group 
documenting the NPAPI.


On Fri, 2 Mar 2007, Michael Enright wrote:
>
> If this is commonly done with just one line of JS then a bot could 
> probably find a significant number of pages with that one-liner in the 
> 'a' element's attributes. By one line, I mean a simple unwrapped 
> property change or invocation of a standard method, not through a 
> wrapper.
>
> It would be worth spec'ing in HTML5 if it applies to plugins that don't 
> obey the NPAPI.

I'm not sure how we could spec something without referencing the plugin 
API itself. What woudl it mean?


> Also it is a little troublesome because the proposal messes with the 
> namespace that the target attribute applies to. Currently there is no 
> reason to worry about a clash between the names of the windows and the 
> ids in the current page. To refine the proposal this potential clash 
> would have to be addressed. Could the target attribute in the example be 
> "#myMedia" to refer to the id on the current page? In general to change 
> the media on plugin P on window W you write 'target="W#P"'? And 
> target="_blank#something" has no defined resolution.

Yeah, there's no clash the way the spec is defined now.



On Sun, 8 Apr 2007, Georges MARZIN wrote:
> 
> I have a suggestion to submit : 
> Look at this piece of code : 
> 
>      <!-- look at the sharp in the target property --> 
> 
>      <a href="inc/foo.frg" target="#main_area"> 
>          Click here to dynamicaly load a text/html piece of code into 
> the "main_area" identified dom node 
>      </a> 
> 
>      <!-- somewhere in the same document --> 
>      <div id="main_area"></div> 
> 
> The content of inc/foo.frg in not a complete html page but only a well 
> formed xhtml piece of code like : 
> 
>     <div> 
>        this content is dynamically loaded into a dom node, like ajax,
>        but with a html extended syntax of the target property.
>     </div> 
> 
> - With this extension of the target attribute, it might be possible to 
> make some "ajax" kind of work without javascript enable. 
> - Second: developers don't need to know anything about
> xmlHttpRequest.   
> - Third avantage: with this syntaxe, a robot can parse the href content 
> to indexe it. Remember that html purist don't like ajax because it use 
> javascript and is not indexable by robots. 
> 
> It is possible to do the same with the target attribute of <form>
> element. 
> So the result of submission will appear in a dom element and not cover
> the whole page.

Why not just use <iframe>?


On Sun, 8 Apr 2007, Kornel Lesinski wrote:
> 
> IMHO it isn't much better than:
> 
> <a href="inc/foo.frg" target="main_area">
> <iframe name="main_area"></iframe>
> 
> It's still as evil as frames - subpages can't be used as standalone documents
> (thus bookmarked, returned by search engines, etc), because they lack proper
> navigation menus and in your example they're not even proper documents.

Indeed.


> I think that much better and more powerful solution are ID overlays. The 
> idea is to merge documents instead of completly including one into 
> another. XUL has something like that: 
> http://developer.mozilla.org/en/docs/XUL_Tutorial:Overlays

Yes, various suggestions along these lines have been made. I'm thinking 
maybe the best way forwards is to make the spec support these various 
proposals, but not implement any particular one proposal. (Similarly, Web 
Forms 2's repetition model, and HTML5's template model, should both 
probably be removed in favour of simply a supporting infrastructure that 
allows them to be implemented by script.)


On Sun, 8 Apr 2007, Georges MARZIN wrote:
> 
> When using iframe, the content is treated like a complete and separate 
> html page. So you have in your document a second page completely 
> different from the main document. So, if you want for this sub-page the 
> same comportment and appearance as the main page, you need to write a 
> complete head section with scripts and css, and to be careful to have 
> compatibility with the main page head section.

We could probably do something that allows style to cascade into iframes 
from the same origin, which would address this.


> With iframe, again, you need to set width and height and the content is 
> usually displayed with scroll-bars, and it is awful.

CSS3 styling can presumably work around this:

   iframe { height: intrinsic; width: auto; overflow: hidden; }


> If you just need to modify a small part of your document like displaying 
> pictures or response coming back a form php script, the iframe solution 
> is a heavy and ugly solution.

At the moment, this is indeed true.


> It's why I thought about another way with a very small modification of 
> the syntaxe of the target attribute : why not specify a dom id with a 
> "#", so it is easy to read and to understand. The "#" symbol mean id in 
> css stylesheet. There is no possible confusion with targeting names of 
> frames or targeting _blank or _top...
> 
> The small html fragment can be a seperate static file, or contextual php 
> results, like :
> 
> <div id="response">The response is : </div>
> <a href="answer.php?question=something&param=someparam"
> target="#response">click!</a>
> 
> When the response will arrive, css rules will apply to the new content,
> and the result will be smart.

I think changes to <iframe> to support cascading into same-origin 
<iframe>s, and changes to CSS to support intrinsic sizing of same-origin 
iframes, would be far simpler.


On Mon, 9 Apr 2007, Kornel Lesinski wrote:
> 
> I think there should be an additional requirement that every subpage 
> specifies its parent page. This would allow user agents to reconstruct 
> full document from any subpage.
> 
> How about that?
> 
> index.html:
> 
> <h1>My page</h1>
> <a href="subpage.html" rel=overlay>open subpage</a>
> <div id=main>hello world</div>
> 
> I've used rel=overlay since you don't need to specify where should supage be
> included (elements with same IDs will be replaced).
> 
> subpage.html:
> 
> <a href="index.html" rev=overlay>my parent</a>
> <div id=main>subpage</div>
> 
> This page has reV=overlay, which specifies the "parent" document. This has two
> roles:
> - a fallback that allows users and bots to find parent page that contains
> navigation and rest of the content
> - allows UAs that support overlays to rebuild complete page using this
> reference
> 
> resulting DOM would be:
> 
> <h1>My page</h1>
> <a href="subpage.html" rel=overlay>open subpage</a>
> <div id=main>subpage</div>
> 
> 
> It should be enforced that subpages contain rev=overlay link and that parent
> pages and subpages are mutually connected:
> 
> If there's no rev=overlay link in the subpage or it has rev=overlay link that
> points to URL other than that of current page, browser should normally open
> subpage instead of overlaying it.
> For example if index.html contains:
> <a rel=overlay href="orphaned.html">
> and orphaned.html does not contain <a rev=overlay href="index.html">, browser
> should not overlay it (ignore the rel=overlay).
> 
> 
> When opening a page that has rev=overlay link, browser should load referenced
> page and overlay the current one on top of it.
> 
> For example if user opens subpage.html as a standalone document (types the
> address, opens a bookmark) and the document contains:
> <a rev=overlay href="index.html">
> browser should load index.html and overlay subpage.html on it.
> 
> 
> And of course since DOM of pages gets shared, overlay should be subject to the
> same origin policy.

This seems somewhat complex, and limited -- what if more than one page 
wants to use an overlay?


On Sun, 22 Apr 2007, Simon Pieters wrote:
>
> I did some testing on id="" and name="" on <iframe>, <object> and <map>...
> 
>    http://hasather.net/test/html/id-vs-name/
> 
> (Thanks to David for uploading them -- FTP didn't work for me today.)
> 
> In the table below, A means "link opens in "iframe"", B means "link 
> opens in new window", C means "link opens in same window", and D means 
> "no link".

I've added (for comparison) a letter for what HTML5 requires in the Notes 
column:

>   Test  | Gecko WebKit Opera IE7 |          Title            |  Notes  5
> --------+------------------------+---------------------------+----------
> 001.htm | A     A      A     A   | <iframe name>             | Interop A
> 001.xml | B     A      A     -   | <iframe name>             | -       A
> 002.htm | B     A      A     B   | <iframe id>               | -       B
> 002.xml | A     A      A     -   | <iframe id>               | -       B
> 003.htm | B     B      B     B   | <object name>             | Interop B
> 003.xml | B     B      B     -   | <object name>             | -       B
> 004.htm | B     B      B     B   | <object id>               | Interop B
> 004.xml | B     B      B     -   | <object id>               | Interop B
> 005.htm | A     A      A     B   | <object name data=data:,> | IE bug? A
> 005.xml | B     A      A     -   | <object name data=data:,> | -       A
> 006.htm | B     B      A     B   | <object id data=data:,>   | -       B
> 006.xml | A     B      A     -   | <object id data=data:,>   | -       B
> --------+------------------------+---------------------------+----------
> 007.htm | C     C      C     C   | <map name>                | Interop C
> 007.xml | D     C      C     -   | <map name>                | -       C
> 008.htm | D     D      C     C   | <map id>                  | -       C
> 008.xml | C     C      C     -   | <map id>                  | Interop C
> 
> So... let's see what is interoperable...:
> 
> <a target> pointing to <iframe name> works in all, except in Gecko in XHTML.
> 
> <a target> pointing to an <object> that is not iframeish opens a new window in
> all.
> 
> <a target> pointing to an iframeish <object name> works in all except IE7, and
> also not in Gecko in XHTML.
> 
> <map name> works in all except in Gecko in XHTML.
> 
> <map id> works in all in XHTML.

All the above are now required in HTML5, with no distinction between HTML 
and XHTML.


> Looking at each browser's results individually, Opera's seems to be most 
> useful and predictable. I think this is what should be specced as to 
> what UAs must do. Having differences between HTML and XHTML here is not 
> useful IMHO.

I've done what Opera does except for treating id="" as a browsing context 
name.


> Looking at this from an author's perspective, it seems using name="" is 
> most reliable, and if we want some sort of consistency here, then I 
> think target="" must point to an <iframe name> or an iframeish <object 
> name> (as opposed to <iframe id> or <object id>), and usemap="" must 
> point to a <map name> (as opposed to <map id>). <map> is not useful 
> without a usemap="" pointing to it, so name="" could be a required 
> attribute on <map>.

The spec uses id="" on <map> as the conforming thing, not name="".


On Sat, 28 Apr 2007, Lachlan Hunt wrote:
> 
> The major reasons for popups that I can remember include:
> 
> * Links to external sites, so that users don't leave the previous site.
>   - It's far better to inform the user that they're going to an external
>     site and let them decide for themselves if they want a new window.
> 
> * Opening help windows. e.g. for help with forms.
>   - There are much more user friendly ways of offering help to users
>     without popups.
> 
> * Photo galleries, where clicking on the thumbnail opens the larger
>   version in a popup.
>   - There are much more user friendly alternatives that don't require
>     popups.  (Just imagine how hard Flickr would be to use if they
>     opened popups for every photo!)
> 
> * Links to files that require external apps, which commonly open within
>   the browser. e.g. PDF, Word docs, etc.
>   - Jakob Nielsen promotes this one for flawed usability reasons, but
>     whether or not such a file opens within the browser is entirely
>     dependent upon the UA config.
> 
> * Advertisements
>   - These are just annoying.
> 
> * To give users windows without chrome (using window.open()), sometimes
>   to prevent the use of the back button.
>   - Such uses usually indicate broken back end implementations and/or
>     the complete failure to think about usability.

I agree with your comments.


> target="_blank" is less evil than window.open(), so it may indeed be 
> more pragmatic just to concede that authors are going to use popups in 
> one way or another, and just allow it.
> 
> Sigh. :-(

I've changed the spec to make _blank legal but to also encourage browsers 
to not create a new window when one is requested.


[Snip other e-mails requesting that _blank be removed.]


On Sat, 28 Apr 2007, Bill Mason wrote:
> 
> 3) The back button is not considered reliable as a navigation aid if 
> target=_blank is not in use.

Can you elaborate on why this is?


On Sat, 28 Apr 2007, Matthew Paul Thomas wrote:
> 
> Ever since I first visited two Web pages that accidentally opened 
> external links in the same window as each other, I've assumed that the 
> top-level frame namespace being global was a bug, with 
> under-specification of the target= attribute in HTML4 as a contributing 
> factor.
> 
> I suggest that WA1 specify that the frame namespace is 
> per-top-level-browsing-context, not global. (Even if it is global in all 
> extant browsers, I doubt that any applications rely on that behavior.) 
> Otherwise, what is a Web application developer supposed to do to ensure 
> that the application's help links reuse only its own help window, and 
> don't accidentally obliterate those of other apps or even other open 
> windows in the same app? Generate a per-page UUID prefix for all its 
> target= attribute values? :-)

The spec does try to make the namespace be somewhat limited.


On Sat, 28 Apr 2007, Maciej Stachowiak wrote:
>
> In principle this sounds like a good idea. But I think there may well be 
> web apps that depend on top-level frame names being visible in all 
> windows, particularly "enterprise" apps which are generally only 
> deployed on intranets. It is worth doing some research to find out if 
> this is the case and determine the scope of the dependency. Perhaps it 
> could be limited to one top-level frame namespace for the set of windows 
> from a single domain.

The spec does reset the name of top-level browsing contexts when 
navigating to other origins.


On Sat, 28 Apr 2007, Smylers wrote:
> Spartanicus writes:
> > 
> > Would perhaps a spec conformance requirement that browsers should 
> > offer users a config option to opt out of windows being opened via 
> > target values be an alternative?
> > 
> > It could avoid the seemingly unwin'able argument with authors who 
> > insist on doing this, and give users the final say

The spec now encourages it, but we can hardly require it.


> Surely whether target="_blank" or even target="help" is treated 
> different from target="top" can at best be a hint?  Surely it isn't a 
> requirement of HTML that user-agents implement multiple content windows?

Actually the spec goes into some detail about what is required.


> That may not be appropriate for some environments, perhaps:
> 
> * terminal-based browsers, such as Lynx
> * One Laptop Per Child UI, where everyting runs full-screen
> * mobile phone browsers
> * televisions with web access

I believe all of these are catered for.


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! :-)


> 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, and that the second is basically impossible to implement 
reliably due to scripting (though Safari tries).

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