Allow leeway when choosing hyperlink targets in special contexts

[daogottwald]

It has been brought up in https://bugzilla.mozilla.org/show_bug.cgi?id=1562547 that for pinned tabs, Firefox violates the rules for following hyperlinks, by opening targetless cross-origin links in a new tab instead of in the pinned tab itself. This is intentional behavior in Firefox, to lock pinned tabs at their original domain. I believe the spec should allow this kind of deviation from the default behavior.

[chris-morgan]

I think the natural implementation direction of such a change would be these three steps, one for each of the places where _self is mentioned:

• Extend “valid browsing context name or keyword” to allow an empty string, so that <base target=""> and <a target=""> would be valid, and the default value. (This allows esoteric behaviour like <base target=_self> paired with <a target> on the odd occasion where you might actually prefer the browser’s default behaviour rather than _self.)
• Adjust the description of the ordinary effect of the empty string in the table below that.
• Distinguish between _self and the empty string in “The rules for choosing a browsing context”.

The spec never calls _self the default, but MDN definitely does, and I expect other sources that talk about targets do; all such sources would then need to be updated to reflect the change (which, as noted, is already reality in Firefox).

[annevk]

https://html.spec.whatwg.org/#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name needs to be changed to always allow for creating a new browsing context as a UX decision.

The current wording isn't even adequate for cmd+click. I suspect we basically want to give maximum freedom to browsers over the chosen browsing context as the distinction between the empty string and _self is only meaningful here, it's not with cmd+click.

(As far as I can tell #4197 did not regress this. It was broken then too.)