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

Use data-theme attribute for themes on root element #1706

Merged
merged 2 commits into from Jun 26, 2022
Merged

Use data-theme attribute for themes on root element #1706

merged 2 commits into from Jun 26, 2022

Conversation

Shane4368
Copy link
Contributor

@Shane4368 Shane4368 commented Sep 21, 2021

Use CSS color-scheme property
This sets light/dark theme on scrollbars and form elements.

Remove switch statement and directly apply theme in setTheme function
This change allows additional themes added by a plugin to work without attaching a new listener to #theme element; also prevents rechecking of localStorage to add the custom theme to body.classList.

* Add custom CSS property --color-scheme

* Remove theme check in setTheme function
* Also declare --color-scheme property under each theme selector
@Gerrit0
Copy link
Collaborator

Gerrit0 commented Sep 22, 2021

This seems reasonable, but I'm not sure it's sufficient. If you add a new dark theme option, but the user's OS theme is set to light, code blocks in the rendered page will be rendered with the light theme when selecting your dark theme...

Is there any major benefit to using a data-theme attribute rather than keeping with classes? Doing this switch is a breaking change that doesn't seem necessary.

@Shane4368
Copy link
Contributor Author

Shane4368 commented Sep 22, 2021

Based on my testing, the code blocks will match the selected theme. https://typedoc-theme-test-shane4368.surge.sh/classes/Bird.html#beginFlight
Edit: Your statement would be true normally, but I override the CSS properties in the plugin.

Using classes for themes would require additional logic to replace the current theme with the selected theme.

<html class="default no-js not-mobile toggle-visibilityprivate toggle-inherited dark">

Using the above as reference, if you wanted to change theme, you'd have to do html.classList.remove("dark") then html.classList.add("selected-theme"). But "dark" could be any value; you'd have to track the current theme or html.classList.remove(localStorage.getItem("tsd-theme")).

body.light { --color-scheme: light; } also doesn't override if it's set on the root element, resulting in dark scrollbar on light theme if OS theme is dark.

If it's a breaking change, you may add this whenever you decide to release 0.23.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Sep 23, 2021

Tracking the current theme doesn't seem too bad to me - at least until 0.23, where the data attribute is probably better going forward. I didn't know about the colored scrollbars possibility - that's neat, and a really compelling reason to move to :root

Just a note: The hardcoded hl-1 through hl-7 might work today, but there's no guarantee that it works in the future. Those classes are completely dependent on the themes the user chooses. If someone writes a theme that has 50 different colors, it'll behave badly. I'd really rather give plugins like yours a way to handle this nicely. Maybe themes in the dropdown could specify two values?

@Shane4368
Copy link
Contributor Author

The hl colours being out of my control was an oversight.

Maybe themes in the dropdown could specify two values?

Like setting a custom hl theme before the html gets written to file, if it's supported? I'm okay with that.

@Gerrit0
Copy link
Collaborator

Gerrit0 commented Sep 24, 2021

I was thinking of making values contain two items, e.g. hl-light light and hl-dark dark, then your themes would specify hl-light custom for example.

Unfortunately supporting custom highlighter themes for each scheme is expensive, adding ~400ms per 1000 lines of code highlighted for each theme (shikijs/shiki#234)

@Shane4368
Copy link
Contributor Author

Oh. That should be fine.

@Gerrit0 Gerrit0 added this to In progress in TSDoc - v0.23 via automation Oct 22, 2021
@Gerrit0 Gerrit0 moved this from In progress to Done in TSDoc - v0.23 Apr 10, 2022
Gerrit0 added a commit that referenced this pull request Apr 10, 2022
@Gerrit0 Gerrit0 added this to the v0.23 milestone Apr 17, 2022
@Gerrit0 Gerrit0 merged commit e2d8327 into TypeStrong:master Jun 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants