| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Also factor out outer_version and const_outer_version into
render_rightside.
|
|
|
|
|
|
|
|
|
|
Improve display for "copy-path" button, making it more discreet
As suggested by `@Nemo157` [here](https://github.com/rust-lang/rust/pull/85118#issuecomment-838887670):
r? `@jsha`
|
|
rustdoc: use focus for search navigation
Rather than keeping track of highlighted element inside the JS, take advantage of `.focus()` and the :focus CSS pseudo-class.
This required wrapping each row of results in one big `<a>` tag (because anchors can be focused, but table rows cannot). That in turn required moving from a table layout to a div layout with float.
This makes it so Ctrl+Enter opens links in new tabs, and using the arrow keys to navigate off the bottom of the page scrolls the rest of the page into view. It also simplifies the keyboard event handling. It eliminates the need for click handlers on the search results, and for tracking mouse movements.
This changes the UI treatment of mouse hovering. A hovered element now gets a light grey background, but does not change the focus. It's possible to have two highlighted search results: one that is focused (via keyboard) and one that is hovered (via mouse). Pressing enter will activate the focused link; clicking will activate the hovered link. This matches up with how Firefox and Chrome handle suggestions in their URL bar, and avoids stray mouse movements changing the focus.
Selecting tabs is now done with left/right arrows while any search result is focused. The visibility of results on each search tab is
controlled with the "active" class, rather than by setting display: none directly. Note that the old code kept track of highlighted search element when tabbing back and forth. The new code doesn't.
Demo at https://hoffman-andrews.com/rust/focus-search-results2/std/?search=fn
Fixes #84384
Fixes #79962
Fixes #79872
|
|
|
|
|
|
Rather than keeping track of highlighted element inside the JS, take
advantage of `.focus()` and the :focus CSS pseudo-class.
This required wrapping each row of results in one big <a> tag (because
anchors can be focused, but table rows cannot). That in turn required
moving from a table layout to a div layout with float.
This makes it so Ctrl+Enter opens links in new tabs, and using the arrow
keys to navigate off the bottom of the page scrolls the rest of the page
into view. It also simplifies the keyboard event handling. It eliminates
the need for click handlers on the search results, and for tracking
mouse movements.
This changes the UI treatment of mouse hovering. A hovered element now
gets a light grey background, but does not change the focused element.
It's possible to have two highlighted search results: one that is
focused (via keyboard) and one that is hovered (via mouse). Pressing
enter will activate the focused link; clicking will activate the hovered
link. This matches up with how Firefox and Chrome handle suggestions in
their URL bar, and avoids stray mouse movements changing the focus.
Selecting tabs is now done with left/right arrows while any search
result is focused. The visibility of results on each search tab is
controlled with the "active" class, rather than by setting display: none
directly. Note that the old code kept track of highlighted search
element when tabbing back and forth. The new code doesn't.
|
|
Rustdoc cleanup
Part of https://github.com/rust-lang/rust/issues/83332. The goal of this PR is to remove a few unused things:
* The "loading content" things are now unneeded.
* Some toggle CSS rules were still there.
* Some parts of the JS had a different indent, fixed it.
r? `@jsha`
|
|
|
|
In rustdoc's main.js, we had an onclick handler for the whole document
that would dispatch to handlers for various elements. This change
attaches the handlers to the elements that trigger them, instead.
This simplfies the code and avoids reimplementing the browser's bubbling
functionality.
As part of this change, change from a class to an id for help button.
Move the handlers and associated code for highlighting source lines into
source-script.js (and factor out a shared regex).
|
|
Fix source code line number display and make it clickable again
Fixes https://github.com/rust-lang/rust/issues/85119.
I used the same logic we're using for other codeblocks: putting the line number `<span>`s into the `example-wrap` directly and then add `display: inline-flex` on `example-wrap`.
r? `@jsha`
|
|
|
|
|
|
|
|
Add stability tags to ImportItem.
Fixes #83832.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
This better matches the appearance of this kind of snippet in the full
item view and is less jarring to read due to repeated
foreground-background changes.
|
|
|
|
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`
|
|
The background was dark before, which made the text impossible to read.
Now the background is white, which is how selected `div`s are rendered.
As a result, the search results tabs now look identical to how they
used to look (before #79896).
|
|
|
|
|
|
|
|
|
|
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.
|
|
GuillaumeGomez:ayu-theme-button-hover-background-color, r=pickfire
Improve theme button hover background color
Fixes #75880.
r? @pickfire
|
|
Unify theme choices border color in ayu theme
There was a slight color difference in the theme choice menu borders:
r? @Cldfire
|
|
|
|
|
|
|
|
Add help button
Part of #75197.
Here is a screenshot of the result:
r? @jyn514
|
|
Only add a border for the rust logo
I didn't add a border for the light theme though, as I felt it as unnecessary.
r? @Manishearth
|
|
|
|
* Rename it in the UI
* Rename the CSS classes
|
|
|
|
Co-authored-by: Cldfire <cldfire@3grid.net>
|
