rustdoc: Hide item contents, not items
This tweaks rustdoc to hide item contents instead of items, and only when there are too many of them.
This means that users will _always_ see the type parameters, and will _often_ see fields/etc as long as they are small. Traits have some heuristics for hiding only the methods or only the methods and the consts, since the associated types are super important.
I'm happy to play around with the heuristics here; we could potentially make it so that structs/enums/etc are always hidden but traits will try really hard to show type aliases.
This needs a test, but you can see it rendered at https://manishearth.net/sand/doc_render/bar/
<details>
<summary> Code example </summary>
```rust
pub struct PubStruct {
pub a: usize,
pub b: usize,
}
pub struct BigPubStruct {
pub a: usize,
pub b: usize,
pub c: usize,
pub d: usize,
pub e: usize,
pub f: usize,
}
pub union BigUnion {
pub a: usize,
pub b: usize,
pub c: usize,
pub d: usize,
pub e: usize,
pub f: usize,
}
pub union Union {
pub a: usize,
pub b: usize,
pub c: usize,
}
pub struct PrivStruct {
a: usize,
b: usize,
}
pub enum Enum {
A, B, C,
D {
a: u8,
b: u8
}
}
pub enum LargeEnum {
A, B, C, D, E, F, G, H, I, J
}
pub trait Trait {
type A;
#[must_use]
fn foo();
fn bar();
}
pub trait GinormousTrait {
type A;
type B;
type C;
type D;
type E;
type F;
const N: usize = 1;
#[must_use]
fn foo();
fn bar();
}
pub trait HugeTrait {
type A;
const M: usize = 1;
const N: usize = 1;
const O: usize = 1;
const P: usize = 1;
const Q: usize = 1;
#[must_use]
fn foo();
fn bar();
}
pub trait BigTrait {
type A;
#[must_use]
fn foo();
fn bar();
fn baz();
fn quux();
fn frob();
fn greeble();
}
#[macro_export]
macro_rules! foo {
(a) => {a};
}
```
</details>
Fixes https://github.com/rust-lang/rust/issues/82114
Introduce a first use of the `<details>` and `<summary>` tags as
replacements for the JS-built toggles. I think this has the potential to
replace all the JS toggles and generally clean up the JS, CSS, and HTML.
Split rendering of attributes into two cases: in the case where they are
rendered as descendents of a `<pre>` tag, where they use indent spaces and
newlines for formatting, matching their surrounding markup. In the case
where they are rendered as descendants of a `<code>` tag, they are
rendered as `<div>`. This let me clean up some fragile CSS that was
adjusting the margin-left of attributes depending on context.
Remove toggles for attributes. With the ALLOWED_ATTRIBUTES filter, it's
rare for an item to have more than one attribute, so hiding attributes
behind a toggle doesn't save any screen space in the common case.
Fix a couple of invocations of `matches!` that didn't compile on my
machine.
Fix a boolean for the JS `createToggle` call that was causing
"Expand description" to show up spuriously on already-expanded
descriptions.
Add JS for auto-hide settings and hide all / show all.
Remove a z-index property and some font color tweaks made unnecessary
by the <details> toggles.
Add CSS for the <details> toggles.
Slight visual improvements to warning boxes in the docs
First I noticed that sometimes the thumbs-down emoji in the docs is hard to see and hard to look at because the yellow emoji color and the color of the box below are so bright. Especially if you look at the screen late at night you can notice it. I thought I should change that so I added a black outline around the emoji. It works using the [`text-shadow`](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow) property. It may be a bit hacky but it seems to work well and browser compatibility looks pretty good too: [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/text-shadow#browser_compatibility).
For consistency the microscope has the black border too.
Alternatively I had `drop-shadow(0px 0px 1px black);` in mind but its [browser compatibility](https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/drop-shadow()#browser_compatibility) doesn't look as good and the blurry shadow probably doesn't look as good either.
Then, I thought that now that I'm at it I could also try changing the purple color to a color you would rather expect to see for deprecation: red. For the red I've taken the blue and reused it as a foundation and moved it to the red color spectrum.
But then I thought that the purple color could still be reused for something else: for the boxes that tell you about portability (e.g. _only supported on Unix_). These are currently blue.
I think blue doesn't really represent danger like it should. Not being cross-platform represents a danger because if you want to compile for a different platform, your code may not compile anymore. Blue looks too friendly and is in my opinion more suitable for a box containing general information like for instance "This is available since 1.0.0". None of the current three box types (unstable, deprecated and portability) are that.
I think purple is a better fit for it because it's kind of in the middle between "use it" and "don't use it". Deprecated is definitely "don't use it". To illustrate this better, here's a color spectrum:
Blue = friendly, "use it".
Red = danger, "don't use it".
And the purple in the middle (the color that the portability box now has) probably represents "use it if you have to", so it's not entirely friendly and not entirely a danger. That is why I think it fits.
However I made one change to that existing purple: I made the outer color a bit brighter because it's outstandingly dark compared to the other outer colors of the other boxes.
This is all subjective but in my opinion it looks nicer. At first you might need to get used to it though. Notice the box colors and the black outlines around the emoji shapes:
Otherwise on systems where Arial is not available the system will
fallback to a serif font, rather than a sans-serif one.
This is especially relevant on acessibility-conscious setups (such as is
mine) that have web-fonts disabled and a limited set of fonts available
on the system.
On most platforms and browsers, `sans-serif` is equivalent to Arial.
However, on Firefox on Ubuntu (and possibly other Linuxes), `sans-serif`
is DejaVu Sans, a much wider font. This creates a larger shift in text
when the custom fonts finally load. Arial is a web-safe font, and
specifying it explicitly gives us more cross-platform consistency, as
well as reducing the layout shift that happens when fonts load.
Add font-display: swap. Per https://web.dev/font-display/, this prevents
"flash of invisible text" during load by using a system font until the
custom font is available. I've noticed this flash of invisible text
occasionally when reading Rust docs.
Add an explicit height to icons (which already had an explicit width)
to allow browsers to lay out the page more accurately before the icons
have been loaded. https://web.dev/optimize-cls/.
Add min-width: 115px to the crate search dropdown. When the HTML first
loads, this dropdown includes only the text "All crates." Later, JS
loads the items underneath it, some of which are wider. That causes
the dropdown to get wider, causing a distracting reflow. This sets a
min-width based on the size that the dropdown eventually becomes based
on the crates on doc.rust-lang.org, reducing page movement during load.
For browsers that support woff2 (most modern ones:
https://caniuse.com/woff2), this offers a reduction in download size
for these two fonts from 362k to 257k (32% reduction). It decreases the
total page size for `struct.String.html` (counting all subresources) by
about 2.5%.
If this is interesting, I'm happy to apply the same treatment to the
other fonts, but these two are the biggest.
Fix search section position on small devices
Fixes#79526.
This is exactly the same issue fixed in 9c36491538 (in https://github.com/rust-lang/rust/pull/79936) but applied to the search section. When the width becomes too small, the search input goes on its own line to get more space, making it go "under" the section following (so either "main" or "search"). The fix is to simply make the section go more under so that it doesn't go over the search input.
r? `@jyn514`
Use sans-serif font for the "all items" page links
The "all items" pages' links aren't using a sans-serif font unlike the rest of equivalent items in the other module pages. ``@Nemo157`` reported me this issue so here is the fix!
r? ``@Nemo157``
Move tooltips messages out of html
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.
So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.
So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other).
Don't hesitate if a part of my explanations isn't clear.
r? `@jyn514`
