[whatwg] Proposal for Links to Unrelated Browsing Contexts

[Charlie Reis]

On Tue, Aug 28, 2012 at 9:39 AM, Glenn Maynard <glenn at zewt.org> wrote:
>
> On Tue, Aug 28, 2012 at 11:18 AM, Charlie Reis <creis at chromium.org> wrote:
>>
>> There are two main differences from the rel=noreferrer feature.  First
(as
>> you note), this does still send the referrer.  That's useful for sites
that
>> don't want to be affected by the newly opened page but that still rely on
>> referrers for analytics.  From my earlier examples, that might include
>> links in social networks (where the social network might want to be seen
as
>> the source of the referral) or links between apps on the same domain.   I
>> suppose it could also be useful for ads.
>>
>> The other difference is that this proposal supports script-initiated
>> navigations, such as window.open(url, "_unrelated").  Gmail is one case
>> that depends on using JavaScript to open links from email messages, and
so
>> it cannot use the rel=noreferrer syntax.
>
>
> That's not a difference between "unrelated" and "noreferrer", though.  It
applies to noreferrer, too.
>
> I had to do this recently (a script-initiated rel=noreferrer navigation).
 FYI, I worked around it by creating a temporary HTMLAnchorElement, setting
its href and rel properties and calling click().  A way to do this directly
with window.open would be nice, but it's orthogonal to noreferrer vs.
unrelated.
>
> --
> Glenn Maynard
>

That's a fair point, actually.  It would be possible to use noreferrer from
script code (if somewhat inelegant).

It's also worth noting that this proposal's cleaner syntax for window.open
has no way to block the referrer if that's what the developers wanted.
 That means they'd have to choose between cleaner window.open syntax that
passes the referrer or the workaround approach that blocks it.

To be honest, I haven't heard strong enough support for the allow-referrer
case to justify this proposal on the basis of "cleaner syntax" alone.
 Maybe we should table the discussion unless a stronger use case arises?

(I'm aware that this doesn't resolve the question of whether named windows
should be discoverable outside their unit of related browsing contexts.
 Perhaps that can be discussed further separately.)

Sound reasonable?
Charlie

ps-- I'll be away from email from tomorrow until September 12, but can
follow up with any further discussion after that.