Add user settings for how external links open

[aligoren]

Is your feature request related to a problem? Please describe.

Some posts like this contain external links. When you're reading an article you click an external link. Before you finish reading the article, you are redirecting to the external link.

If you aren't using a browser extension, this could be a bad experience for you.

Describe the solution you'd like

I'm not good at Ruby. Perhaps this can be easily handled in Ruby. But as I said, I don't have any experience with Ruby. So, my solution will be with Javascript.:

const linksOpenNewTab = () => {
	const links = document.querySelectorAll("#article-body a")
	
	Array
		.from(links)
		.filter(filteredLink => !filteredLink.href.includes(window.location.href))
		.forEach(link => {
			link.setAttribute("target", "_blank")
			link.setAttribute("rel", "noopener noreferrer")
		})
}


linksOpenNewTab()

Describe alternatives you've considered

I've no any idea. But there should be many solution in Rails.

[rhymes]

I thought so too years ago but I was convinced otherwise by a designer I had a conversation with and also by my own behavior (this is not statistically valid of course :D).

The default behavior of a link is to open in the current tab, the user knows that by meta-clicking they can send the link to a new tab (mine open in the background for example, so I can keep reading without that annoying jump to a newly opened page). In addition: on mobile people know that by long pressing they can decide to open the link in a new tab, if all links were to open a new tab it would be weird. Also, a user might legitimately want to move on from your content (considering the fact that most browsers now save the scrolling coordinates of the previous page and put you back there when you click back)

If you set all links to open in a new tab then all links open in a new tab, regardless of the wishes of the user.

If you notice, most websites that open all links in new tabs do it to minimize the chances that a user would leave the page (and some, even more annoyingly, use those warning pages saying "hey, you're about to leave xyz, are you sure?").

Chris Coyier gives more pros and cons on opening links in new tabs: When to use target=”_blank”.

To me it was reframed like that.

[aligoren]

In this example, there are two kind visitors. People who want to open link in new tab and people who want to link in the current tab.

I agree with you, the default behavior is important. I always open links to read later. Which means, I still keep reading the article.

I read below part now:

"Reading an article", in my opinion, doesn't qualify here. Since it's (generally) so easy to get back to (most browsers even scroll down to where you were), there is no risk of real loss, and readers are really skimmers anyway.

That makes sense to me.

[jessleenyc]

Yeah, I think this is one of those issues that's hard to get right because people simply want different functionality. With that said, we could potentially have this be a preference you toggle in your settings.

[aligoren]

we could potentially have this be a preference you toggle in your settings.

Actually, that makes more sense. I agree.

[Hamatti]

This is one of those topics that I have weirdly strong opinion in favor of using target=_blank on external links even though I don't think it's the better way.

In this example, there are two kind visitors. People who want to open link in new tab and people who want to link in the current tab.

This is the reason why I'm having hard time justifying my own opinion. If we don't have target=_blank, both visitors can get their functionality: first one with cmd+click (or right click open to tab, long-press on mobile or which ever method they use) and the second one just by clicking the link.

If we do have target=_blank on, I don't think there's any way for a user to prevent that so only the second visitor will get what they wish for.

[maestromac]

That's a good point @Hamatti

[Link2Twenty]

first one with cmd+click (or right click open to tab, long-press on mobile or which ever method they use)

Or middle clicking 😉

[eusonlito]

As a regular dev.to visitor, please add target="_blank" to external links, or at least, to links to images.

I open the links as two ways:

1. Click on external link (relevant to article), read article and close tab. Then I'm on dev.to article in exact last position before click.
2. Ctrl+Click to continue reading dev.to article while external link is opening (not relevant to article).

I think that browsers without tabs are very far on time, and dev.to (as an interesting dev place) should mantain users inside.

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue in 7 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If this issue still requires attention, please respond with a comment. Happy Coding!

[maestromac]

not stale

[jessleenyc]

I just updated the title of the issue so it reflects what I think is the most reasonable next step here, allowing users to decide how they want links to open up.

[lkreimann]

Please be aware, that target="_blank" can be security risk for the user if not implemented right. See https://dev.to/ben/the-targetblank-vulnerability-by-example for more info.

My personal opinion: I would always leave the decision to the user if it is wanted to open a link in an new tab or not. You can easily open links in a new tab by pressing Ctrl while clicking on a link (at least on OS like Ubuntu and Windows).

[cmgorton]

Hello! Thanks for your contributions here. This seems like an issues that needs a lot more discussion and consensus from everyone.
We have a new process moving forward to address feature requests and especially those that have been in our repo for 1+ years without much traction. 

TLDR: we have new internal RFC process for feature requests. Any features that are more substantial and require more thought and detail will need to be discussed in forem.dev.

You can read more about our Internal RFC Process and forem.dev Discussions in this post.