Port noopener.

[mikewest]

The noopener link relation is part of Secure Context's requirements, implemented by Chrome and Firefox, and @plehegar partially ported it (accidentally?) into HTML as part of 61663e2. It would be lovely to actually port it over in toto.

[mikewest]

Hrm. I was wrong about the commit. It was apparently part of the "Import" in a023b06. If that's the case, I'm very confused about where most of the definition actually went. :/

[chaals]

Hi Mike,

this is related to #170 and it seems a priori that we should integrate the link type, and refer to Secure Context for a definition.

In that context it would be helpful if you could let us know of other specs that extend HTML, so we can at least try to have the right set of pointers…

[chaals]

(In this case it seems we also have interop, so it's a pretty good candidate for an early draft of HTML 5.2)

[mikewest]

I'm not sure this is something that can be well-addressed via modularity. Secure Contexts does not define the behavior of the noopener link relation: instead, Secure Contexts relies on the behavior that noopener offers in order to explain its behavior in certain classes of navigation, see https://w3c.github.io/webappsec-secure-contexts/#example-30335756 for instance.

noopener's behavior is fairly deeply bound up with navigation and document creation algorithms. See step 4 of https://html.spec.whatwg.org/#following-hyperlinks-2 and step 13 of https://html.spec.whatwg.org/#dom-open (as well as the related changes around https://html.spec.whatwg.org/#disowned-its-opener).

Looking at Secure Contexts, again, however, I don't think we need noopener ported before we can advance. We only use it in an example; the normative work is done by checking a document's browsing context's opener browsing context which should be similar enough between the WHATWG and W3C documents.

[mikewest]

This is something that Secure Contexts doesn't rely on in a normative way, but certainly relies on in principle.

/cc @adanilo @hillbrad