Skip to content
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

Code fences / inline code: provide a 'dark' mode #1219

Closed
ang-zeyu opened this issue May 2, 2020 · 4 comments · Fixed by #1355
Closed

Code fences / inline code: provide a 'dark' mode #1219

ang-zeyu opened this issue May 2, 2020 · 4 comments · Fixed by #1355

Comments

@ang-zeyu
Copy link
Contributor

ang-zeyu commented May 2, 2020

Is your request related to a problem?
na

Describe the solution you'd like

  • provide a dark mode for code fences / inline code using markdown-it-attrs
    • maybe make it the default as well, since contrast is generally better in dark mode

Describe alternatives you've considered
na

Additional context
na

@damithc
Copy link
Contributor

damithc commented May 3, 2020

How does the dark mode work for printing? i.e., does it revert to normal mode when printing?

@ang-zeyu
Copy link
Contributor Author

ang-zeyu commented May 3, 2020

yup it should use the 'light' mode colors ideally

@ryoarmanda
Copy link
Contributor

ryoarmanda commented Sep 8, 2020

I'm taking up this issue but unsure how to proceed. So far I have investigated that

  • Highlight.js does support many light/dark themes (see https://highlightjs.org/static/demo/) so hoping that I can leverage this for our uses
  • To support the case for automatic switch to 'light' mode when printing, the styling for light and dark mode must be able to be toggled in some way. But, it's not really possible for us to reliably detect print events in js (see https://stackoverflow.com/questions/11138939/how-to-trigger-javascript-on-print-event) so we can't toggle to 'light' mode just before printing. If we use something like a @media print rule instead of detecting print events, the problem shifts to us needing to provide the whole 'light' styling inside the rule.
  • Even if we can detect print events, the problem also changes to us needing to wrap the 'light' and 'dark' stylings into classes so that both can be easily toggled, which is probably not possible as pure css doesn't support nested selectors.

I think the quick-and-dirty way is to manually copy one of the dark theme stylings supported by highlight.js and then paste it in @media screen of our css, and use the default styling (the one that we use now) as the 'light' mode for printing, so we only need to copy over one set of styling. It's not pretty but it's an easy way to do this, and the stylings are pretty short (checked some and I haven't seen one that goes over 100 lines). Would this be okay? @ang-zeyu

@ang-zeyu
Copy link
Contributor Author

ang-zeyu commented Sep 8, 2020

not pretty but its the cost of doing business
ideally we can combine media queries and selectors so we don't need to duplicate things, but css didn't intend for that =P

as you saw the light styles are pretty short though, so no need to worry about bundle size

perhaps you could add in sass in the webpack compilation process so we can use mixins to remove surface level duplication at least - we'll also need sass support somewhere down the line to get #903 done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants