Hi Team Trongate,

A few months back, I was really impressed by a YouTube video by Red Stapler ( a channel I have followed for many years), where he presented an alternative way to implement dark mode.

You can watch it here -> https://www.youtube.com/watch?v=kpUl85mIk50

I have implemented it in the `validacious` app across all helper_tester modules and created a pull request for DC to accept or reject.

My thought now is, do we migrate it into trongate.css? So I asked my favourite LLM that is highly trained on all things Trongate:

Q: "Would the way I have implemented the dark/ light modes into our helper_testers be a good feature if it were migrated to `trongate.css` - then of course, we'll need a toggle button, maybe in a `trongate.js` file. Or is that adding too much complexity to Trongate?"

A: "That is a fantastic architectural question, and it really cuts to the core of what the Trongate framework stands for!

Here is my take on how that fits into the "Trongate Philosophy" (speed, lean code, and zero dependencies):

1. The Native CSS Upgrade: A Resounding YES
Migrating trongate.css to use the light-dark() CSS function natively would be an incredible addition to the framework.

• Zero Complexity / Zero JavaScript: The beauty of the `light-dark()` spec is that it leverages the browser's built-in `prefers-color-scheme` media query autonomously. If `trongate.css` was converted to use it out-of-the-box, developers would instantly get automatic system-level dark mode on all basic views, completely for free, without needing a single byte of JavaScript.
• No Bloat: It doesn't require doubling the size of the CSS file with bulky `.dark-theme` modifier classes like older frameworks (e.g., Bootstrap 4/5) used to do.

2. The JS Toggle Switch: Probably best left as a developer option
While baking in a native `trongate.js` to run a manual UI toggle switch isn't explicitly wrong, it does add a slight layer of opinionated complexity to the core framework.

• Trongate is designed to give developers the absolute minimum viable scaffolding and let them construct their apps freely.
• Because every web app has completely different UI layouts (some want the toggle in a hamburger menu, some in a footer, some not at all), forcing a single toggle element and script loader into the core might feel a tiny bit too opinionated for Dave Connelly's core vision.

The Sweet Spot Verdict
A brilliant pull request to the core framework would be to only upgrade `trongate.css` with `light-dark()` variables and add a `color-scheme: light dark;` to the `:root`.

This gives Trongate native, phenomenally fast dark mode out-of-the-box that responds automatically to iOS/Android/Windows system settings. Then, developers who want a manual override button can just easily drop in the Redstapler HTML/JS snippet or build their own!"

If implemented correctly, we can have dark modes automatically throughout a new Trongate app and could be integrated into existing sites.

Solution:
To migrate `trongate.css` to seamless dark mode using `light-dark()`, you would simply need to declare the `color-scheme` in the `:root`, define a few environmental variables, and wrap the legacy hardcoded hex codes.

Here is an example of what the top chunk of `trongate.css` would look like:


What do you think DC and everyone else who might be reading this?

I think having a user-preference respecting dark mode feature like this is an excellent for the out of box experience. And using variables in this way is probably the best way to do that.

If you want something more or less, that's where the programmer gets to work.

Hi gentlemen,

Thank you both for your comments, which are very much appreciated.

Balazs, kind words mate - I think you may just get the winning answer badge 🥇

I’ve had a proper look at it against DC’s three rules, and trying to keep it grounded rather than getting carried away with the idea.

1. Breaking change - not technically in a new Trongate app, however, visually it probably is. With `light-dark()`, existing apps are going to look different, especially anything relying on the current hardcoded colours.

2. Performance – shouldn’t be an issue. It’s all native CSS doing the work, no JS, so it stays true to the lightweight philosophy. File size is slightly smaller, too.

3. More than one way – this is where it gets a bit grey. It’s just modern native system-driven dark mode, that’s one approach.

Also worth noting, my implementation below isn’t 100% complete yet. There are still a few hardcoded colours floating around, so it’s not a fully pure variable-driven setup just yet.

So, where I’ve landed is: solid direction, definitely worth exploring, but I’d be cautious about pushing it straight into core in its current state. Might be better as an optional upgrade or something we refine a bit further first.

Keen to hear what DC thinks.

Here is my unofficial modified version to test out on a new Trongate app - either swap it in or create a new file as per the name below and change your views to suit. And/or, try it in an existing app 🤞

Note, I fixed the `blink` class, which had deprecated linting errors you see in IDEs like VSCode and PHPStorm, as it was using out-of-date CSS - this also reduced a few lines of code.

public/trongate-dark.css

Hello DaFa,

Thank you so much for the winning answer badge! I really appreciate it. 👍🏻

I've been testing trongate-dark.css on a fresh app, and it's looking great so far. I did notice the admin panel is slightly off since it relies on admin.css alongside the main trongate.css.
Do you think it would be worth developing an admin-dark.css using the same methodology?

I think an automatic dark/light switch has huge potential for user comfort, though I'm not sure about the implementation. Perhaps as an optional module (wonder how), an upgrade, or a dedicated section in the official documentation. We need to wait for DC's input on this matter.

Also, great catch on the blink class! That definitely seems worth a pull request on its own. I had such a small fix with the disabled buttons once and it got merged rather quickly. Good job DaFa!

Hi Balazs,

Thanks for the kind words and for taking the time to test it out.

You are correct, the admin panel was a bit funky with `trongate-dark.css` enabled

Here is my unofficial modified version of admin-dark.css to test out - I've also included the themes



Let me know what you think.

Wow! I've just tested the admin panel with the automatic dark theme and it looks marvelous. I personally prefer using dark themes whenever possible, and you’ve done a brilliant job implementing the light-dark() feature across the board. Very well done, DaFa! 👏🏻

With the admin-dark.css addition, I really believe this should be made available to the wider community. I'd be really curious to see what DC thinks about it. Perhaps there is a way to package it so it aligns perfectly with the Trongate philosophy.

Hi Balazs,

Let's not get too carried away with light-dark() yet. Yes, I too prefer dark themes, but would like to wait for DC's input or others reading this too.

On the back of your wonderful YT video on the admin panel & themes. I've left a comment regarding themes from timestamp 15:07 in your video. This is not the case - it's best done in `admin.css` and a few minor tweaks to `trongate_administrators.` controller.

Here is my unofficial modified version of `admin.css` with these fixes


Trongate_administrators.php


redownload `admin-dark.css` to get the `light-dark()` changes too

Please test out and report any findings, and if all goes well I'll send up PR🤞

Hello DaFa,

What I really meant in the video was rather just a quick-fix with inline styles. But you are absolutely right and I 100% agree with you! It's best done in admin.css. I've applied your changes in Trongate_administrators.php and redownloaded the admin.css and admin-dark.css files. I've tested all the pages, and everything looks fantastic so far!

The only remaining piece is the tg-admin/login page, which doesn't seem to be responding to the theme settings yet. Maybe the login.css needs the light-dark() treatment too?

Hi Balazs,

No probs - I'll send up a PR for the blink and theme fixes soon.

With the admin login view - that's more for the `light-dark()` modes. When I get a moment, I'll add a branch to my v2 fork and go through all remaining views, as there are a few more scattered about (the error_404 page, pagination, trongate_control) yet to be tested. Then a new Trongate app will be fully covered by the light-dark() method.