| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
This feature extends rustdoc to support the syntax that most users will
naturally attempt to use to search for diverging functions.
Part of #60485
It's already possible to do this search with `primitive:never`, but
that's not what the Rust language itself uses, so nobody will try it if
they aren't told or helped along.
|
|
|
|
This enhances generics with the "unboxing" behavior where A<T>
matches T. It makes this unboxing transitive over generics.
|
|
|
|
|
|
Part of #60485
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Designing a good hover microinteraction is a matter of guessing
user intent from what are, literally, vague gestures. In this case,
guessing if hovering in our out of the tooltip base is intentional
or not.
To figure this out, a few different techniques are used:
* When the mouse pointer enters a tooltip anchor point, its hitbox
is grown on the bottom, where the popover is/will appear. This was
already there before this commit: search "hover tunnel" in
rustdoc.css for the implementation.
* This commit adds a delay when the mouse pointer enters the base
anchor, in case the mouse pointer was just passing through and the
user didn't want to open it.
* This commit also adds a delay when the mouse pointer exits the
tooltip's base anchor or its popover, before hiding it.
* A fade-out animation is layered onto the pointer exit delay to
immediately inform the user that they successfully dismissed the
popover, while still providing a way for them to cancel it if
it was a mistake and they still wanted to interact with it.
* No animation is used for revealing it, because we don't want
people to try to interact with an element while it's in the
middle of fading in: either they're allowed to interact with
it while it's fading in, meaning it can't serve as mistake-
proofing for opening the popover, or they can't, but they
might try and be frustrated.
See also:
* https://www.nngroup.com/articles/timing-exposing-content/
* https://www.nngroup.com/articles/tooltip-guidelines/
* https://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown
|
|
This was added to control percentage sizes, in
79956b96e875e6ba2bfa551fabda6b7896f988ac
Now, the only percentage size is [`border-radius`], which is
based on the size of the box itself, not its containing block.
This leaves the property unused.
[`border-radius`]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius
|
|
|
|
r=GuillaumeGomez
rustdoc: restructure type search engine to pick-and-use IDs
Fixes #110029
Preview: https://notriddle.com/rustdoc-demo-html-3/search-corrections/std/index.html?search=-%3E%20streaming
This change makes it so, instead of mixing string distance with type unification, function signature search works by mapping names to IDs at the start, reporting to the user any cases where it had to make corrections, and then matches with IDs when going through the items.
This only changes function searches. Name searches are left alone, and corrections are only done when there's a single item in the search query.
|
|
r=GuillaumeGomez
rustdoc: clean up settings.css and settings.js
`handleKey` was added in 9dc5dfb97504c538bc72f367a77bb9f714c30097 and 704050da2334c465784954d81c8990c4bc7a92c5 because the browser-native checkbox was `display: none`, breaking native keyboard accessibility.
The native checkbox is now merely `appearance: none`, which does not turn off [behavior semantics], so JavaScript to reimplement it isn't needed any more.
[behavior semantics]: https://w3c.github.io/csswg-drafts/css-ui/#appearance-semantics
The other, one line change to settings.css is follow-up to #110205
|
|
This code was added back when `border-color: currentColor` was used.
Since it was changed in ad9a89eef2857a24ef049b9eee2d1db5bcbf1d11, the
current color is not used any more.
|
|
This code was added in 9dc5dfb97504c538bc72f367a77bb9f714c30097
and 704050da2334c465784954d81c8990c4bc7a92c5 because the browser-
native checkbox was `display: none`, breaking native keyboard
accessibility.
The native checkbox is now merely `appearance: none`, which does
not turn off [behavior semantics], so JavaScript to
reimplement it isn't needed any more.
[behavior semantics]: https://w3c.github.io/csswg-drafts/css-ui/#appearance-semantics
|
|
* There's no need to call `history.replaceState` right before
calling `searchState.hideResults`, which already does it.
* There's no need to implement hiding search results when that
is already implemented.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change makes it so, instead of mixing string distance with
type unification, function signature search works by
mapping names to IDs at the start, reporting to the user any
cases where it had to make corrections, and then matches with
IDs when going through the items.
This only changes function searches. Name searches are left alone,
and corrections are only done when there's a single item in the
search query.
|
|
|
|
r=GuillaumeGomez
rustdoc: stop passing a title to `replaceState` second argument
As described on [MDN's replaceState page], this parameter is not currently used, and the empty string is "safe against future changes to the method."
[MDN's replaceState page]: https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState
|
|
As described on [MDN's replaceState page], this parameter is not
currently used, and the empty string is "safe against future
changes to the method."
[MDN's replaceState page]: https://developer.mozilla.org/en-US/docs/Web/API/History/replaceState
|
|
|
|
|
|
|
|
|
|
|
|
rustdoc: make settings radio and checks thicker, less contrast
This is very dependent on subjectivity and what screen you use, but this change makes the radio buttons' outer circle less ugly.
This is because I could see the pixels very clearly, thanks to the very thin line and high contrast. This change makes both less severe, giving your browser's antialiasing algorithm more to work with. Since it's thicker, lowering the contrast shouldn't impact visibility.
## Preview
https://notriddle.com/rustdoc-demo-html-3/pixelated-border/settings.html
## Before
## After
<details><summary>Original "after" image with 2px border around checked box</summary>
</details>
|
|
Fixes the desktop scrolling weirdness mentioned in
https://github.com/rust-lang/rust/pull/98775#issuecomment-1182575603
As described in the MDN page for this property:
* The current Firefox ESR is 102, and the first Firefox version
to support this feature is 59.
* The current Chrome version 112, and the first version to support
this is 63.
* Edge is described as having a minor bug in `none` mode, but we
use `contain` mode anyway, so it doesn't matter.
* Safari 16, released September 2022, is the last browser to
add this feature, and is also the oldest version we officially
support.
|
|
This is very dependent on subjectivity and what screen you use,
but this change makes the radio buttons' outer circle less ugly.
This is because I could see the pixels very clearly, thanks to the
very thin line and high contrast. This change makes both less
severe, giving your browser's antialiasing algorithm more to
work with. Since it's thicker, lowering the contrast shouldn't
impact visibility.
|
|
This functionality is already tested in `hash-item-expansion.goml`,
and was implemented twice:
* First, in code that ran at load time and at hash change:
917cdd295d2eed213c135d6f984c650f016ee3d6
* Later, the hash change event handler was itself run at load time,
and the code handling both cases diverged in implementation,
though their behavior still matches pretty well:
f66a331335f3ac931afabca6f927a9d7dc17db3e
|
|
rustdoc: add test and bug fix for theme defaults
Part of https://github.com/rust-lang/rust/issues/66181
|
|
|
|
* Stop checking `func` in `onEach`. It's always hard-coded right
at the call site, so there's no point.
* Use the ternary operator in a few spots where it makes sense.
* No point in making `onEach` store `arr.length` in a variable if
it's only used once anyway.
|
|
rustdoc: avoid including line numbers in Google SERP snippets
|
|
|
|
|
|
improve UX
|
|
|
