rel=noopener for <form> and <base> elements

[ondras]

The rel=noopener is currently available only for <a> and <area> elements. I suggest adding this attribute-value pair also to:

• <form> element, as it is well possible to have a <form target=_blank> which creates the window.opener binding in the newly created context (tested in Firefox 55);
• <base> element, which can be already used to specify a target=_blank globally for all links. Having a way to make all these links noopener would be consistent with the current <base> usage.

[annevk]

cc @mikewest @mystor

[mystor]

Adding noopener to the <form> element seems like a relatively straightforward improvement, though it does open up the question of what other rel attributes should be exposed there.

My first concern about the <base> element would be that a page which had set <base rel="noopener"> would have no way to specify a link as one which is not noopener. I'm not sure if that's a use case which we want/need to support however.

I'm also curious about <base>'s interaction with window.open, if you write window.open("https://google.com") in a <base rel="noopener"> page, for example, one might expect the newly opener window to not have window.opener set, and for window.open to return null.

[annevk]

It wouldn't work for window.open(). We don't use <base target> values there either.

[ondras]

what other rel attributes should be exposed there.

Would it be possible to start with just the noopener and add others if that becomes a thing?

My first concern about the element would be that a page which had set would have no way to specify a link as one which is not noopener.

Good catch. Perhaps an opener value might be usable to override?

I'm not sure if that's a use case which we want/need to support however.

Our services use a pop-up login window facility that depends on .opener to work at all, so I think this use case is relevant.

[annevk]

Other than noopener and noreferrer, are there any values that would have an actual impact? I guess with <base> the problem might be how it affects <link>? That does indeed seem rather unfortunate.

[gcbw]

<base> support is a nobrainer. The original gecko feature ticket people even wonders why not add noopener by default with opt-out instead https://bugzilla.mozilla.org/show_bug.cgi?id=1222516#c4

This will help when well behaved ads, for example, using regular <a> links to compromised landing pages. Won't help much if the actual ad is compromised though.

[annevk]

Mozilla would like to add rel support to <form>. In particular to enable non-auxiliary top-level browsing context creation.

@cdumez is this something Apple would like to do as well? @tkent-google @creis Google?

(<base> is too involved as it would also have to impact <link>, which creates a mess.)

[cdumez]

Yes, I support adding rel to form.

[csreis]

Adding rel=noopener support to <form> makes sense from my perspective. @mikewest, sound good to you?

[tkent-google]

This is a reasonable change.

[sideshowbarker]

I strongly support adding noopener behavior to form but I think rel is the wrong syntax for adding it.

I propose that for form we instead add a new boolean noopener attribute.

The fact that we previously made the bad design choice of using rel for noopener behavior for the a element shouldn’t be used as a precedent. It was a mistake to use rel for noopener behavior to begin with, and we shouldn’t now further propagate that mistake.

[mikewest]

I think adding the functionality is pretty reasonable. I don't have strong opinions about how exactly we spell it: rel or a boolean attribute both seem fine to me.

On the other hand, I'm not at all enthusiastic about extending <base>. If folks want the ability to set a default policy for a page or site, I hope we can align on some out-of-band mechanism instead (origin policy or feature policy seem like good targets).

[annevk]

@sideshowbarker I don't know about that. For #4078 Safari is shipping opener as value and Firefox is following. I suspect we want that on <form> if we do the _blank defaulting on <form> as well. We might also want to support noreferrer here if we keep its semantics as a strict superset of noopener. Given that, rel seems like the obvious choice, also because <form> basically is <a> in terms of behavior (it navigates).

[sideshowbarker]

For #4078 Safari is shipping opener as value and Firefox is following.

Yeah, I guess it’s a lost cause if we keep getting stuck with changes to the HTML language happening in way that preempts any opportunity for web developers and the wider community to ever have a chance to weigh in on what would be the preferred way to hook the feature into the language.

It seems to me we generally don’t end up with the best designs for the long term when one browser project “experiments” with unilaterally making some change to the language that they decide on their own is the most convenient hook for hanging some new UA behavioral change on — and then another browser project goes ahead and implements it. What we end up with instead is technical debt.

What we’ve been doing with rel for this stuff is pretty clearly not what rel was originally intended for — what its semantics were before we started shoehorning things like this into it. But like I said, I guess it’s a lost cause now since we’ve already ended up polluting rel to the point where its semantics are that it’s now just a general extension point for declaratively controlling a (growingly disparate) range of browser behavior.

I suspect we want that on <form> if we do the _blank defaulting on <form> as well.

What we want is to associate some behavior with <form>. From that it doesn’t necessarily follow that we want or need to use the same (poorly considered) syntax choice used previously to associate the behavior with a different element.

In the case of associating behavior with the <a> element I guess the reason chosen to hook this (and other features) into rel was that the <a> element already had a rel attribute. So I guess the rationale was that it was more convenient or easy or whatever to drop it into rel rather than adding a new attribute for it.

But in this case the form element doesn’t already have a rel attribute. So this change is very different from the <a> change in that it’s adding a whole new attribute to the element that it’s never had before — rather than repurposing or extending some existing attribute it already has. And along with that, it’s going to pull in all the rest of the spec complexity of the Link Types machinery onto form.

We might also want to support noreferrer here if we keep its semantics as a strict superset of noopener.

If that happens then it would be better to add the capability to <form> with a new noreferrer boolean attribute instead.

Given that, rel seems like the obvious choice, also because <form> basically is <a> in terms of behavior (it navigates).

rel only seems like the obvious choice because of us now being stuck forever with the precedent of having used rel to add it to the <a> element. It’s not at all obvious that using rel to begin with was objectively the right design choice. It’s not written in stone anywhere that we have no choice but to keep on uncritically proliferating that design choice. We’ve imposed it on ourselves. We can choose to un-impose it.

Anyway I’m resigned to the likelihood that the facts that have been put on the ground here mean that I’m just tilting at windmills on this. But I do hope that in making future decisions we can find a way to avoid ending up imposing further technical debt like this — avoid painting ourselves into a corner the way that’s happened with rel.

[annevk]

Well, this is the first time I've seen someone complain about the way rel is used on <a>. Why didn't this come up when noopener was added on top of noreferrer? And again, I'd like to stress that I think precedent is somewhat important to follow here given how similar in behavior <a> and <form> ultimately are. Using an entirely new syntax will lead to confusion.

I also think it's not justified to say that the developer community did not get a say on #4078 while OP there obviously has a bunch of support, including from you, and thus far nothing negative in that thread.

[annevk]

A concrete proposal for this is now at #4332 by the way. It retcons form into a hyperlink (it navigates after all). This seems like the right approach and @sideshowbarker seemed more amenable to it after discussing it further out-of-band. Review appreciated. If someone wants to volunteer for writing tests that'd be even better!

[sideshowbarker]

A concrete proposal for this is now at #4332 by the way… This seems like the right approach and @sideshowbarker seemed more amenable to it after discussing it further out-of-band.

Yes

It retcons form into a hyperlink (it navigates after all).

Yeah I think that’s necessary if we’re gonna have rel there