WordPress.org

Make WordPress Core

Opened 15 months ago

Closed 3 months ago

#36809 closed enhancement (maybelater)

Remove target="_blank" checkbox in Advanced Link Modal

Reported by: mrwweb Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch dev-feedback
Focuses: ui, accessibility, administration Cc:

Description

I'd like to propose that the streamlining and usability improvements to the Link Modal started in #33301 be continued by removing or modifying the "Open Link in New Tab/Window" checkbox for inserting target="_blank" in the editor.

target="_blank" Should Rarely be Used

There are very few intended uses for target="_blank" and those that exist (such as when a form is the main content of the page) apply to few pages.

Additionally, when target="_blank", the best practice is that users should be given advance warning with text or an accessible icon, something almost never seen in the wild.

target="_blank" is a way for website builders to remove control of a website visitor's browser and is abused much more than it's appropriately used. (It also provides an attack vector for phishing attacks.) Chris Coyier has a great article listing the many bad reasons people do this. Unfortunately, this has become a fake "best practice." I think WordPress can do the internet an immense favor by making this harder to do.

Two Options for Changing this

Remove the Checkbox Entirely

This is my preferred solution. I believe that anyone who has the appropriate background knowledge to accurately assess when it's appropriate to use target="_blank" will also have the knowledge to use the Text editor to add it via HTML and meet the other usability requirements.

This seems consistent with the "decisions not options" philosophy of WordPress development. Given the rare usage of this feature it should be cumbersome to add. I suspect that the anger at losing this feature will be the primary reason given for not doing this, but I don't think that outweighs the numerous reasons given above. This isn't really that different from removing the title attribute textbox that gave 25%+ of the web a nudge toward better usability.

WordPress can make the web a better place where visitors have more control over their browsers with this change.

Make It Irritating to Use

If people aren't willing to entirely remove the target="_blank" checkbox, I believe that checking it should always trigger a modal window explaining when and when not to use target="_blank". This is intentionally irritating and it should be. If editors are insistent on interfering with their visitors browsing preferences, they should have to work to do it. Designing to annoy can be an effective technique, and this feels like an appropriate situation for doing so if removing the checkbox is considered unfeasible.

Attachments (2)

open-in-new-tab.png (33.9 KB) - added by rianrietveld 11 months ago.
Open link in new target in menus
36809.patch (1.1 KB) - added by kevinlangleyjr 7 months ago.
Adding rel="noopener noreferrer" to both links modal and nav menu walker

Download all attachments as: .zip

Change History (24)

#1 @ocean90
15 months ago

  • Component changed from General to Editor

This ticket was mentioned in Slack in #core-editor by iseulde. View the logs.


15 months ago

This ticket was mentioned in Slack in #core by ocean90. View the logs.


15 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


13 months ago

#5 @afercia
13 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

Discussed a bit in today's accessibility weekly meeting. While the intent is good, and we all would like people to forget target="_blank" even exists :), this can't be just removed. One thing that maybe could be reasonably added in the link advanced modal is a short description under the checkbox to inform and educate users, maybe with a link to a handbook page. Something like:

<a href="somehandbookpage/" target="_blank">Learn why opening links in a new tab/window can be problematic for accessibility</a>`

Any feedback for a better wording would be very welcome!

#6 @Presskopp
13 months ago

There's also a security concern

Example:
https://mathiasbynens.github.io/rel-noopener/

edit:
Uh, this was already mentioned, however, it's a nice example

Last edited 13 months ago by Presskopp (previous) (diff)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


13 months ago

#8 @helen
12 months ago

I am not convinced that messaging is going to change many minds about this, and is really pretty jarring in its dissonance - "here's why you shouldn't use this thing that we put right here". At the same time, removing it outright seems very likely to go over badly and use up a lot of time and energy just handling reactions, etc.

One thought while we're here - is it worth adding rel="noopener" in the name of keeping people safe? It doesn't cover everything but if that's going to stick as a standard then maybe we should have it.

#9 @Presskopp
12 months ago

We discussed this in german slack, I asked if we gonna use

rel="noopener noreferrer"

There seems to be no simple answer on using target="_blank" — how to use it, or if better not having it at all.

Last edited 12 months ago by Presskopp (previous) (diff)

#10 @azaozz
12 months ago

+1 to add rel="noopener noreferrer" to every link with target="_blank" too. Thinking this should be separated in its own ticket, and done in 4.7.

#11 @Presskopp
12 months ago

I made a ticket here #37941

#12 @Ipstenu
12 months ago

#37941 was marked as a duplicate.

#13 follow-up: @Ipstenu
12 months ago

@Presskopp - Just submit your patch in this ticket. No need for a second one.

#14 @rianrietveld
11 months ago

Related to this: setting a link target in menus
Maybe this is less used and can be removed without a lot of protest?

@rianrietveld
11 months ago

Open link in new target in menus

#15 in reply to: ↑ 13 ; follow-up: @SergeyBiryukov
11 months ago

Replying to Ipstenu:

@Presskopp - Just submit your patch in this ticket. No need for a second one.

This ticket is focused exclusively on the the "Insert/edit link" modal, while #37941 was for all target="_blank" links in the admin. I think this should be handled separately, per comment:10.

Also related: #23432.

#16 in reply to: ↑ 15 @NealMcConachie
10 months ago

Replying to SergeyBiryukov:

Replying to Ipstenu:

@Presskopp - Just submit your patch in this ticket. No need for a second one.

This ticket is focused exclusively on the the "Insert/edit link" modal, while #37941 was for all target="_blank" links in the admin. I think this should be handled separately, per comment:10.

Also related: #23432.

Agreed. From my clients' perspective, the security issue is arguably a more urgent (not necessarily more important, but definitely more urgent) requirement than the usability one. In the meantime, I'll apply the patch that @Presskopp provided, but it sure would be nice to prioritise this for an upcoming release.

Last edited 10 months ago by NealMcConachie (previous) (diff)

@kevinlangleyjr
7 months ago

Adding rel="noopener noreferrer" to both links modal and nav menu walker

#17 @kevinlangleyjr
7 months ago

  • Keywords has-patch dev-feedback added; needs-patch removed

#18 @SergeyBiryukov
7 months ago

  • Milestone changed from Future Release to 4.8

#19 @rockodev
4 months ago

I think this also needs to be implemented in post content links.

This ticket was mentioned in Slack in #forums by sterndata. View the logs.


4 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

#22 @joedolson
3 months ago

  • Milestone 4.8 deleted
  • Resolution set to maybelater
  • Status changed from new to closed

There are legitimate reasons to use target=_blank on links, so (from a discussion in the A11y team) we have doubts about whether this is really something we should be doing. From an accessibility standpoint, the problem isn't whether or not links open in new windows; it's whether or not that behavior is disclosed to the user.

While opening a link in a new window isn't preferred, generally, it is a legitimate option.

We should possibly explore an option that would provide a means for people to disclose links that open in new windows more effectively and elegantly as a core option.

Note: See TracTickets for help on using tickets.