Inhibit clicks on summary's children
A byproduct of using `<details>` and `<summary>` to show/hide detailed documentation was that clicking any part of a method heading (or impl heading) would show or hide the documentation. This was not super noticeable because clicking a link inside the method heading would navigate to that link. But clicking any unlinked black text in a method heading would trigger the behavior.
That behavior was somewhat unexpected, and means that if you try to click a type name in a method heading, but miss by a few pixels, you get a confusing surprise.
This change inhibits that behavior by putting an event listener on most summaries that cancels the event unless the event target was the summary itself. In practice, that means it cancels the event unless the target was the "[+]" / "[-]", because the rest of the heading is wrapped inside a `<div>`, which is the target for anything that doesn't have a more specific target.
r? ``@Manishearth``
Set color for <a> in a more straightforward way.
Previously, we set the default color for <a> tags to black, and then had an override with a bunch of not() clauses to set anchors in
docblocks to blue.
Instead, we should set the default color for <a> to blue (or equivalent in other themes), and override it for places like the sidebar or search results, where we don't want them to be styled as links.
Demo at https://rustdoc.crud.net/jsha/theme-anchor/std/string/struct.String.html. This should result in no visible changes.
r? `@GuillaumeGomez`
Previously, we set the default color for <a> tags to black, and then
had an override with a bunch of not() clauses to set anchors in
docblocks to blue.
Instead, we should set the default color for <a> to blue (or equivalent
in other themes), and override it for places like the sidebar or search
results, where we don't want them to be styled as links.
A byproduct of using `<details>` and `<summary>` to show/hide detailed
documentation was that clicking any part of a method heading (or impl
heading) would show or hide the documentation. This was not super
noticeable because clicking a link inside the method heading would
navigate to that link. But clicking any unlinked black text in a method
heading would trigger the behavior.
That behavior was somewhat unexpected, and means that if you try to click
a type name in a method heading, but miss by a few pixels, you get a
confusing surprise.
This change inhibits that behavior by putting an event listener on most
summaries that cancels the event unless the event target was the summary
itself. In practice, that means it cancels the event unless the target
was the "[+]" / "[-]", because the rest of the heading is wrapped inside
a `<div>`, which is the target for anything that doesn't have a more
specific target.
Make scrollbar in the sidebar always visible for visual consistency
Fixes#90943.
I had to add a background in `dark` and `ayu` themes, otherwise it was looking strange (like an invisible margin). So it looks like this:


Sadly, I wasn't able to add a GUI test to ensure that the scrollbar was always displayed because it seems not possible in puppeteer for whatever reason... I used this method: on small pages (like `lib2/sub_mod/index.html`), comparing `.navbar`'s `clientWidth` with `offsetWidth` (the first doesn't include the sidebar in the computed amount). When checking in the browser, it works fine but in puppeteer it almost never works...
In case anyone want to try to solve the bug, here is the puppeteer code:
<details>
More information about this: I tried another approach which was to get the element in `evaluate` directly (by calling it from `page.evaluate(() => { .. });` directly instead of `parseAssertElemProp.evaluate(e => {...});`.
```js
const puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.goto("file:///path/rust/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/lib2/sub_mod/index.html");
await page.waitFor(".sidebar");
let parseAssertElemProp = await page.$(".sidebar");
if (parseAssertElemProp === null) { throw '".sidebar" not found'; }
await parseAssertElemProp.evaluate(e => {
const parseAssertElemPropDict = {"clientWidth": "192", "offsetWidth":"200"};
for (const [parseAssertElemPropKey, parseAssertElemPropValue] of Object.entries(parseAssertElemPropDict)) {
if (e[parseAssertElemPropKey] === undefined || String(e[parseAssertElemPropKey]) != parseAssertElemPropValue) {
throw 'expected `' + parseAssertElemPropValue + '` for property `' + parseAssertElemPropKey + '` for selector `.sidebar`, found `' + e[parseAssertElemPropKey] + '`';
}
}
}).catch(e => console.error(e));
await browser.close();
})();
```
</details>
r? ``@jsha``
- Remove border.
- Reduce size of emoji slightly.
- Remove details disclosure for unstable reason. This was inconsistent
with our other details disclosures, and the detail revealed was
usually better explained by clicking on the issue link.
Use h3 and h4 for the variant name and the "Fields" subheading.
Remove the "of T" part of the "Fields" subheading.
Remove border-bottom from "Fields" subheading.
Move docblock below "Fields" listing.
rustdoc: Use TTF based font instead of OTF for CJK glyphs to improve readability
Due to Windows' implementation of font rendering, OpenType fonts can be distorted. So the existing font, Noto Sans KR, is not very readable on Windows. This PR improves readability of Korean glyphs on Windows.
## Before

## After

The fonts included in this PR are licensed under the SIL Open Font License and generated with these commands:
```sh
pyftsubset NanumBarunGothic.ttf \
--unicodes=U+AC00-D7AF,U+1100-11FF,U+3130-318F,U+A960-A97F,U+D7B0-D7FF \
--output-file=NanumBarunGothic.ttf.woff --flavor=woff
```
```sh
pyftsubset NanumBarunGothic.ttf \
--unicodes=U+AC00-D7AF,U+1100-11FF,U+3130-318F,U+A960-A97F,U+D7B0-D7FF \
--output-file=NanumBarunGothic.ttf.woff2 --flavor=woff2
```
r? ``@GuillaumeGomez``
Remove border-bottom from most docblocks.
Headings in the top-doc docblock still get a border-bottom due to a rule
that covers all h2, h3, and h4. Method docblocks are generally h5, and
so don't get a border-bottom anymore.
This fixes a problem where a sub-sub-heading within a method would have
a line that went all the way across the page, creating a division that
made that sub-sub-heading look much more important than it really is.
Fixes#90033
Demo at https://jacob.hoffman-andrews.com/rust/less-rule/std/string/struct.String.html
r? ``@GuillaumeGomez``
Headings in the top-doc docblock still get a border-bottom due to a rule
that covers all h2, h3, and h4. Method docblocks are generally h5, and
so don't get a border-bottom anymore.
This fixes a problem where a sub-sub-heading within a method would have
a line that went all the way across the page, creating a division that
made that sub-sub-heading look much more important than it really is.
* Move call location logic from function constructor to rendering
* Fix issue with macro spans in scraping examples
* Clean up example loading logic
Documentation / newtype for DecorationInfo
Fix line number display
Serialize edition of call site, other small cleanup