Skip to content

Open every link in the same tab - #77

Merged
narthur merged 2 commits into
masterfrom
fix/consistent-link-targets
Aug 18, 2026
Merged

Open every link in the same tab#77
narthur merged 2 commits into
masterfrom
fix/consistent-link-targets

Conversation

@narthur

@narthur narthur commented Aug 18, 2026

Copy link
Copy Markdown
Owner

The footer was the only place external links stayed in the same tab. Rather than make the footer match the rest of the site, this makes the rest of the site match the footer — following current best practice, which is to default to same-tab navigation regardless of whether the destination is external, and reach for target="_blank" only where it protects in-progress work (a form, an editor, a checkout).

This site has none of those. "It's external" was the only justification, and that isn't enough: a new tab takes control away from the reader, and anyone who wants one can middle-click.

What changed

target="_blank" and rel="noopener noreferrer" removed from every link in src/. Verified across the built output: 84 anchors, 74 of them external, none carrying target or rel.

rel="noreferrer" was not harmless

Worth calling out separately, because it was quietly costing something. Unlike noopener, noreferrer applies to same-tab navigation too — it suppresses the Referer header unconditionally. So every click through to Substack, Pine Peak Digital or Stack Overflow arrived with no referrer, and none of those could attribute the traffic to nathanarthur.com.

That's the opposite of useful given the open question of whether this site sends anyone anywhere. If a link ever does need a new tab, the rule is now rel="noopener" — never noreferrer — plus a visible cue in the label.

Falls out for free

Both isExternal helpers existed only to decide target, so both are deleted, along with the duplication between the copy in +page.svelte and the one in +layout.svelte.

Accessibility

A net improvement. Unexpected new-tab navigation without warning is a documented WCAG failure mode (SC 3.2.5), and there were no "opens in new tab" cues anywhere to make it safe. Removing the behaviour removes the problem rather than papering over it.

Notes

knowledge.md records the same-tab rule and what to do if an exception is ever needed. The repo's review learnings previously required target="_blank" on external links (a convention from PR #75) — that entry now records the reversal, so future reviews don't flag this as a regression.

Judgment call worth surfacing: the footer carries a newsletter email field on every page, which is technically "a form" under the best-practice exception. I didn't treat it as one — a single optional email input isn't in-progress work worth protecting, and the back button covers it.

pnpm lint, pnpm check, pnpm test and pnpm build all pass.

🤖 Generated with Claude Code

narthur and others added 2 commits August 17, 2026 20:24
The footer was the only place external links stayed in the same tab. Its four
external links (Substack, Pine Peak Digital, Stack Overflow, Ko-fi) now carry
target="_blank" and rel="noopener noreferrer", matching the convention set on
PR #75 and used everywhere else on the site.

The internal /uses link previously carried rel="noopener noreferrer" with no
target, which did nothing; it now carries neither.

Verified across the whole built site: of 84 anchors, all 74 external ones have
target and rel, all 10 internal ones have neither, and nothing is mismatched.

The rule is now written down in knowledge.md, since it drifted silently once.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reverses the previous commit on this branch. Current best practice is to default
to same-tab navigation regardless of whether the destination is external, and to
reach for target="_blank" only where it protects in-progress work — a form,
editor, or checkout. This site has none of those, so "it's external" was the only
justification and that isn't enough: a new tab takes control away from the reader,
and anyone who wants one can middle-click.

Removes target="_blank" and rel="noopener noreferrer" from every link in src/.
Verified across the built site: 84 anchors, 74 of them external, none carrying
target or rel.

Two things fall out of it:

- rel="noreferrer" was not harmless. Unlike noopener, it applies to same-tab
  navigation too, so it was stripping the Referer header and preventing Substack,
  Pine Peak Digital and Stack Overflow from seeing this site as a traffic source.
  That is the opposite of useful when the open question is whether this site
  sends anyone anywhere. (I earlier described the footer's rel-without-target as
  inert; that was wrong for the noreferrer half.)
- Both isExternal helpers existed only to decide target, so both are now deleted
  along with the duplication between them.

knowledge.md now records the same-tab rule and what to do if a link ever does
need a new tab: rel="noopener", never noreferrer, plus a visible cue.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 18, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@narthur, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 45 minutes

Limit details: You’ve used all 1 included review currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Repository: narthur/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 0ba2d7dd-2bee-4c20-93c1-dbfee64e1911

📥 Commits

Reviewing files that changed from the base of the PR and between 1f17171 and 23a2185.

📒 Files selected for processing (6)
  • knowledge.md
  • src/routes/+layout.svelte
  • src/routes/+page.svelte
  • src/routes/audioverse/+page.svelte
  • src/routes/uses/+page.svelte
  • src/routes/writing/+page.svelte

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@narthur
narthur merged commit 1b68784 into master Aug 18, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant