Move tooltips messages out of html #79742
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GuillaumeGomez
added
T-rustdoc
|
Some changes occurred in HTML/CSS/JS. A change occurred in the Ayu theme. cc @Cldfire Some changes occurred in HTML/CSS themes. |
rust-highfive
added
the
S-waiting-on-review
GuillaumeGomez
force-pushed
the
move-tooltips-messages-out-of-html
branch
from
d484660
to
9b62936
Compare
|
I haven't checked that it works properly, but the approach seems sane to me. One thing I might do is change |
|
No idea either. Renaming to |
|
From discord (for explanations about @Nemo157's suggestion):
|
|
Ok let's go! @bors: r=Nemo157 |
|
📌 Commit 152d4e7 has been approved by |
bors
added
S-waiting-on-bors
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Dec 23, 2020
…es-out-of-html, r=Nemo157 Move tooltips messages out of html First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up. So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice. So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other). Don't hesitate if a part of my explanations isn't clear. r? `@jyn514`
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Dec 24, 2020
…es-out-of-html, r=Nemo157 Move tooltips messages out of html First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up. So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice. So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other). Don't hesitate if a part of my explanations isn't clear. r? ``@jyn514``
|
☀️ Test successful - checks-actions |
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have
ignore,compile_fail,should_panicandedition. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (
::beforeand::after). The message is now inside::afterand we use the::beforeto have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.So now, back to the
editionchange: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip callededitionwhich contains this information. Then, the::afteruses it inside itscontent(you can get the content of an element's attribute by usingattrand concat different strings by simply having them after the other).Don't hesitate if a part of my explanations isn't clear.
r? @jyn514