Add ability to specify link target

[sdmcraft]

Expected Behaviour

Page authors should have the ability to specify the link target i.e. whether it opens in the same tab/ new tab etc in the authoring document.

Actual Behaviour

Currently there's no such ability. Developers need to implement custom logic for achieving this. For e.g. hlxsites/mmm-af@9dba400

Reproduce Scenario (including but not limited to)

Not Applicable

Steps to Reproduce

Not Applicable

Platform and Version

All

Sample Code that illustrates the problem

Not Applicable

Logs taken while reproducing problem

Not Applicable

[trieloff]

I don't think this is nearly as common enough to be left to authors. In most cases, sites can formulate rules such as "all external links should open in a new window except for these hostnames", so that no one-off decisions by authors are needed.

[sdmcraft]

@trieloff , I logged this ticket based on a discussion here wherein @davidnuescheler mentioned that this has come more than once and could be considered for inclusion in the bolierplate. If we feel that isn's the case or we need to reconsider, I can close this. Else perhaps an implementation like this can be ported here,

[rofe]

To @trieloff's point, the alternative would be to add a more generic solution (without author control) to open all external links in a new tab, e.g. like so.

[ramboz]

So the question seems to be if we can find valid use-cases for internal links to open in new tabs consistently.

From the top of my head, I can think of 3 use cases that could benefit from this:

1. Links to pdf, doc, xls, etc. would benefit from being opened in a new tab all the time as they represent a complete change of context (from an accessibility point-of-view, and would need to be combined with https://www.w3.org/TR/WCAG20-TECHS/G201.html)
2. Links to contextual documentation or glossaries could be opened in a named window/modal with # anchors to scroll to the right section immediately. I think that wouldn't work great with the proposed #_blank option, as we'd need to combine 2 anchors. Maybe something like SPA routers use: #<window-name>:/<anchor-name>, i.e. #_blank:/my-doc
3. Deep-linking into SPAs that have already complex anchors for their views. Thinking of unified shell for instance where we already have a pattern like https://experience.adobe.com/#/@<org>/<service>/<spa-path>, maybe again a pattern with: https://experience.adobe.com/#_blank:/@<org>/<service>/<spa-path>

And then there is a 4th… more gray area one:

4. Links to code samples, which may include css/js and would thus be hard to differentiate from the ones you'd want to download forcibly. That's probably more project-specific so harder to define a default behavior. But 2. & 3. could also address this.