Mastodon: Installable and shareable custom CSS themes

[TrechNex]

Pitch

Currently to install a custom theme, instance admins require code level access to a Mastodon installation. This is not always the case. For example, I use masto.host where I do not have this kind of access. Non-technical users may also have no interest in hacking the underlying code of their installation.

In addition, adding content to the "custom CSS" box is not portable and applies to every theme that any of the users of that instance select, and this may not be desirable behaviour.

This issue suggests that the Mastodon admin panel should enable admins to upload a CSS file, and for that theme to then be available in the same drop-down menu that already exists in the site admin panel. Selecting that theme would then apply it on a site-wide basis.

In addition, this issue suggests that individual users should also be able to apply their own CSS theme in a similar manner from the User Preferences settings panel. In this case, the theme would apply for that user only.

In a future iteration CSS themes could be edited in-browser, with the added option of exporting it to a file that can then be shared with and installed by others.

Motivation

Future drama over default CSS choices can be avoided if it is easy for individuals and site admins to install their own custom themes to override it, should they feel that those choices do not meet their needs or aesthetic tastes.

In addition, this enables instance admins to further customise their instances according to the particular userbase they are targeting their server for. You would find certain themes would become quite popular and those that appeal to the development team could be included by default in future releases.

Finally, users with specific accessibility needs can make any and all visual changes they need to without having to ask their admin to make code changes to the instance.

[nightpool]

I really like the idea for individual users to be able to install and share themes, but I want to remind you that the fact that masto.host doesn't let you upload themes is a deficiency in their product, and it's not something we can fix. We're not involved with masto.host and you'll need to talk to the person you're paying money to about why they won't let you perform one of the most basic admin tasks.

[Fidgetcetera]

Why can't it be easier for an admin to update their own themes than having to manually go into the backend and edit files, anyway, though?

[Fidgetcetera]

I can see a lot of reasons why you don't want to give an admin of your instance complete access to mess with config files and upload themes that way, but you do want them to be able to upload a theme.

[nightpool]

@Fidgetcetera two main reasons: theme code is not CSS, it needs to be compiled and processed by the backend, which is completely separate code and can't easily be done for production setups without running code in the terminal and restarting the server. Second: unfortunately, there are still a lot of bad things you can do if you give an untrusted user access to CSS files, like add trackers or socially engineer people by impersonating admins. Code is code is code, and allowing an "easier" trust boundary for editing CSS is still a security risk.

(which is why any implementation of this issue would need to a) make it very easy to disable a theme and b) make sure users understand where a theme comes from and who wrote it. and maybe that wouldn't even be enough)

[TrechNex]

@nightpool the service limitation is by design. Basically people who use masto.host are paying to not have to worry about installations, upgrades, permissions, etc. This is why we're stuck with the 3 stock themes and that's it unless we start adding content to the custom CSS box. It's also why it's so popular with non-techies.

For security if you mandated a template then you could also create a common mechanism to validate & interpret it, no? In so doing you could whitelist or only implement the elements you intend to support.

[nightpool]

@bobstechsite So you're saying if masto.host implemented the feature you want mastodon to implement, masto.host would be less useful to you? I'm not sure I understand.

I agree there are ways to get around the security issue, it's just important to understand that there is one.

[TrechNex]

Expecting non-techie users to edit source code (eek!) for an installation that will be trashed and replaced with an unmodified version in the next update (d'oh!) would be less useful, yes. :grin:

But even for people not using that service, the ability to install themes through the Admin UI would be a big timesaver, and it reduces the risk of breaking a production server many users might rely on. So even for budding sysadmins there are benefits.

[nightpool]

@bobstechsite i'm not sure what you mean. writing css is editing source code no matter where you put it......

and you're still arguing against a strawman of the feature. "an installation that will be trashed and replaced with an unmodified version in the next update" is obviously not a useful implementation.

[TrechNex]

I think we have crossed wires and are getting hung up on the wrong thing. So, some clarifications:

• The service I gave as an example is a managed host that gives you your own instance if you pay them money. My own instance (Bobadon.rocks) runs on top of it, as do many others.

• My feature suggestion is to provide a supported UI way of doing something you currently have to edit the underlying source code for Mastodon to accomplish. Not everyone has the desire to mess with production systems in this way just to add new themes.

• My initial thought was to upload a raw CSS file, but as you indicated that would have potential security ramifications. Maybe it is better as a template or config file instead, with behind-the-scenes logic to validate & interpret it?

[nightpool]

I really like the idea of a template or UI for customizing mastodon instances, and a way for users to create and share custom themes (and possibly a way for admins to provide these themes to users by default). I think both of those would be great additions to Mastodon and I would love to flesh out support for them.

I don't think the deficiencies of a specific managed hosting platform are a good justification for adding new code to Mastodon. They (a for-profit company) chose to cut corners on customization—that's not a good reason for imposing the technical burden on a volunteer-run, patreon supported free software project. There are managed mastodon hosting platforms, like https://free.m.to/, which do support this kind of customization, using a custom CPanel-like interface.

[trwnh]

This might also be handled by a simple plugin architecture for loading CSS over the precompiled SCSS. One monolithic "custom CSS" field is pretty limiting for compartmentalization and sharing. Yes, userstyles exist for (desktop) users. But then you have to worry about syncing changes across every browser you use, or putting everything on userstyles.org and having to go back to that page just to edit an option in the theme.

I'd take a stab at it but I have no idea how to write the UI components, I only do CSS and design. Maybe I'll edit this later with a mockup...

[TrechNex]

A plugin framework would be ideal! I was fearful of suggesting that in the first feature request I've ever made for this project because (much like this suggestion) I'm not the one that'd be implementing it, and therefore have no idea how large a job that would be. :sweat_smile:

[trwnh]

@bobstechsite now that i'm at a computer, see #7717 for that specifically. as well as the more generally possibly-related issues #8056 #8612 #9281

[TrechNex]

That being the case, I'm satisfied with the resolution of closing this issue as a duplicate. :+1:

If styles can be applied by setting variables through the UI and API that would achieve the same objective without requiring end users to write any code at all.

If Mastodon adopts a plugin framework then that would satisfy the objective of sharing and installing of themes between admins of instances.

In the interim I would implore @Gargron to reconsider his stance on #9898. (I'm sure there's a better way to do things than my own ham-fisted custom CSS!)

The "High Contrast" theme work-around suggested in the PR is not applied when I select it on my 2.7.0 install, and others I've spoken to are reporting a similar problem. I'll get in touch with the tech support of my managed host to determine if that's an ops issue or bug that needs raising.