-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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: use smaller number of colors to distinguish items #91480
Conversation
Some changes occurred in HTML/CSS/JS. |
r? @ollie27 (rust-highfive has picked a reviewer for you, use r? to override) |
I agree with @PatchMixolydic. They're close enough that it would make it confusing. Another thing I wonder is if we should group by "kind of types". For example (by groups):
I'm not too sure where to put primitives. Currently it's the same color as struct, enum and union, I guess it's fine as is. What do you think? |
(ugh, I hate GitHub on mobile) I think we should only have different colors for things that could be confused in the search page. Since the only things that can have the same name must be in different namespaces, that suggests that we should have one color per namespace (value namespace, type ns, macro ns). I like the idea of doing this with the symbols you'd see in the source (e.g. |
Good point about macros, particularly that not all macros are function-like, so styling as functions doesn't necessarily make sense. I've restored macros to having their own color. It was nice having just four colors, but since the primary motivation here is to make method signatures less distracting, and macros don't contribute to that problem, I think that's okay.
I think we rely too much on colors in the search page to distinguish types. If distinguishing types is important (and I think it is), we should put the type as text in the search results. That way it's accessible to colorblind people, and also understandable to people who haven't figured out what the colors mean (and it helps learn what the colors mean). But that's a change for another day. :-)
I like in theory the idea of mapping color distinctions onto a language concept (namespaces). This PR actually is pretty close to that. One difference: We still distinguish traits vs (enums, structs, unions), even though traits are also in the type namespace. I think the distinction between traits and other types is valuable and I'd like to keep it. Is there a specific change you'd like to make so colors align better with namespaces? |
(Updated the branch and the demo) |
When making a large UI change like this, please open a thread on Zulip so the whole team can discuss it :) |
Looks good to me as is. Thanks for working on this!
This is actually a very good point!
You're absolutely right, let's hear from others as well. cc @rust-lang/rustdoc |
jsha and I discussed the trait color on Zulip. I tweaked the trait color to match the "lightness" (see the Zulip thread for details on what that is) of the type color, and I think it looks more similar to the other colors now. The current plan is this:
(Note that the hyperlink color is not being changed AFAICT.) |
After some discussion on Zulip I've updated the branch and the demo to lighten the trait color from |
@camelid just to clarify - are macros using different colors for function-like and derive macros? Or is there only one color for the macro namespace? I don't know what the current behavior is. (Either seems fine to me, but seems good to clarify) |
@@ -11,7 +11,7 @@ reload: | |||
|
|||
assert-css: ("#toggle-all-docs", {"color": "rgb(0, 0, 0)"}) | |||
assert-css: (".fqn .in-band a:nth-of-type(1)", {"color": "rgb(0, 0, 0)"}) | |||
assert-css: (".fqn .in-band a:nth-of-type(2)", {"color": "rgb(173, 68, 142)"}) | |||
assert-css: (".fqn .in-band a:nth-of-type(2)", {"color": "rgb(173, 55, 138)"}) |
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.
Yikes, it's worrying that only one test had to change because of this massive color change ;)
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 more tests will be added. :)
There's just one color for all types of macros. |
That's a good point; macros aren't in the color palette IIRC. @jsha could you put the macro color in the palette instead of the unstable item-info color? |
already did, and updated the link above :-) https://color.adobe.com/rustdoc%20proposed%20theme-color-theme-19077288 |
This reduces visual distractions when reading method signatures.
This comment has been minimized.
This comment has been minimized.
I pushed a fix for an issue where associated types were incorrectly getting generated with I'm happy to write some tests for colors, but it's pretty error prone with browser-ui test as it is today. I filed GuillaumeGomez/browser-UI-test#227 for an update to make it easier to specify expected colors in the same way we specify them in the CSS (hex literals instead of rgba tuples). |
This comment has been minimized.
This comment has been minimized.
Looks good to me! I'll wait for the others who commented to take a look first but then r=me. |
@GuillaumeGomez said:
So far we have an approval from @jyn514. @camelid and @PatchMixolydic you were the others who commented. I believe I've satisfactorily addressed all your comments. Good to go? |
I haven't looked at this in a while, but I think it's fine to land this and make tweaks later. |
Looks good to me 👍 |
@bors r=GuillaumeGomez rollup |
📌 Commit 3f517fb has been approved by |
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#90383 (Extend check for UnsafeCell in consts to cover unions) - rust-lang#91375 (config.rs: Add support for a per-target default_linker option.) - rust-lang#91480 (rustdoc: use smaller number of colors to distinguish items) - rust-lang#92338 (Add try_reserve and try_reserve_exact for OsString) - rust-lang#92405 (Add a couple needs-asm-support headers to tests) - rust-lang#92435 (Sync rustc_codegen_cranelift) - rust-lang#92440 (Fix mobile toggles position) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
What is the formal process for requesting this to be all or partially reverted? The PR was a step backwards and universally disliked. Merging the color options makes things harder to find and understand. I've been looking for green text to identify enums in method signatures and now it's impossible. PR #92660 makes things even worse by combining them all into a single section. Having distinct colors and sections improves visibility and discovery. The first analogy that comes to mind are phone numbers.
|
I opened a discussion about it in https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/UI.20regression.3F. |
For anyone interested this has bothered me enough that I've created and been testing for a few weeks the following userscript to bring back colors to my rustdoc browsing: (You may use it via Tampermonkey on any major browser) |
This reduces visual distractions when reading method signatures.
As discussed in #59845 (comment), this categorizes items into one of six colors (down from thirteen):
#AD7C37
)#6E4FC9
)#AD378A
)#3873AD
)#068000
)#000000
)I slightly tweaked the actual color values so they'd have the same lightness (previously the trait color stood out much more than the others). And I made the color for links in general consistently use steel blue (previously there was a slightly different color for "search-failed").
The ayu and dark themes have been updated according to the same logic. I haven't changed any of the color values in those themes, just their assignment to types.
Demo:
https://rustdoc.crud.net/jsha/fewer-colors/std/string/struct.String.html
https://rustdoc.crud.net/jsha/fewer-colors/std/vec/struct.Vec.html
https://rustdoc.crud.net/jsha/fewer-colors/std/io/trait.Read.html
https://rustdoc.crud.net/jsha/fewer-colors/std/iter/trait.Iterator.html