Theme switcher - Remove auto from the list of themes

[raphigaziano]

Hi.

When toggling between themes, the click seems to be a no-op whenever it switches from or to the os/browser's preferred theme.

This is because if my preferred theme is, say, "dark", then the theme attribute is set to "dark" when switching to auto, and stays at the same value when it then switches to "dark".

I removed the auto string from the themeList array, and kept the logic for handling it as an argument to setTheme and defaulting to it if no variable is set in localStorage, which seems to fix the issue.

I can submit a PR with the fix it that clears things up.

Not quite related, but I don't quite understand why the theme in stored in two different attributes (data-theme and data-user-theme). Does it make a difference when styling ?

[matthiask]

Hi

We're doing the same thing the Django admin does -- switch between forced light, forced dark and automatic. So, it's expected that one of the theme changes doesn't produce any visible change except for the button and icon itself.

I think it could be argued that forcing a light theme when the system is configured to prefer light schemes and vice versa doesn't really make much sense, but again, we're following Django's lead here.

The difference between data-theme and data-user-theme is that the former describes the theme which is currently active in the browser and the latter describes the user's preference. So, data-user-theme=auto can exist, data-theme=auto cannot.

[raphigaziano]

Thanks for the answer. I don't really see the benefits, but I understand the reasoning of staying consistent with what django does. I'll go see if the topic has been discussed on their end.

Regarding the two different attributes, I understand the finer granularity, but again I fail to see the practical use (I'm mainly thinking about styling and may very well be missing something obvious. Sorry if it sounds critical, it's an honest question and I understand this is not really the place for those. Feel free to close the issue if the question is not pertinent).

[tim-schilling]

Wouldn't the auto also follow the user's dynamic preferences? For example, I have my system configured for a light theme during the day and a dark theme at night. Removing auto as an option prevents me from that utilizing that feature (I think).

[matthiask]

So, data-user-theme controls which icon is shown in the button and data-theme controls the rest of the toolbar styles.

I'm mainly thinking about styling and may very well be missing something obvious. Sorry if it sounds critical, it's an honest question and I understand this is not really the place for those. Feel free to close the issue if the question is not pertinent.

Asking questions is fine!

I myself probably wouldn't have implemented theming support anyway for the toolbar but since it's here now I'm trying to explain why things are how they are currently. I'm not saying everything makes a lot of sense.

The thinking is that we should allow three things:

• Users always wanting the toolbar to use the light theme
• Users always wanting the toolbar to use the dark theme
• Users which want the toolbar to follow their systems preference

I don't really see a way to simplify or remove things without hurting one or more of those groups.

[matthiask]

As an aside: What we're doing here seems to be quite common. Just as a single example, here's the Figma theme selector:

The theme selector of my terminal emulator:

[raphigaziano]

I hadn't thought about the dynamically changing settings. And I guess this also allows the style to update automatically if you go and change the system's settings.

So yeah, it makes sense, especially for a library/framework. Thanks to both of you =)

I guess what tripped me up is the toggle UI. I saw examples like the ones you listed many times and never thought about it, as it allows you to directly select what you want and bypass the "click didn't do anything" impression.

Not sure if adding a panel for this is worth it though.

[matthiask]

Not sure if adding a panel for this is worth it though.

A panel would certainly be too much, but maybe we could instead use a hidden <select> (where you only see the dropdown once you click on it) instead of the tristate button. Not sure if it's worth it.