Is there a way to use custom stylesheets with Joplin, so you can pick fonts and other properties for different elements such as tables and headers?
At the moment it’s not supported.
Looks like you built this by now from the website notes about userstyle.css
I simply wanted to make my headings bigger, so I create a file named userstyle.css, in this location (which I was able to verify on the General Options screen of Joplin:
C:\Users\Brian.config\joplin-desktop
and these are my styles, but they aren’t working - any idea why? I closed the app from the taskbar icons area and restarted it.
My styles:
h1{
font-size:40px !important;
}
h2{
font-size:32px !important;
}
h3{
font-size:26px !important;
}
Hi! Unfortunately it looks like updates to the website happen faster than updates to the application. This is a new feature which will be available on the next release! (Disclaimer: I don’t know when the next release is)
I am also trying to edit the desktop display with CSS because the Font Zoom doesn’t work.
I tried to increase the font size for the editor and the viewer but only the viewer respects any changes.
The viewer would ignore specific viewer element calls but it would obey the changes from “body” changes.
The editor ignores all changes even when specifically trying to adjust ace-editor, ace-content or #note-editor
The userstyle.css is only applied to the viewer. Basically whatever you put into userstyle.css is added to the html code of the viewer and no where else. Unfortunately your only option to increase the zoom of the editor is the global zoom percentage. Did you try restarting Joplin after changing the value? It’s probably a bug if it doesn’t work.
Unfortunately, the Global Zoom doesn’t do anything. There are a couple reports on it in the GitHub issues.
The main issue is I think the default of 12px is too small for a notes app. I think the viewer should be 16px and the editor be either 16px or at least 14px to be more comfortable for most people.
By the way, I use the AppImage in Linux (KDE Neon -> Ubuntu).
I tested zoom on my computer (AppImage, Gnome - Ubuntu 18.04)
Here is a section at 200%
And a comparable section at 100%
Of course, as you can see at 200% the icons don’t fit very well (and the title doesn’t change size). But it’s definitely working. Just to confirm, you are restarting joplin after changing the zoom percentage? It must be closed and re-opened for the zoom changes to take effect.
The global resize started to work for me after the last update but didn’t come back to the thread until now.
The issue with the text and icons not fitting is because the line-height isn’t responsive so while the text increases the line-height doesn’t change making it very cramped.
Custom stylesheet on Android is not supported and if I understand it correctly by a previous comment in another thread, it is not possible currently.
I’ve created a small draft PR playing around with this concept: https://github.com/laurent22/joplin/pull/2099
@laurent I’d be curious to get your perspective before I go further with it. Apologies, I forgot to mention in this thread before I started, so this whole addition may not be welcome. No worries if not, I should’ve remembered to check in with you first.
As far as I see now, the adaptable userstyle.css
has been implemented for Windows and macOS. I don’t know about Linux and Android, but the iOS version does not support it (or it must be well hidden). Are there any serious plans for doing so? It’s one of the things I miss most as a fresh Joplin user, because the current style settings are too space consuming on the tiny screen of my iPhone.
I’d love to be able to set custom styles across notes in iOS, too!
As far as my implementation of custom stylesheets goes, there’s unfortunately no way to set a default stylesheet for iOS because there’s no way to access an equivalent of the ~/.config/joplin-desktop/
directory.
In the short term, I’ve been adding this to the bottom of my notes to get the styles I want. Not the most elegant solution, but it makes the rendering look much nicer at least:
<style>
body {
font-family: 'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji";
margin-bottom: 2em !important;
}
code, pre {
font-family: "iA Writer Mono V", "Fira Code";
// font-weight: 600;
// font-size: .95em;
line-height: 1.5em;
background: rgba(0, 76, 114, .08) !important;
border-radius: 4px;
}
.code, .inline-code {
border: none;
background: rgba(0, 76, 114, .08);
border-radius: 4px;
}
img[title="250px"] { width: 250px; }
img[title="350px"] { width: 350px; }
mark {
background: #3edbff53 !important;
padding: 1px 3px;
}
.md-checkbox .checkbox-label-checked { cursor: pointer; }
/*********************************
**** Links to internal notes ****
*********************************/
a .resource-icon { display: none; }
a[href="#"] { color: green; }
</style>
Longer-term, we could consider supporting a Meta Joplin
notebook or something, where you can create a note called userstyle.css
(just like the one in ~/.config/joplin-desktop/
) that applies the styles there. Or, we could consider adding it under the Configuration
panel as a big string, similar to how we store the themes. I think either of these would be a more intuitive solution for the desktop app too, rather than having to dig into the fairly hard-to-find ~/.config/joplin-desktop/
directory.
We had a good discussion going, but it died down....
An alternative for inline style definitions could be this:
<link rel="stylesheet" href="c:/Users/memophenon/.config/joplin-desktop/altuserstyle.css">
<link rel="stylesheet" href="/Users/memophenon/.config/joplin-desktop/altuserstyle.css">
The first one for my pc, the second for my Mac. I would prefer a relative stylesheet address, but I couldn’t find a way to get that working. Nor do I have any clue what kind of address I should use on iOS.
It was a good decision to make the userstyle.css device-dependent, in my opinion. Different devices demand for different stylings. But a cascade allows you to play with style scopes:
- on your device — built-in AppStyleSheet (dynamic)
- on your device — UserStyleSheet
- in notes — CSS files linked by
<link>
tag - in notes — CSS block embedded as
<style>
element, optionally containing@import
functions - in notes —
style
attributes added to HTML tag
Thanks for sharing your stylesheet BTW. I hadn’t realized I could suppress the J icon at internal links this way. It’s too big, too low positioned, and ruins the regular line spacing.
I would like to get this discussion going again, so in that spirit here is my proposal.
I would propose 3 different modes for setting css.
- No CSS
- Select from filesystem (this will use the system default file picker). The selected file can be displayed underneath the setting along with a reload button. The file will be reloaded on application start (same as now)
- Load from note. This will add an option to the note context menu “Set Userstyle” and “Set Userchrome” (can also have an input in settings similar to the goto anything feature). This will allow users to take advantage of syncing notes across platforms.
Having these options means users can manage css as they want without having to create any specific folders or directories.
To make option 3 a bit smoother we should add in the ability for users to hide notebooks, this will allow users to create a config notebook which holds all the styling notes without those notes always being visible.
I think option 3 is the easiest one. Technically it would take very little to get this working, but it’s in terms of UX that it’s not great.
It’s a bit messy, even with hidden notebooks, because it’s mixed with the other notes. There’s also the problem of requiring the user to create notes with magic names so that they are picked up by the app. And what if there’s a syntax error in the config file? We also don’t have a good way to report that. They’ll also show up in search results, which might be unexpected.
Maybe it would make sense to create a separate class of sync items for this. They’ll be used only for config, and we could list them in a separate config screen and manage them differently than the notes.
You could use a reserved tag name, like .system
or something, to identify and group config notes.
This wouldn't be a problem because the user will select the note they want to use, which means no specific naming pattern.
I don't think there is currently any method for reporting syntax errors with css. This is probably something that should be considered in any case.
We could possibly use manual excludes but I can see how this might not be desirable.
This could be the best option but it'll also be the most work.
I actually think a convention of something like a notebook named Joplin config
with notes inside called Markdown rendering styles
and Joplin app styles
would be quite elegant (or userstyle.css
and userchrome.css
to be consistent). I might just be biased from GitHub’s approach, but I like it when content and config are stored in the same way.
I could see this implemented along a spectrum of name customization:
- On one extreme, we could just say “The folder must be named X, and the files must be named Y and Z”. This would likely minimize confusion down the line, because then everyone has files with the same name. This would make it harder for people to make mistakes, and support questions will be easier to phrase properly rather than having a dance where we try to figure out what folks are talking about.
- On the other extreme, the folder and file names could be totally customizable. We let folks determine their names in Settings, similar to how they can set their text editor. This would entail 3 new fields:
Configuration notebook
,Markdown rendering styles
, andJoplin app styles
(or some other names).
I don’t recommend creating a complex abstraction on top of these files, like hiding them or anything like that. I think that makes it much more likely that folks get confused, forgetting that it’s even there. If it gets annoying to see this config notebook in the sidebar, here are two suggested solutions that I think would create less confusion:
- Right now, when I have an old notebook I don’t use much anymore, I just nest it under a meta notebook called
Archive
, which lets me minimize all of the sub-notebooks. This takes up less visual space than having lots of old notebooks lying around, without making it easy to forget they even exist. (The problem is this might break the config notebook because I guess now the notebook name would be nested? I think it’d be fine, but worth checking) - Perhaps we could create some more formal concept of archival, rather than having to nest it into a meta notebook.