dark mode

[dirk-bester]

So based on this conversation with our intrepid leader I went forth to gather data. https://discord.com/channels/1003691521280856084/1003699523522142399/1080749824653135932

I am not working at Adobe anymore so no Adobe dollars to spend on user studies. But school me if I am ignorant of The Way.

However the meta question is really, what is the state of dark mode? This starts on the device where we ask our Mac, iPhone, iPad, PC, Android, Arduino? to be 'dark' or 'light' or 'auto' etc. (The latter is my choice and I supplement that with a reduced glare and blue light setting at night time.)

So I went through all 47 apps open in my dock. Trash is a duplicate and Launcher is N/A. The following had no dark mode:

• NCalc, but it is light on UI, heavy on calc anyway.
• Steam and Battle.net were designed dark and as hybrid web apps anyway, basically just 2 browsers.
• Chrome doesn't care about dark mode at all, but some intern wrote an experimental "force dark" mode. Truly pathetic and just 100% wrong!
• Safari, Opera, Firefox obey the modes, but like Chrome suck at the actual websites themselves doing dark mode. But they do all transmit the device settings. Also their actual corporate websites are fully dark mode aware and support dark, light and auto on the Mac and iOS.

Conclusion

So I actually modified my view a lot. I agree with Chris it should be simple. I now think this is how every website should work:

• Automatically obey the device setting and change as the device tells you. Period.
  • This is especially important on iPad as it moves from sunlight to shade or indoors or night. You want the web to just automatically do the right thing per the device.
  • Also, you don't want to make users hunt for some switch to click, the default should just do the right thing. It's bad enough doing the "dumb cookie dance" and lately the "whack the popup ad" game. Let us not add a LighSwitch trip.

This is accomplished by the existing autoModeWatcher() and setInitialClassState() in LightSwitch.

Ointment Flies

There is one fly in the ointment. Not all websites rock good dark or light modes. Also user preferences are fickle so sometimes they want to force a light or dark choice. I like to code in dark mode only as an example. But users should be able to revert to the system setting again, it's polite.

Recommendation

I would recommend upgrading the current binary choice switch that disables going back to the system mode with one that does. https://xgrams.vercel.app/ has a refactoring of the current code that only adds that specific part (moon button, top left). A lot of hacking went into that version to simplify some stuff and I figured out some svelty ways of doing other things, it was quite the adventure! I renamed everything so it can coexist with LightSwitch with no chance of colliding variables, npm doppelgangers, unkown knowns, etc. That process would get reversed if we want this switch of course.

I think reducing the choices we give skeleton users here is important, with an emphasis on "doing the right thing automatically". I read substantial amounts of the showcase thread and saw the lamentations that people tend to just copy the given AppShell etc. as is!

Discussion needed (post 1.0)

Anyway, thoughts, comments, discussion. I doubt I covered all angles on the topic. Also I found a related discussion about the sausage of how we do dark mode vs tailwind which also has a pure css as well as a system mode which I think we don't support yet, at least not according to a quick test.

[riziles]

I love your Moon Phase Switch. I love it so much I might steal it (again), but... I think the use case is edgy enough that it doesn't need to be part of core skeleton. Having the ability to switch back to system theme is really only necessary on a website that I'm going to be on all day long, and most Skeleton projects probably won't end up in that category.

That said, there are a lot of things I wish were in Skeleton but I realize aren't practical or realistic to have as part of the core library. I would propose that your Moon Phase Switch be the first entrant into a robust and vibrant ecosystem of plug-and-play Skeleton extensions. Aesthetically, Skeleton is about the best UI system I've seen even though other systems may have more features. If people are building functionality around Skeleton without having to pester the core maintainers, I think the community will continue to grow and adoption will accelerate.

[dirk-bester]

By the way, you can pass in any 3 components you want. That really simplified a11y because skeleton icon buttons passed in just work.

I don't think it is edgy, but how you want the web to work. Here, take a look at the second button from the top right. https://tailwindcss.com/ Our current 2 way switch is actually disabling built in tailwind functionality. It is most certainly at odds with how every single dark mode capable desktop app works.

What we put in the core matters. It forms the default. Hunting down stuff elsewhere is a smaller chance affair.

[Sarenor]

Doing it 3 ways with replicating the system default is a very cool idea, but there's still a couple of problems.
Afaik Windows support for applications getting notified that color preference changed (or that it's set to auto and now displaying dark instead of light or vice versa) is still not implemented or at least not implemented well and everyhere, afaik.

So the "adhere to system preference" setting would mean that a browser needs to be restarted/refreshed to reflect the current system preference in windows afaik which is just bad as well.

What I'm trying to say is that this is (sad as it is to say) a bit at the cutting edge of web development and capabilities and if we want to avoid bleeding and pain, waiting a bit might not be the worst option.

[Sarenor]

Also to add to this, and I'm not 100% sure if I'm reading this right but, the current lightswitch is kind of the same as the tailwind one:

/** Set the visible light/dark mode on page load. */
export function setInitialClassState() {
	const elemHtmlClasses = document.documentElement.classList;
	// Conditions
	const condLocalStroageUserPrefs: boolean = localStorage.getItem('modeUserPrefers') === 'false';
	const condLocalStroageUserPrefsExists: boolean = !('modeUserPrefers' in localStorage);
	const condMatchMedia: boolean = window.matchMedia('(prefers-color-scheme: dark)').matches;
	// Add/remove `.dark` class to HTML element
	if (condLocalStroageUserPrefs || (condLocalStroageUserPrefsExists && condMatchMedia)) {
		elemHtmlClasses.add('dark');
	} else {
		elemHtmlClasses.remove('dark');
	}
}

As I understood it this checks for saved user preferences in local storage and if there are none, it tries to select the users preferred color scheme and sets the mode depending on that.

[endigo9740]

@Sarenor is correct, we default to OS preference by default. That's been a thing since the first Lightswitch was implemented months ago. BUT, if a user preference is selected, then it uses that. Because that's what the user has opted into. So the only thing missing in the current lightswitch is a means to return back to the OS preference (aka "system").

I've expressed my opinions for why I don't think this is a useful option. I've also expressed ways for developers to work around this via the getter/setter methods we provide. These are the same tools the Lightswitch is built on. Think of it like this, the Skeleton Lightswitch is just a dumb UI onto of these methods. Which means ANYONE can build their own Lightswitch UI.

What might someone do with these methods?

• Build a three way toggle as suggested by Dirk
• Build a single button toggle that flips between 2 or 3 states as preferred
• Conditionally check the value of the OS or user preference
• Conditionally set the value of the user preference

Essentially we provide and API for everything that's been suggested or pretty much any use case folks could have beyond our simple toggle.