rustdoc: add interaction delays for tooltip popovers
Preview:
* [notable traits](http://notriddle.com/rustdoc-demo-html-3/delay-tooltip/testing/struct.Vec.html#method.iter)
* [panicking code block](http://notriddle.com/rustdoc-demo-html-3/delay-tooltip/testing/struct.Vec.html#indexing)
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
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
79956b96e8
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
This code was added in 9dc5dfb975
and 704050da23 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
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.
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.
Fix "Directly go to item in search if there is only one result" setting
Part of #66181.
The setting was actually broken, so I fixed it when I added the GUI test.
r? `@notriddle`
Improve "Auto-hide trait implementation documentation" GUI test
Part of #66181.
I'll start working on the `include` command for `browser-ui-test` so we can greatly reduce the duplicated code between setting tests.
r? ``@notriddle``
rustdoc: simplify DOM for `.item-table`
This switches from using `<div>` to the more semantic `<ul>`, and using class names that rhyme with the classes the search results table uses.
* Changes the class names so that they all start with `setting-`.
That should make it harder to accidentally use a setting class outside
the settings popover, where loading the CSS might accidentally change
the styles of something unrelated.
* Get rid of an unnecessary wrapper DIV around the radio button line.
* Simplify CSS selectors by making the DOM easier and more intuitive
to target.
rustdoc: remove redundant CSS rule `#settings .setting-line`
Since the current version of settings.js always nests things below a div with ID `settings`, this rule always overrode the one above.
This prevents some strange blur-event-related bugs with the "?" command
by ensuring that the focus remains in the same spot when the settings
area closes.
rustdoc: remove redundant item kind class from `.item-decl > pre`
This class originated in the very first commit of `rustdoc_ng`, and was used to add a color border around the item decl based on its kind.
4fd061c426/src/rustdoc_ng/html/static/main.css (L102-L106)
The item decl no longer has a border, and there aren't any kind-specific styles in modern rustdoc's rendering of this UI item.
Most of this PR is updating test cases so that they use `item-decl` to find the `<pre>` tag instead of relying on the fact that the class name had `rust {kind}` in it while other `<pre>` tags only had class `rust`.
Add tidy check to ensure that rustdoc GUI tests start with a small description
The first commit comes from https://github.com/rust-lang/rust/pull/106865 to prevent CI to fail.
This PR adds a tidy check to enforce having a small description at the top of the GUI test. Although the format is made to be as easy as possible to read, it's not always obvious what a test is actually checking. I think enforcing this will make it easier for us to come back on these tests if needed.
r? `@notriddle`
This class originated in the very first commit of `rustdoc_ng`, and was used
to add a color border around the item decl based on its kind.
4fd061c426/src/rustdoc_ng/html/static/main.css (L102-L106)
The item decl no longer has a border, and there aren't any
kind-specific styles in modern rustdoc's rendering of this UI item.
Most of this commit is updating test cases so that they use `item-decl` to
find the `<pre>` tag instead of relying on the fact that the class name
had `rust {kind}` in it while other `<pre>` tags only had class `rust`.
rustdoc: remove unnecessary DOM class `h1.fqn`
It's misleading. The main heading sometimes isn't an fully qualified name at all.
It's also redundant. It's always a child of `div.main-heading`, so just use that.
It's misleading. The main heading sometimes isn't an fully qualified name at all.
It's also redundant. It's always a child of `div.main-heading`, so just use that.
