More about the performance "benefit" here: https://jakearchibald.com/2016/performance-benefits-of-rel-n...
About rel=noopener (2016)
11–20 of 48 posts
Re: About rel=noopener (2016)
#12Earlier quoted context omitted.
Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.
I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…
Re: About rel=noopener (2016)
#13Shouldn't this behavior be explicitly enabled, defaulting to disallowing it? Or do I need to tag all my links with a long series of "Don't allow this crazy thing", "Or that other thing", etc.
Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.
Re: About rel=noopener (2016)
#14Earlier quoted context omitted.
I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.
I suspect the cost of breaking web compatibility intentionally to accomplish this goal would kill a browser, as authentication, payment, and many other things would suddenly break.
Re: About rel=noopener (2016)
#15Shouldn't this behavior be explicitly enabled, defaulting to disallowing it? Or do I need to tag all my links with a long series of "Don't allow this crazy thing", "Or that other thing", etc.
Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.
Re: About rel=noopener (2016)
#16Earlier quoted context omitted.
I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.
I doubt this behaviour comes purely under html anyway as its only usable from the javascript environment.
More likely is a content security policy... oh looke there: https://w3c.github.io/webappsec-csp/#directive-disown-opener
Re: About rel=noopener (2016)
#17Shouldn't this behavior be explicitly enabled, defaulting to disallowing it? Or do I need to tag all my links with a long series of "Don't allow this crazy thing", "Or that other thing", etc.
Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.
Browsers deprecate security related features all the time. See SSL, HSTS [EDIT: HPKP*], etc.
At the very least, browsers could remain backward compatible but mark the URI as “Insecure” in the address bar if the link could result in tab hijacking. Although on second thought, that would be challenging because it would require parsing the source of all links.
Re: About rel=noopener (2016)
#18Earlier quoted context omitted.
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.
HTML 2.0 was published in 1995. I doubt this behaviour comes purely under html anyway as its only usable from the javascript environment. More likely is a content security policy... oh looke there: https://w3c.github.io/webappsec-csp/#directive-disown-opener
Re: About rel=noopener (2016)
#19Earlier quoted context omitted.
in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.
Internet Explorer tried to maintain multiple rendering engines. Every version from IE5 to IE11 (if you open the debug console you can switch rendering modes) And now they have Edge. It never took off. I suspect the cost of breaking web compatibility intentionally to accomplish this goal would kill a browser, as authentication, payment, and many other things would suddenly break.