| Age | Commit message (Collapse) | Author | Lines |
|
|
|
Most of the code in mod.rs should be code that really needs to have
the list of available themes inlined into it.
|
|
|
|
rustdoc has various user-configurable preferences. These are recorded
in web Local Storage (where available). But we want to provide a way
to configure the default default, including for when web storage is
not available.
getSettingValue is the function responsible for looking up these
settings. Here we make it fall back some in-DOM data, which
ultimately comes from RenderOptions.default_settings.
Using HTML data atrtributes is fairly convenient here, dsspite the
need to transform between snake and kebab case to avoid the DOM
converting kebab case to camel case (!)
We cache the element and dataset lookup in a global variable, to
ensure that getSettingValue remains fast.
The DOM representation has to be in an element which precedes the
inclusion of storage.js. That means it has to be in the <head> and we
should not use an empty <div> as the container (although most browsers
will accept that). An empty <script> element provides a convenient
and harmless container object. <meta> would be another possibility
but runs a greater risk of having unwanted behaviours on weird
browsers.
We trust the RenderOptions not to contain unhelpful setting names,
which don't fit nicely into an HTML attribute. It's awkward to quote
dataset keys.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Currently, storage.js and main.js have many open-coded calls to
getCurrentValue for "rustdoc-" values, but these are settings and
should be handled by getSettingValue.
So make getSettingValue part of storage.js (where everyone can call
it) and use it everywhere.
No functional change yet. We are going to make getSettingValue do
something more sophisticated in a moment.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
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
|
|
|
|
r=jyn514
Fix sidebar scroll on mobile devices
Fixes #77942.
The issue was coming from the appearance/disappearance of the "wrapper" on the mobile devices web browsers, which triggers the "resize" event, calling the `hideSidebar` function is the JS code.
r? @jyn514
|
|
|
|
Add settings to rustdoc to use the system theme
This PR adds new settings to `rustdoc` to use the operating system color scheme.

`rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121), but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page.
I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)).
Since there's now more than one official ""dark"" theme in `rustdoc` (and also to support custom/third-party themes), the preferred dark and light themes can be configured in the settings page (the defaults are just "dark" and "light").
This is also my very first "proper" PR to Rust! Please let me know if I did anything wrong :).
|
|
If the user doesn't have a preferred dark theme but is already using a
dark theme, set the preferred dark theme to be that theme
|
|
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.
|
|
|
|
rustdoc: Fix font CSS for crate lists
I had put it in the wrong file in #76126. This should fix it now. Thank
you to `@ollie27` for pointing this out!
---
`@rustbot` modify labels: T-rustdoc C-bug
|
|
I had put it in the wrong file in #76126. This should fix it now. Thank
you to @ollie27 for pointing this out!
|
|
Improve contrast of foreground line number.
|
|
Fira Sans is what's used for module lists and other item lists.
Previously, the default body font, "Source Serif Pro", was used for
crate lists, which didn't visually match other item lists.
|
|
aszenz:GH-66816_removes_disable_attribute_before_return, r=GuillaumeGomez
GH-66816: Remove disable attr before return
Passing --disable-per-crate-search removes the create search inputs so moved code around so that the search input is enabled
first before the function returns.
Fixes #66816
|
|
GuillaumeGomez:ayu-theme-button-hover-background-color, r=pickfire
Improve theme button hover background color
Fixes #75880.


r? @pickfire
|
|
Clean up rustdoc front-end source code
r? @jyn514
|
|
Expand rustdoc theme chooser x padding


But I still think there is room for improvement considering mdbook.

CC @GuillaumeGomez @jyn514
|
|
|
|
|
|
Passing --disable-per-crate-search removes the create search
inputs so moved code around so that the search input is enabled
first before the function returns
|
|
|
|
Improve help popup
Fixes #75623.
The second commit is just a slight improvement: the help popup won't be created until someone presses "?" or ESC. Not a big improvement in itself but considering the low amount of code required, I think it was worth the shot.
r? @jyn514
|
|
|
|
|
|
Unify theme choices border color in ayu theme
There was a slight color difference in the theme choice menu borders:


r? @Cldfire
|
|
Fix font color for help button in ayu and dark themes
A nice before/after:


For the ayu theme, the change is very "light", the font color was already close to white, so I unified the color with the pictures of the other buttons:


|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add help button
Part of #75197.
Here is a screenshot of the result:

r? @jyn514
|