Plugin CSS Improvement Ideas

[uxamanda]

(Branching from a conversation here: 🎨 macOS theme for Joplin - #32 by uxamanda)

I was thinking about the Plugin CSS and how to make it 1) easier for plugin devs 2) more consistent from a design standpoint.

Right now each plugin (that is in an iframe) seems to have a copy of the CSS variables (i.e. --joplin-color-error: red; --joplin-color-warn: #9A5B00; etc).

Having these as named variables is great because then the plugin dev can use the same colors. Looking at a few plugins, they then tend to use them like

body{
background-color: var(--joplin-background-color);
}

This is ok, but wouldn't it be better if there was a css class called .joplin-background that was already defined with that color variable, and therefore the plugin developer can use the class and be done?

The benefit of this is that if someone making a great theme could override/set the "root" / predefined joplin variables and then it could cascade down to the plugin.

The way it is now, there is no easy way to have the plugins match the theme. Some plugins (i.e. Note Tabs) have advanced preferences that let me manually set each color, but this is not ideal (cannot easily change from dark to light, fragile) and most don't bother exposing them.

Known Issues

Note: Because the plugin's are iFrames, I think that there would still need to be a step somewhere (?) that brings the root CSS variables and/or the classes in, it just seems like that should happen automatically when the app loads, not only when the Plugin is built. (Maybe the dev would include a flag to "include core css"?)

Ideas from other thread:

@andrejilderda

Well, an iframe creates a new CSS scope. So even if I'd set the --joplin-background-color in the parent, plugins will not have access to it (unfortunately). The only solution to this would be that loadChromeCssFile(...) would also append the CSS to all plugin iframes or do some postMessage'ing to the iframe.

---

Anyways, just wanted to bring it up since I am a heavy plugin user, and I love the new theme.

[laurent]

Those are good ideas but my problem at the moment is that the theming feature of Joplin is a bit inconsistent:

• We have the actual themes (Light, Dark, Nord, etc.), which are defined by setting various colours for the background, main colour, etc. And it's those colours that are passed to the plugin views. The themes are implemented that way so that they work in both the desktop app and mobile app (which doesn't support CSS).

• And then we have the CSS theming, which has always been more or less unofficial because, while understand it makes it easy to customise the app, it conflicts with the "official" themes. It's also an uncontrolled environment because it's possible to set various CSS properties which might break the app. And of course, new app updates can also break themes. In comparison, themes are safe because the defined properties are used only in places where it makes sense.

So ideally there would be a unified way to theme the application. Perhaps it means dropping support for the official themes and instead going full CSS? Or, on the contrary, drop support for custom CSS and improve theming support, for example by allowing to set paddings, margins, borders, etc. and without having to compile the app to add a theme. I'm not even sure which one is best in terms of maintenance and UX. It's a tricky issue that's been around for a while.

[whitewall]

@laurent

drop support for custom CSS

I can't see that as being popular. But I understand that it can cause issues.

[laurent]

Yes I'm aware of that. I think it's still worth discussing what, in theory, would be best. Then we can consider how it could be done (if it can be done) with minimum disruption.

[whitewall]

Yes, yes. And perhaps someone could develop a plugin that gave a gui interface for changing the most important css things. That would probably accommodate most people. I rely on my .css files for Joplin, but I'd rather be able to get what I want through an interface.

[tessus]

Personally I'd rather copy a file and be done. An interface can be useful, but I seriously doubt it can contain all the things I have put in my css.

[dnzm]

I agree with this - I understand a bit of GUI will be easier for "normal people", but it's impossible to create that UI to both be usable and have the breadth of options pure CSS has.

[laurent]

Sure, although that's not really the issue. The GUI is an implementation detail to make certain tasks easier. Underneath it will indeed be a file of some sort.

[Yann1ck]

From a user perspective I prefer it if an app as some well designed defaults and not to many settings. (Moreover every setting needs to be maintained as well). So the actual themes can be removed (personally I dont think they are are particular good looking) and just be replaced with one light and one dark theme (perhaps a third one in between is fine as well). These should be applied automatically based on the system preference.

For more advanced theming CSS is the best way, because it is highly customisable and it is obvious that CSS can break. Less tech-savvy users that want to customize Joplin can still look on the forum and c&p styles. It would be even easier if plugins could be used to apply styles, like it is possible with the macOS theme.

[uxamanda]

(FYI I just added a bunch of thoughts about themes here: Ideas about Joplin Theming)