Enable userchrome.css for plugin webviews

First of all, this a very low priority topic. I'm just curious if it is currently possible. Because I could not get it working. I've tested two options but both don't work.

  1. add as script with 'profileDir' as full path:
const profileDir: string = await joplin.settings.globalValue('profileDir');
await joplin.views.panels.addScript(panel, profileDir + '/userchrome.css');

=> Does not work because addScript adds the current workingDir to the path. So only relative paths can be used here.

  1. So I've tried a relative path (doesn't matter if it would be right):
await joplin.views.panels.addScript(panel, '../userchrome.css');

=> Causes the following error on app start.

joplin.plugins: Uncaught exception in plugin "joplin.plugin.note.tabs": 
Error: Script appears to be outside of plugin base directory: ...

So my question is... is there another way this could work? Or is it unsupported on purpose?

It's a hack, but you could just copy it where Joplin can load it from.

The plugin API exposes a number of CSS properties to give the font, background color, size, etc. Is it not sufficient for plugins?

In any case, please don't fetch files in the profile directory, as it's likely to make your plugin break at some point as there's no guarantee that the profile structure will stay as it is.

In fact I will perhaps disable access to profileDir and a few other setting variables as giving access is going to prevent further improvements to the app, since it won't be possible to change it anymore.

No from plugin point of view it is okay how it works right now. I am okay with providing settings which allow users to change the style of a plugin.

But some users asked in another thread if it could be supported. From the user's point of view, it would of course be nice to be able to make all the style changes in one file.
As I said before, I don't see this as urgent. Perhaps we should wait and see if it is requested more often.

I see what you mean, although for now custom CSS support is relatively low priority because it makes things more complex and it's not clear if the work involved to support it is really worth it. For now I would just like to mention that it's best not to implement solutions around access to profileDir, as that might break.

I would prefer instead to improve access to the built-in themes so that plugin views can match the current theme. This would benefit everyone, while custom CSS is more of a niche feature, at least I assume so.

1 Like

I can understand this, but it should be possible to determine/access the path somehow, so that e.g. during a backup also the templates, keymap-desktop.json, css fies could be backuped.

Right I forgot about this. In that case some access to it is indeed still needed for now.

1 Like

Custom css may or may not be a niche feature, I don't know. I am just commenting here to say that I use it and very much appreciate its existence. Moreover, the liveliness of threads related to custom css suggest that, if it is a niche interest, then the niche might be quite a large one!


Yes a lot of nice stuff are being done using the custom CSS feature and that's great. However since we don't track users we have no metrics to know how many people use this feature. If it was like 50% then it would make sense to look if it can be integrated to the plugin system, but I don't know I expect it's like less than 5%, which makes it low priority compared to other features.

This was suggested on another thread, and I wonder if it is an easier solution? Or something like manually adding a userchrome-.css file would make it accessible. I know I am a minority, but CSS is my favorite feature of Joplin. :slight_smile:


I don't use custom CSS actually, and I'm curious why is it an important feature? Is it because the available themes are not good enough? If so, wouldn't the solution be to create more themes? Then theme variables could be made available to plugins, thus making them automatically match the current theme. I feel that's a more elegant solution that would be available to everybody, even those who don't know CSS, but maybe I'm missing something.

1 Like

Hi Laurent. I can't see these properties in the API, where can I find them?

They aren't well documented yet, but you can see some of them in the TOC tutorial:


Basically it's all the variables in the theme file prefixed with --joplin-

1 Like

I found these while I was messing around with the development tools: