-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean up dom #84703
Clean up dom #84703
Conversation
Some changes occurred in HTML/CSS themes. Some changes occurred in HTML/CSS/JS. A change occurred in the Ayu theme. cc @Cldfire |
@@ -387,7 +387,7 @@ fn maybe_redirect(source: &str) -> Option<String> { | |||
const REDIRECT: &str = "<p>Redirecting to <a href="; | |||
|
|||
let mut lines = source.lines(); | |||
let redirect_line = lines.nth(6)?; | |||
let redirect_line = lines.nth(7)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For information: this change is needed because of my change in the redirection file which added a title to the page.
This comment has been minimized.
This comment has been minimized.
e97b4f9
to
c7cc23f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good! One possible tweak.
c7cc23f
to
9dd46ab
Compare
@jsha Very good point! |
src/librustdoc/html/render/mod.rs
Outdated
@@ -1328,7 +1328,7 @@ fn render_impl( | |||
.map(|item| format!("{}.{}", item.type_(), name)); | |||
write!( | |||
w, | |||
"<h4 id=\"{}\" class=\"{}{}{}\">", | |||
"<div id=\"{}\" class=\"{}{}{}\">", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it should be:
"<div id=\"{}\" class=\"{}{}{}\">", | |
"<div id=\"{}\" class=\"{}{}{}\" role="heading" aria-level="4">", |
if I understood correctly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, if so, that'll also allow me to simplify the CSS changes quite a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's what I'm thinking.
☔ The latest upstream changes (presumably #84729) made this pull request unmergeable. Please resolve the merge conflicts. |
9dd46ab
to
43a3794
Compare
Applied @notriddle's suggestion which allowed me to simplify the CSS changes. I also rebased. |
@GuillaumeGomez can you update the PR description to describe why the |
@jsha Good idea! I updated the description. |
Looking at this again, I'm not sure the switch to
What's the exact message you're getting from tidy? Are we confident tidy is correct about it? This stack overflow suggests heading tags can contain "phrasing content": https://stackoverflow.com/a/9543834 The list of "phrasing content" (https://html.spec.whatwg.org/multipage/dom.html#phrasing-content) include |
We have |
|
Here is a small sample of the
|
Aha, this is what I was worried about:
Instead of changing all our
This looks like we failed to close a tag somewhere (and doesn't seemed to be part of this PR, just wanted to acknowledge since it's a big part of the output). |
It looks like one significant candidate is:
|
Apparently, headings inside
|
From reading that article, it sounds like the only issue is that JAWS won't interpret headings in summaries as headings. To me that suggests we should keep them as headings, but also add an aria-role to ensure they are treated as headings by JAWS. Assuming that works. Do you have a copy of JAWS to test? |
Unfortunately, no I don't. |
@jsha I think it shouldn't have been |
I think https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-span-element I think the tidy check is actually pointing out for us a wider fix, which is great! That's what tidy tools should be, at their best. The notable-traits tooltip should not be part of the Try this: visit https://doc.rust-lang.org/std/boxed/struct.Box.html and run in the console I think we should build the various notable-traits tooltips potentially required by a document in a single, hidden DIV at the end of the document, then use JS to put them into place on hover. That allows us to de-duplicate them. It makes it so we're not embedding a |
But it would require JS to work whereas it doesn't need it currently. I think we should rely as little as possible on JS if possible. So maybe we could work around this limitation with page-specific CSS or something along the line? |
Fair point about requiring JS for the tooltips where we currently don't. Another possibility, which solves the "don't put divs inside spans" problem but not the duplication problem, would be to move the |
Replaced the |
@bors r+ Excellent. Thanks for sticking through all my comments. I'm really happy with the results: not only have we made tidy happy, we've significantly cleaned up and clarified our DOM and CSS. |
📌 Commit 0daf8ac has been approved by |
☀️ Test successful - checks-actions |
And thank you for the great insight and reviews! |
These were changed in rust-lang#84703.
…ulacrum Fix a bug in the linkchecker There was a small typo in the linkchecker (in rust-lang#85652) that caused it to report a `#` fragment link error pointing to the wrong file (it was displaying the path to the source file, not the target of the link). This also includes a few other changes: - Fixes the tests due to some changes in the redirect handling in rust-lang#84703. - Adds the tests to rustbuild to run whenever the linkchecker itself is run. - Updates the tests to validate more of the output (so that a mistake like this would have been caught). Closes rust-lang#86144
…ulacrum Fix a bug in the linkchecker There was a small typo in the linkchecker (in rust-lang#85652) that caused it to report a `#` fragment link error pointing to the wrong file (it was displaying the path to the source file, not the target of the link). This also includes a few other changes: - Fixes the tests due to some changes in the redirect handling in rust-lang#84703. - Adds the tests to rustbuild to run whenever the linkchecker itself is run. - Updates the tests to validate more of the output (so that a mistake like this would have been caught). Closes rust-lang#86144
Part of rust-lang#87059 Partially reverts rust-lang#84703 Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
…atch, r=GuillaumeGomez Rustdoc accessibility: use real headers for doc items Part of rust-lang#87059 Partially reverts rust-lang#84703 Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
Part of rust-lang#87059 Partially reverts rust-lang#84703 Heavily modified for beta backport needs.
Part of rust-lang#87059 Partially reverts rust-lang#84703 Backport of rust-lang#87390 Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
Part of rust-lang#87059 Partially reverts rust-lang#84703 Preview at: https://notriddle.com/notriddle-rustdoc-test/real-headers/std/index.html
The commits come from #84480.
They were errors reported by the
tidy
script that we will use to ensure that the HTML generated by rustdoc is valid.I checked carefully that there were no difference so in principle it should be exactly the same rendering but a double-check would be very appreciated in case I missed something.
Extra note:
<h4>
and some<h3>
tags were replaced by<div>
because they're not supposed to contain tags as they currently do.r? @jsha