rustdoc: remove link on slice brackets

[notriddle]

This is #91778, take two.

Fixes #91173

The reason I'm reevaluating this change is #97668, which makes fully-generic slices link to the slice docs page. This fixes some downsides in the original PR, where Box<[T]>, for example, was not linked to the primitive.slice.html page. In this PR, the [T] inside is still a link.

The other major reason for wanting to reevaluate this is the changed color scheme. When this feature was first introduced in rustdoc, primitives were a different color from structs and enums. This way, eagle-eyed users could figure out that the square brackets were separate links from the structs inside. Now, all types have the same color, so a significant fraction of users won't even know the links are there unless they pay close attention to the status bar or use an accessibility tool that lists all links on the page.

[rust-highfive]

r? @GuillaumeGomez

(rust-highfive has picked a reviewer for you, use r? to override)

[eggyal]

I said it on the original issue and I'll say it again here: I do find those links to slice docs occasionally useful—I don't entirely understand what is to be gained from removing them?

[GuillaumeGomez]

I think the problem is that for [u32], either you click on u32 or the brackets, you end up on different pages and there is no UI distinction. Am I right @jsha? If I guessed it right, shouldn't we underline it on hover instead?

[notriddle]

@GuillaumeGomez

If I guessed it right, shouldn't we underline it on hover instead?

• That won't work on touchscreens.
• It requires someone to pay very close attention to the exact span of the underline, which is a bit much to expect.
• In a lot of web pages, there won't be any visible underline below square brackets in any case, if they have text-decoration-skip-ink turned on and use a font where square brackets descend below the baseline. Even if we turn that off in rustdoc, we can't expect people to know that we turned it off.

@eggyal

I don't entirely understand what is to be gained from removing them?

It should reduce misclicks.

[eggyal]

Okay, well it's not something I'm going to lose any sleep over though it is a minor niggle.

Maybe there's an alternative solution to the problem of ambiguous links? I rather like a recent update in VSCode that is colouring brackets differently according to their nesting depth (it cycles over three colours): perhaps the same might be a solution here, where each level of type nesting is coloured differently?

[GuillaumeGomez]

Apart from the debate, the code changes look good to me, thanks!

Let's just wait confirmation from @jsha and then it's good to go. :)

[jsha]

I agree with @notriddle's assessment. Single-character links are hard to click for anyone who doesn't have precise mouse control (for example consider tremors) and high visual acuity. And putting multiple links adjacent to each other makes it hard to discern where one begins and the next ends, making it easy to accidentally click the wrong one. Also: this allows the type inside the brackets to visually stand out better.

FWIW, there will still be a good number of links to the slice page: they will show up any time the slice is fully generic, as @notriddle says in the PR description. For instance, Vec's as_mut_slice:

I realize that probably doesn't cover every where you've found a link to the slice docs useful, @eggyal, but hopefully it provides at least some on-ramps.

Another change we've been discussing separately that might help: It would be nice search across std's items from any rustdoc output. That would allow a very quick way to access the slice page: s (to focus the search box), [ (to search for slice).

@bors r+ rollup

[bors]

📌 Commit 682889f has been approved by jsha