#46323 closed enhancement (duplicate)
Should Codex/HelpHub links be treated as external links
| Reported by: | garrett-eclipse | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Administration | Version: | |
| Severity: | normal | Keywords: | target-blank |
| Cc: | Focuses: | ui, accessibility |
Description
Hello,
Came across the codex links for Cookies when reviewing #46254 and thought they should be external links.
There's loads of codex links in WP and am wondering if they should open in a new tab with the security rel set for noopener.
I found the CSS codex link does open in a new tab and has screenreader text;
https://github.com/WordPress/WordPress/blob/d9a1f99d9ce352a0e151169c3612b00c4c146ddf/wp-includes/class-wp-customize-manager.php#L5567-L5573
Along with adding the rel="noopener noreferrer" should we make other doc links open in a new tab?
Thanks
Change History (5)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
#3
@
8 years ago
- Milestone Awaiting Review
- Resolution → duplicate
- Status new → closed
Duplicate of #23432.
Thanks @afercia that's awesome. I'm all for removing target _blank where not absolutely necessary.
Both of these cases make sense to leave without the new tab effect so am closing this as a duplicate.
And I see you already commented about the Customizer example in the other ticket here;
https://core.trac.wordpress.org/ticket/23432#comment:53
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
See https://core.trac.wordpress.org/query?keywords=~target-blank for related tickets. Blessed task: #23432.
There's an ongoing effort to remove from core as many
target="_blank"attributes as possible. For example, the ones in the Help tabs have been removed. Many are still to address.Only in rare cases a
target="_blank"attribute might make sense. In most of the cases, we should just stop taking control of users' browsers :)