-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustdoc: Align search results horizontally for easy scanning #112937
Conversation
The recent PR rust-lang#110688 added info about an item's kind before its name in search results. However, because the kind and name are inline with no alignment, it's now hard to visually scan downward through the search results, looking at item names. This PR fixes that by horizontally aligning search results such that there are now two columns of information.
Do you have a rendering of what the new results look like? Also, quite in favor of this change 👍 |
EDIT: This version is out-of-date. Please see #112937 (comment) for the final version. Note: I'm having an issue getting Rust to build on my computer right now, so the "after" screenshot was generated by applying the changes in Firefox dev tools. BeforeAfter |
color: var(--search-results-grey-color); | ||
font-size: 0.875rem; | ||
width: 6rem; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I picked this number arbitrarily. Two issues:
-
It would be nice if it weren't based on eyeballing the layout.
-
This isn't actually wide enough for "associated constant". If I increase this to 9em, it fits, but then all the other rows have excessive spacing. I see two solutions: one is to shorten the typename to just "constant", the other is to make the spacing somehow adaptive to what the longest typename is. But I'm not sure how to implement that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when it overflows? Does it wrap and just become a taller row? I think that honestly wouldn't be terrible if that's what happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:/ true -- i wonder if vertically center-aligning those rows would help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we really need to just keep rows a constant height. Variable height rows almost always look a bit off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something that could at least make them look better is to make sure both the path/name and short description are aligned the same, to the top or the middle as Michael suggested.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was able to avoid the wrapping by adding a tiny bit extra space.
The longest type name is |
@GuillaumeGomez could we shorten "associated constant" to just "constant"? I'm not sure if it really matters to users whether a constant is associated or free, and even aside from this change, it's quite a long word that distracts from the actual name of the item. |
I'd honestly rather shorten it to |
Abbreviation would be fine with me 👍 |
But EDIT: It's actually pretty useless to do since |
It looks nice like that. But remains the problem of |
Existential types have not been implemented yet I thought? Or I thought they're at least an experimental feature. |
"Existential type" is still shorter than "associated constant". We could shorten "existential type" to just "existential"? What is an existential type in this context actually? Is it |
@camelid: type alias impl trait ("existential type" in rustdoc i guess) is implemented, and we probably should account for them too |
We'd actually only need 7 rem (rather the current 6) to support "existential type" as it is. |
Why |
In non-monospace fonts, the letters are variable width, so you can't just multiply the font size by the number of characters. In addition, I believe the "em" in "rem" is referring to a value that is (approximately, sigh...) the width of an uppercase "M", which should be wider than the letters we're using. EDIT: Here's a demo of two strings with the same length but different characters (16 M's, which I believe is the correct length of "existential type"): Note: In case anyone's confused by "u8" being an existential type: I'm using browser dev tools to create this image ;) |
Can you just check what it gives with "existential type" please? (Just update the text, no need for a real one 😸 ) Also please show screenshots of a mobile view (just reduce the width). |
Let's maybe reduce a bit the margin after the type name? But otherwise looks good to me. 👍 |
Some changes occurred in HTML/CSS/JS. cc @GuillaumeGomez, @Folyd, @jsha |
👍 |
@bors r=GuillaumeGomez |
@bors rollup |
…meGomez rustdoc: Align search results horizontally for easy scanning The recent PR rust-lang#110688 added info about an item's kind before its name in search results. However, because the kind and name are inline with no alignment, it's now hard to visually scan downward through the search results, looking at item names. This PR fixes that by horizontally aligning search results such that there are now two columns of information. r? `@GuillaumeGomez`
Failed in #113004 (comment). You forgot to update a GUI test. ;) @bors r- |
Some changes occurred in GUI tests. |
Thanks! @bors r=notriddle,GuillaumeGomez rollup |
@bors r=notriddle,GuillaumeGomez rollup |
💡 This pull request was already approved, no need to approve it again.
|
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#112937 (rustdoc: Align search results horizontally for easy scanning) - rust-lang#112950 (DirEntry::file_name: improve explanation) - rust-lang#112956 (Expose `compiler-builtins-weak-intrinsics` feature for `-Zbuild-std`) - rust-lang#113008 (Move some docs from the README to the dev-guide) - rust-lang#113009 (Remove unnecessary `path` attribute) r? `@ghost` `@rustbot` modify labels: rollup
The recent PR #110688 added info about an item's kind before its name in
search results. However, because the kind and name are inline with no
alignment, it's now hard to visually scan downward through the search
results, looking at item names. This PR fixes that by horizontally
aligning search results such that there are now two columns of
information.
r? @GuillaumeGomez