rustdoc: Add search result item types after their name

[GuillaumeGomez]

Here what it looks like:

The idea is to improve accessibility by providing this information directly in the text and not only in the text color. Currently we already use it for doc aliases and for primitive types, so I extended it to all types.

r? @notriddle

[rustbot]

Some changes occurred in HTML/CSS/JS.

cc @GuillaumeGomez, @Folyd, @jsha

[notriddle]

Mostly, this seems fine, though as a UI tweak it'll go through FCP just like all the others.

[GuillaumeGomez]

Added the GUI test for the added type kind text color.

[notriddle]

@rfcbot fcp merge

[rfcbot]

Team member @notriddle has proposed to merge this. The next step is review by the rest of the tagged team members:

• @GuillaumeGomez
• @Manishearth
• @Nemo157
• @aDotInTheVoid
• @camelid
• @jsha
• @notriddle

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[bors]

☔ The latest upstream changes (presumably #111552) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Fixed merge conflict.

[jsha]

Thanks for working on this! I have a little feedback on the UI: instead of having the item type in parentheses right after the name, it should get its own column. We'd have effectively a 3-column layout, similar to a table, but not implemented as a table because we want each row to be wrapping in an <a>. The columns should be: name, item type, short description.

Reasoning: The primary task, most of the time, is skimming the list of results for the item name you want. Since the item name is (often) more important than the path, this involves skimming along the right-hand edge of the list of names. Adding something in parentheses along the right-hand edge makes that skimming a little more annoying.

Another alternative would be a different ordering: item type, name, short description. This would have the advantage of being somewhat like source code, but we would still want a columnar display so all the names line up vertically, and that would make it look less like source code. I think the overall effect would be slightly worse.

[GuillaumeGomez]

I prefer to have the type name before. It looks like this:

What do you think @jsha ?

[GuillaumeGomez]

Fixed the eslint error too.

[notriddle]

What's it like on mobile?

[GuillaumeGomez]

I didn't even think about it. It's quite ugly:

[GuillaumeGomez]

I pushed the doc online so you can test it here.

I also improved the mobile display:

I also gave a try to check with italic rendering:

And with bold:

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[homersimpsons]

(I am not an UI expert)

I feel that this change introduces a lot of verbosity solely to make clearer what the colors are. I personally think this may not be the best solution.

Some solution I can think of (may be combined):

• Add a color legend at the top, if there are not too much color kind it could be fine, the user will certainly have a quick look at it and just remember it for later
• Add a title attribute on the colored portion to precise wether this is a module / function etc ... As this is a link there are high chances the user will discover it alone but this doesn't really make its clear that this is similar as the color
• Use a shorter abbreviation with a title, it would work well with fn, mod, struct but re-export would certainly need another wording
• Use a one-letter abbreviation f, m, s, r... With a title attribute and inline it with the text (if it has a monospace font)

Once again I am not an UI expert, but from the screenshots I feel we are overloading the UI without adding information as we are just duplicating existing information.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[GuillaumeGomez]

@jsha What do you think of @notriddle's suggestion?

[GuillaumeGomez]

Let's merge for now, we can change the text formatting in a follow-up PR.

@bors: r=notriddle,jsha

[bors]

📌 Commit de85f7f has been approved by notriddle,jsha

It is now in the queue for this repository.

[bors]

⌛ Testing commit de85f7f with merge 6a94e87...

[bors]

☀️ Test successful - checks-actions
Approved by: notriddle,jsha
Pushing 6a94e87 to master...

[rust-timer]

Finished benchmarking commit (6a94e87): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.3%	[-4.8%, -1.4%]	9
Improvements ✅ (secondary)	-2.5%	[-2.7%, -2.2%]	2
All ❌✅ (primary)	-3.3%	[-4.8%, -1.4%]	9

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 648.664s -> 646.921s (-0.27%)