-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
rustdoc: change .src-line-numbers > span
to .src-line-numbers > a
#103650
Conversation
A change occurred in the Ayu theme. cc @Cldfire Some changes occurred in HTML/CSS/JS. cc @GuillaumeGomez, @Folyd, @jsha Some changes occurred in HTML/CSS themes. |
5f38053
to
563986e
Compare
With this change, when another line is selected, the original one keeps the right border: Just to explain a bit more what I did:
When switched back to |
d9b9630
to
c9e7c56
Compare
@@ -211,6 +216,12 @@ const handleSourceHighlight = (function() { | |||
}; | |||
}()); | |||
|
|||
const addSourceLineAnchorsHref = () => { | |||
onEachLazy(document.querySelectorAll(".src-line-numbers a"), e => { |
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.
This is unneeded. If there is an ID, it automatically links to itself if there is no href
.
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.
Is it? When I try running with this function patched out, clicking the links still works, but right-clicking them doesn't.
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.
What is the right clicking supposed to do?
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.
Oh indeed. It doesn't propose to copy a link, what a shame... Then I guess it comes to this: is it better to generate href
through JS or in the HTML directly?
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.
I guess it really depends on how much bigger it makes the doc bundle. If it's only 1% or so, it's probably fine to just use HTML. If it's more like 10%, it should probably be JavaScript, or skip this PR entirely.
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.
Let's see once we have results to think about. ;)
|
||
const addSourceLineAnchorsHref = () => { | ||
onEachLazy(document.querySelectorAll(".src-line-numbers a"), e => { | ||
e.href = linkPage + "#" + e.innerText; |
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.
On small pages, it's fine. However, it's a very bad ideas as soon as you start to have more than 5 functions with examples which comes pretty quickly. Either generate directly the URLs (which would increase the size) or don't change it at all.
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.
That makes sense.
Okay, I've changed it to just embed the links directly in the outputted HTML.
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.
Big question: is it worth it? It'll increase the page size quite a lot.
78a7205
to
ec51816
Compare
Let’s see how much, I suppose. @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit ec5181653e19477b01f2f1eb60db969c3598b36d with merge c02fcd308362e1b1a08a8c1ba40eaffb84e1d23f... |
☀️ Try build successful - checks-actions |
Queued c02fcd308362e1b1a08a8c1ba40eaffb84e1d23f with parent 33b530e, future comparison URL. |
Finished benchmarking commit (c02fcd308362e1b1a08a8c1ba40eaffb84e1d23f): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
doc-bytes results: https://perf.rust-lang.org/compare.html?start=33b530e04099465a8029ef581202d52f4075558e&end=c02fcd308362e1b1a08a8c1ba40eaffb84e1d23f&stat=size%3Adoc_bytes
|
…e-css, r=notriddle Fix z-indexes of code example feature and cleanup its CSS When reviewing rust-lang#103650, I realized that the `z-index`es of this feature were completely broken: ![Screenshot from 2022-10-28 10-55-27](https://user-images.githubusercontent.com/3050060/198826360-0c5cbe5a-ea8e-452a-9504-38d3da3615e6.png) This PR fixes it by reducing the value of value under the one used for `.popover` (it could be completely removed but then it wouldn't be displayed as nicely). There was also a lot of duplicated CSS so I merged the rules. r? `@notriddle`
I think it's acceptable. r=me once you have fixed the merge conflict. |
ec51816
to
5ec54cc
Compare
5ec54cc
to
5421a84
Compare
@GuillaumeGomez Okay, it's rebased. |
src/librustdoc/html/sources.rs
Outdated
writeln!(line_numbers, "<span>{0}</span>", line + offset) | ||
for line_number in 1..=lines { | ||
let line = line_number + offset; | ||
writeln!(line_numbers, "<a href=\"{root_path}{url}#{line}\">{line}</a>") |
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.
This one is still bugging me: as soon as this feature is enabled by default, the size will increase like crazy... I'm really not sure it's worth it to generate links here.
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.
Would generating it with JavaScript be better?
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.
No because then it would become a performance problem on the front-end side. Maybe I'm just overthinking things in here... The problem is that this feature has basically no test or anything, so it's really not great.
Maybe let's ask what the @rust-lang/rustdoc team thinks about it?
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.
I assume the doc_bytes
benchmarks are raw file sizes? Seems like this should compress really well and not affect the transferred size much.
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.
The problem isn't the network part of the GUI rendering.
This comment has been minimized.
This comment has been minimized.
This allows people to treat them like real links, such as right-click to copy URL, and makes the line numbers in a scraped example work at all, when before this commit was added, they had the clickable pointer cursor but did not actually do anything when clicked.
5421a84
to
ba4ae13
Compare
I can't think of any way to really mitigate the HTML overhead. Is this worth rebasing? Or just call it a dud and submit the |
Then I suggest this: let's only keep this change for the source code pages and remove it for the examples as it is where it will crazily increase. |
93594a6
to
cb3a04b
Compare
Thanks! @bors r+ rollup |
…r=GuillaumeGomez rustdoc: change `.src-line-numbers > span` to `.src-line-numbers > a` Example: https://notriddle.com/notriddle-rustdoc-demos/line-anchors/test_dingus/fn.test.html This allows people to treat them like real links, such as right-click to copy URL, and makes the line numbers in a scraped example work at all, when before this commit was added, they had the clickable pointer cursor but did not actually do anything when clicked.
Rollup of 5 pull requests Successful merges: - rust-lang#103650 (rustdoc: change `.src-line-numbers > span` to `.src-line-numbers > a`) - rust-lang#104177 (rustdoc: use consistent "popover" styling for notable traits) - rust-lang#104318 (Move tests) - rust-lang#104323 (rustdoc: remove no-op CSS `.scrape-help { background: transparent }`) - rust-lang#104345 (Fix up a Fluent message) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Example: https://notriddle.com/notriddle-rustdoc-demos/line-anchors/test_dingus/fn.test.html
This allows people to treat them like real links, such as right-click to copy URL, and makes the line numbers in a scraped example work at all, when before this commit was added, they had the clickable pointer cursor but did not actually do anything when clicked.