| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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`
|
|
|
|
Fix item name display on mobile
Fixes https://github.com/rust-lang/docs.rs/issues/1200
cc `@jyn514`
r? `@Nemo157`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Greatly improve display for small mobile devices screens
Fixes #78014.
The biggest change being the "search bar". Instead of having everything on one line, I decided to move the search input on its own:
Another change is that now, we "break words" in the listing so that they don't grow too big:
r? @jyn514
|
|
|
|
|
|
Small CSS cleanup
r? @jyn514
|
|
|
|
Hide help button on mobile
Addresses #77899.
This PR is just a quick fix for now: we're still debating about whether or not we want to display this help popup and if so, how. I'll open an issue once this PR is merged to discuss about it.
Before:
After:
r? @jyn514
|
|
|
|
Add word wrap for short descriptions
Fixes #77652
cc @WaffleLapkin
r? @jyn514
|
|
|
|
|
|
|
|
Fixes an issue where links in the one-line version of an item's docs
would be in Fira Sans, while the rest would be in a serifed font.
|
|
I had put it in the wrong file in #76126. This should fix it now. Thank
you to @ollie27 for pointing this out!
|
|
|
|
Add help button
Part of #75197.
Here is a screenshot of the result:
r? @jyn514
|
|
|
|
* Rename it in the UI
* Rename the CSS classes
|
|
Fix tooltip position if the documentation starts with a code block
Fixes #74321.
Before:
After:
And in case there is text, it is not being applied:
And on mobile it isn't needed so it's not "activated":
r? @rust-lang/rustdoc
|
|
|
|
|
|
|
|
We need it for run buttons (https://github.com/rust-lang/rust/pull/44671), but not function defs
|
|
|
|
This makes the spotlight show on hover instead of click. Clicks can be
used to persist it, which is also what's used on mobile.
|
|
|
|
This reverts commit 1244ced9580b942926afc06815e0691cf3f4a846.
|
|
r=Dylan-DPC
Add margin after doc search results
I found it not really on computer that the last result is right at the bottom of the page. I find it better with margin below (especially when you hover the last element!). A screenshot to show the result:
r? @kinnison
cc @rust-lang/rustdoc @Manishearth @jyn514
|
|
|
|
This causes the components of FQN's to behave similarly to other links
in the contents of rustdoc-styled pages.
I (and I hope others at least in part) have found the prior design to be
somewhat confusing, as it is not clear (upon hovering) that the various
parts of the FQN are actually links that the user can navigate to.
In short, this patch makes links in the FQN have an underline when the
user hovers over them, more clearly indicating that they can be used for
navigation.
Signed-off-by: Kristofer Rye <kristofer.rye@gmail.com>
|
|
Previously, compile_fail and ignore code examples displayed a tooltip
indicating this in the documentation. This tooltip has now also been
added to should_panic examples.
|
|
|
|
Unblock font loading in rustdoc.css
rustdoc's font loading defaults to "auto", so browsers may block render.
But rustdoc's case prefers a faster TTI for scrolling, this means the
strictest font-display in use should be "swap". rustdoc's fonts do provide
notable legibility improvements but first-time users will have little trouble
reading without. This means "optional" is preferred.
The one exception is Source Serif Pro: it's a big difference for body text, so
"fallback" is preferred over "optional" to cause a (tiny) block.
This follows up on (but does not resolve) #20962, taking PageSpeed Insight's rec fairly directly. Supporting reading material: https://drafts.csswg.org/css-fonts-4/#font-display-desc
|
|
|
|
rustdoc's font loading defaults to "auto", so browsers may block render.
But rustdoc's case prefers a faster TTI for scrolling, this means the
strictest font-display in use should be "swap". rustdoc's fonts do provide
notable legibility improvements but first-time users will have little trouble
reading without. This means "optional" is preferred.
The one exception is Source Serif Pro: it's a big difference for body text, so
"fallback" is preferred over "optional" to cause a (tiny) block.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
