Let users customize themes with URL-encoded styles

[a-trost]

It would be great if you could customize themes with data stored as URL parameters. Similar to how Cloudinary/Imgix do their image transforms with an image API, themes could have a Theme API where everything gets added to the URL.

Customized URLs might look something like this:
https://showmy.chat/c/TrostCodes?theme=frontend-horse&text-color=03ae92&bg-color=03ae92&mod-bg-color=03fa20&font-size=16&font-family=Roboto

These could be defined per-theme with a JSON object, providing labels, types (color, text, select, integer), etc.

Then in an interface, you'd be able to customize the different properties. Here's a quick mockup of how I see this potentially looking:

If you paste an old URL in, the values would load and you'd be able to easily customize once again.

We'd need to decide if some themes just have small customization options, or arent' customizable at all. Or if there are standard values across all themes, like font-family or text-color. I worry that would limit the potential creativity of future themes, so letting each theme create its own properties feels like the most flexible way, if not a tad chaotic.

This would also address #2

Caveat

This idea assumes demand for people to deeply customize their themes.
It might be better for the time being to focus on building out more theme styles that people like, rather than putting the onus on users to create a style they like through this method.

@BenDMyers did mention that you could get around this URL encoding bit by adding custom styles in OBS which is a great workaround.

[BenDMyers]

A few folks have suggested high customizability is something they'd want, which is making me kind of rethink what showmy.chat should be. I'd initially envisioned showmy.chat as a plug-and-play solution with themes that look nice and work well enough out of the box — sacrificing flexibility for simplicity. To that end, customizations have largely touched on functionality over appearance.

However! I don't think that original visions need to be kept pristine and intact, particularly if I thought people needed/wanted one thing, when what they really need/want is another.

Here are some thoughts that I've got, in no particular order. These aren't meant to discourage doing this, particularly if there's serious interest in having this as an option!

• What would introducing high configurability mean for maintenance down the road? Unless we break out a versioning system (which is already something I'm considering anyways if/when the time comes), we'll need to support customizations faithfully and not break users' expectations. A user's URL should work reliably more or less ad infinitum, and that means early decisions about properties and whatnot will have to be supported until we can break out a new, separate version. This might make things like splitting up one query parameter into two or more very hard.
• To what degree should themes be expected to respect/support users' preferences? The answer to this should probably be "to a large degree, themes should respect/support preferences," but is there a line to draw here?
• Is it worth building out a fully fledged theme customizer product as a separate, distinct product from the plug-and-play themes? This could live on the showmy.chat domain, likely with its own path (using a different path extension than /c/), and use a lot of the same logic for parsing/displaying logic — but kept separate from the simpler plug-and-play experience. This might help with maintenance, or it could make maintenance a lot worse.
• At what point is a theme so customized, it should really be its own theme?

[ajcwebdev]

This is awesome Trost! I do a lot of open source and it's rare that people come to the table with high quality mock-ups like this, so kudos to you.

My own 2 cents is I think this is still in line with the original vision as I've seen it play out since showmy.chat started because the ability to create your own theme has always been there, but it has been more challenging to create for anyone without fluency in CSS.

This can be seen as a tool to help expand the palette of potential plug and play themes. I agree though that it will require a lot of forward thinking to make sure you don't end up trying to rebuild Figma. At some point the intricacy of creating a design tool within your own site becomes more trouble than it's worth.

But at this point there's far more control we can give through a low code tool, which is how I see this adding a lot of value today.

[NickyMeuleman]

tagging in #78
Should this "theme-customization-builder" generate a .css file with custom property overrides that can then be used through an url, like theme currently?
What I'm thinking of is potentially:

1. A theme uses CSS properties.
   eg:

   :root {
      --background-color: red;
   }
   body {
      background-color: var(--background-color);
   }

2. This builder creates a file that sets the desired overrides
   eg:

   body {
      --background-color: blue;
   }

3. You use the output css from that tool in a place where you can add custom CSS, like OBS browser source.
   https://obsproject.com/wiki/Sources-Guide#browser-source
   OR you host it on the internet somewhere (like a github gist?) and use it with an url like: https://showmy.chat/c/TrostCodes?theme=frontend-horse&customization=https://site.with/overrides.css
   OR you can configure the tool to include query parameters that then set the corresponding properties via the serverless function

Those ORs aren't mutually exclusive, you'd only do one, but maybe they're all supported in this hypothetical.