Hi,
Apologies if this is the wrong section.
I am working in a user css style sheet. I was wondering id there is a ‘guide’ or ‘list’ of the css property names?
e.g.
H1 = # in markdown
I have worked out a few of them, some are obvious, some other by looking at others css code examples they have posted here. Though, it would be easier if I could find a list.
Thanks.
Hi, you can see them all by opening the dev tools in the Help menu. There won’t be a list of CSS classes because they can change from one version to the next. We make no guarantee that they’ll be stable.
It might be practical to establish some convention for naming classes. To give developers maximum freedom, I would suggest that they avoid the prefix user- or (my preference) u-, so that users can define their own classes without the risk of conflicts.
Hi, thanks for that.
For me and my current programming skills, that is a bit overkill and difficult for me to find what I am looking for as it appears to give the css for way more than I am looking for.
Maybe, you could help me with one class I am trying to work on right now - code highlighting, that is to define the css when using markdown to display code e.g.
<some/code/here>
or
<some code>
[here]
{and here}
Code example from one of my notes, of what I want to create user css for:
I have some idea from reading another person’s sample css, but I can’t quite get what I want as I don’t understand the classes.
Thanks,
Paul
Providing explicit support for stable classes would make development much harder, even though user styles are probably only used by a tiny fraction of users, so that’s why it won’t be done.
That being said, the generated HTML tends to be relatively clean and indeed stable anyway, but I prefer to make it clear there’s no guarantee about it.
If you want to change the way code is displayed in the viewer start with this in your userstyle.css and play with the values or delete the entries you do not want. NOTE that you will have to name a monospace font that is on your system (assuming you want to change the font!) and you must QUIT and restart Joplin for the changes to have an effect.
code {
font-family: "Roboto Mono", monospace; /* sets code font - fenced code, inline code and pre - MUST be a monospace font*/
font-size: 12px; /* sets code font size - fenced code and pre */
color: #000000; /* sets code font colour - fenced code, inline code and pre */
}
.inline-code {
font-size: 12px; /* sets inline code font size - code element does not seem to control this */
border: 0px none; /* removes the border around inline code */
background: none; /* removes the background shading from inline code */
}
Many Thanks for that, I was soooo close with what I had, but 'close' doesn't cut it when programming 
For the 'code' section. what are the properties for the box around it? It is not
code {
border: 2px solid #545454;
border-radius: 3px;
background-color: #B3B3FF;
}
These apply effects to the 'lines of text' not the outer box (pale grey by default).
Thanks,
Paul
If you want to change the background of the fenced code blocks try:
.hljs {
border: 0px none; /* makes sure fenced code blocks do not have a border */
background: #F0F0F0; /* makes the background of fenced code blocks darker than the default */
}
I am used to systems where common namespaces are divided into a system part (e.g. everything that starts with Z or SYS or __) and a user part by convention. I can imagine that in the current pioneer phase naming standards didn’t have a high priority. But may I give an impetus to some kind of user initiative in this area?
Let’s reverse it, as a thought experiment. Not the makers, but I as a user more or less claim a part of the namespace by the recommendation not to use certain names, at the risk of annoying Joplin users. I’m having a three-character prefix in mind:
-[-_a-zA-Z][-_a-zA-Z0-9] ⇒ 3,456 combinations for vendors_[-_a-zA-Z0-9]{2} ⇒ 4,096 combinations for vendors, which makes a total of 7,552 for them[a-zA-Z][-_a-zA-Z0-9]{2} ⇒ 221,184 combinations for other parties (grand total 228,736)u-[-_a-zA-Z0-9] ⇒ 64 combinations for users, so only 221,120 left for developersAm I too greedy? Then:
u-- ⇒ 1 combination for users, 221,183 left for the developersI don’t think this should make development really much harder. But I’m not that close to the fire, so it might be a naive thought of me (third parties that cannot be controlled and the like).
I understand. It’s just that a few items don’t have a class at all, which makes it impossible to change them. E.g. the background color (weird orange) in the Encryption tab in Preferences looks awful on the dark theme. The link is not even readable. Yet I can’t change it…
Many Thanks for this dpoulton
Sorry I didn’t get back to you sooner, I was away a few days.
As we don't have an agreement on this topic, I felt free to change my mind.
Methinks all developers are serious people with good taste, who would never ever let an identifier end in a dash. Being a rather frivolous user myself who don't care too much of what people would think about my taste, I have chosen to do the opposite. That seems a pretty safe way to avoid name conflicts. And it keeps my identifiers short, with less visual noise than the prefix construction.
mainframe, eh?
I guess we could add classes to the code here and there if it helps with custom css. Perhaps we could build a list of what elements should have a class to get a sense of what’s needed.
Long term I’d like to switch to scss for styling, so nearly everything will have classes then or be selectable with css. At the moment it’s rather tedious to create UI in Joplin because you need to manually set the styling on each tag.
Switching to scss would allow proper styling, and we can use the dynamic properties of scss to support themes.
So, if I’m reading correctly, scss would function similarly to react typescript in this project; it gets compiled into css while being an extension that makes it overall easy to work with. If that’s the case, I’m all for that. So cool
Not exactly. The way I see it we’ll ship the app with an actual SCSS file and it will be compiled to CSS at run time (and cached to disk). Compiling at runtime means the generated CSS is dynamic, based on the current theme.
So in the repo there will be one master SCSS file that can easily be tweaked, and theme.js will contain the variables that change from one theme to the other. Custom CSS will still work the same - it will just be applied like now, after the SCSS and theme has been applied.
Fair point. I can’t wait to see what that brings. Because that would be dynamic, would that mean that changes could be implemented while Joplin is running and it wouldn’t need need to be restarted to apply them? Of course, since it’d be loaded and compiled at runtime, that might not be possible but it would definitely be nice.