-
Notifications
You must be signed in to change notification settings - Fork 189
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
Adapt syntax highlighting on dark theme #2769
Conversation
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'm thrilled to see us fixing this, thank you!
A couple of things to consider.
src/web/src/pages/_app.tsx
Outdated
|
||
// Enable the stylesheet for the syntax highlighting depending on the theme | ||
if (preferredTheme === 'dark') { | ||
document.querySelector('#light-stylesheet')?.setAttribute('disabled', 'disabled'); |
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.
.disabled = true
see https://developer.mozilla.org/en-US/docs/Web/API/StyleSheet/disabled
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.
Question: should this happen within a useEffect
@DukeManh?
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, it should be useEffect of hooks/use-preferred-theme
src/web/src/pages/_app.tsx
Outdated
const toggleTheme = () => { | ||
setPreferredTheme(preferredTheme === 'dark' ? 'light' : 'dark'); | ||
if (preferredTheme === 'dark') { | ||
document.querySelector('#light-stylesheet')?.removeAttribute('disabled'); |
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.
We're repeating code here, let's consider moving this enable/disable logic to function(s), and maybe even put it in hooks/use-preferred-theme
so it happens when we get/set the theme.
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.
Why haven't we done this earlier. Thank @dbelokon.
One thing, let's use the minified css files to save loading time. https://highlightjs.org/download/
@@ -0,0 +1,10 @@ | |||
pre code.hljs{display:block;overflow-x:auto;padding:1em}code.hljs{padding:3px 5px}/*! |
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 possible for us to get these via node_modules/
vs. embedding directly in our code? Then we can get updates.
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, as I understand how next.js
deals with static files and CSS style sheets in particular, it might not be possible with the tools we have available...
If your style sheets were in src/web/src/styles
, you can @import
a style sheet found in node_modules
, but next.js
modifies the original file so that the @import
rule is not there anymore. So, we cannot access the github.css
and github-dark.css
files from the @import
rules like in CSSImportRule. And, even if next.js
kept the @import
rule, we wouldn't be able to find the original style sheet with an id
, because the style
element generated by next.js
does not have an id
.
If you place the style sheets in src/web/public
, you cannot @import
a style sheet found in node_modules
.
So, as of right now, it might not be possible. If someone knows a lot about next.js
, please let us know if you can think of a way to make this possible.
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.
In the worst case, we would have to use a dependency that copies certain files in node_modules
during next.js
compilation time for this specific case.
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'm surprised there's no way to do this with next.js, but if it can't be done, we can go this route. One question.
I am not very experienced with |
cc @DukeManh, @Andrewnt219 for thoughts |
@dbelokon I can help you. Let's ask people in the chat, otherwise we will think something. |
@dbelokon, I think you misunderstood the import CSS part. In React/Next, CSS files can be imported like a module in JS like so: @humphd, I don't think importing CSS files from node_modules would work for us because we want to give them |
What if you do dynamic imports and only pull in the one you need, when you need it? |
Would it work for CSS file? |
So, it seems that As I understand, it seems The main problem is that the CSS style sheet has to be a global one, because otherwise the elements that are annotated with the class names won't get styled at all. So, if you have two global sheets that apply to the same class names, you need to disable one of them for the other to work. If the styling was bundled in a React component, this would be much easier, but of course, we wouldn't have the problem of the style sheet being global anyway. |
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.
@dbelokon I feel like we're holding up "good" work in an effort to have "perfect," and this is the wrong approach: we should take what you've done, which is awesome, and iterate on it later.
Thanks for entertaining these discussions as we look for a proper way to solve this. It was worth researching.
@dbelokon could you please rebase this, and we can merge it. |
Hahaha thank you @humphd!! Going to rebase it shortly |
Rebased and squashed without conflicts! |
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 did it because it looked a little bit better, especially with GitHub's syntax highlighting. This is my opinion, though 😅 I can change it back to white background, if you don't mind |
For a "light" theme, I think white is the way to go. It helps with text contrast with accessibility. |
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.
All code blocks that the Telescope back-end sends us are annotated with highlight.js classes, so the front-end has to provide the stylesheet that defines these. Since the stylesheet is global, we have to link both stylesheets for light and dark theme, and disable either depending on the current theme.
Issue This PR Addresses
Fixes #2377.
Type of Change
Description
All code blocks that the Telescope back-end sends us are annotated with highlight.js classes, so the front-end has to provide the stylesheet that defines these.
Since the stylesheet is global, we have to link both stylesheets for light and dark theme, and disable either depending on the current theme.
Checklist
Quality: This PR builds and passes our npm test and works locally
Tests: This PR does not includes tests as it does not add new functionality or change it.
Screenshots: This PR includes screenshots or GIFs of the changes made:
Documentation: This PR does not include documentation as it does not add user exposed functionality. However, a couple of comments were provided in the code as well in the commit message to explain certain changes.