chore(ui): make package name selectable

[Adebesin-Cell]

Fixes #568

The package name in the header was difficult to select, especially for scoped packages, because it was split across interactive elements.

This PR refactors the header so the package name is rendered as plain text and is easy to select across all browsers. Clicking the package name still copies it to the clipboard, but the copy action is now suppressed when the user is actively selecting text, allowing normal text selection without accidental copies.

BEFORE:

Screen.Recording.2026-02-01.at.01.44.21.mov

AFTER:

Screen.Recording.2026-02-01.at.08.35.47.mov

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 1, 2026 2:06pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 1, 2026 2:06pm
npmx-lunaria	Ignored		Feb 1, 2026 2:06pm

[danielroe]

this is a good change, but I'm not wild about adding ui elements to this part of the page.

copying the package name is nice but 'discoverable' because you'd click on it anyway to copy it. can you think of another solution that isn't an extra icon/button?

[Adebesin-Cell]

this is a good change, but I'm not wild about adding ui elements to this part of the page.

copying the package name is nice but 'discoverable' because you'd click on it anyway to copy it. can you think of another solution that isn't an extra icon/button?

Good point!

I’ve updated the implementation to remove the extra icon/button entirely. The package name itself is now the click target for copying, but it’s rendered as plain text, so it can be selected normally. Let me know what you think!

[knowler]

I like that it’s more easily selectable considering before it wasn’t immediately clear that there was a button there (presentational-to-semantic mismatch). With that said, it’s still acting like a button without any of the semantics. Users navigating by keyboard now have no way to copy the name (and tabindex=0 is not a good solution here, because then we need a role which opens up another can of worms which will get you back at a <button>). A screen reader user could copy the name, but it won’t be clear to them that they can. I think more conventional accessibility wisdom would say:

• Don’t wrap any part of the package name with a <button> element (since it’s not visually presented as a button—an affordance of text is selectability).
• If a copy shortcut is being provided, include it as a button separate from the heading text to avoid making this unselectable.

We don’t have to follow that conventional wisdom, but then that’s going to take a bit more intentioned research and design.

[danielroe]

what about adding a button that's has aria-text, is in the tab order and is only visible when tabbed to, a la skip to content?

here's my thinking:

copying a package name is a minor enough benefit we don't care if users know about it - they can discover it if/when they go to try to select the text... and adding an additional button-with-icon is not worth the visual distraction in this area.

[knowler]

what about adding a button that's in the tab order but only visible when tabbed to, a la skip to content?

I think the least bad option given the current design and avoiding clutter would be to do something like this and you could even reveal said (perhaps visually labelled) button for sighted/mouse users when they hover the area. That could ensure folks could use the package scope link, select the package name, and have a distinct button to copy the package name.

Where that falls short for accessibility purposes is that you aren’t really supposed to make stuff only show up on hover for various reasons (it also affects touch users who often can’t hover). It fails the “perceivable” principle of WCAG, but like I said, I think it could be the least bad option at least for now (doing weird things with UI overlap/omitting semantics is worse IMO).

And I guess, even without a persistently visible labelled button, sighted mouse/touch users still do have the affordance of the text itself which they know they can select and copy, so it’s not like their access is being impeded.

[Adebesin-Cell]

Quick sanity check before I tweak this again, would a real copy button that’s keyboard-accessible but only visible on focus (skip-link style, maybe also on hover) be an acceptable direction?

Or would you prefer dropping the copy interaction altogether and just relying on normal text selection?

cc: @danielroe

[danielroe]

let's go for the button, for now

happy to remove the functionality later if there are a11y concerns but my reading of @knowler s comments indicates we are just about OK here

[Adebesin-Cell]

#568

Screen.Recording.2026-02-01.at.12.24.28.mov

Looks like this now!
Thinking about mobile devices, the copy button currently relies on hover/focus to appear. Do you think we should adjust the behavior for touch users, or leave it as-is for now?