W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2007

[whatwg] Target Attribute Values

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 28 Apr 2007 02:27:04 -0700
Message-ID: <AD8A5F42-3097-428D-AE66-5C16387A40A6@apple.com>

On Apr 28, 2007, at 2:04 AM, Matthew Paul Thomas wrote:

> On Apr 28, 2007, at 4:12 PM, Maciej Stachowiak wrote:
>> ...
>> One valid reason to use _blank instead of a named target to open a  
>> new window is the fact that the top-level frame namespace is  
>> global, and you don't want to collide with windows opened by other  
>> web apps, or even other instances of your own web app.
>> ...
> 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? :-)

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.

Received on Saturday, 28 April 2007 02:27:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:54 UTC