Since 1.0.157, checkboxes that are checked are rendered greyish instead of black. How can I disable/revert this?
Note that certain workflows work opposite (checked items are relevant).
Add this to your userstyle.css (only works on desktop)
.checkbox-label-checked {
opacity: 1;
}
For mobile support you’ll need to put that code within style tags on the note that you want.
<style>
.checkbox-label-checked {
opacity: 1;
}
</style>
It’s work keeping in mind that all the rendered styling can be changed with css.
So I need to clobber all my notes --manually!-- with visible, ugly and disgusting <style> tags? This is not acceptible.
@laurent Please revert this change or make it selectable.
This reminds me that we should probably pick up the discussion about using userstyle.css on mobile again.
I remember there were a few suggestions a while back, but nothing happened in the end.
3 Likes
In itself it’s not too complicated to inject custom css, but we indeed just need to decide where that css will come from on mobile.
Few solutions I can think of:
- Get the CSS from a note, maybe called userstyle.css
- Get the CSS from a special file on the sync target
- Get it from the settings (but then it can’t be synced, and is also lost when uninstalling and reinstalling the app)
1 Like
I opt for this option. The reason is simple. It's the easiest and best solution. Why?
The first item is rather error prone. So what happens, if you had 2 notes with the name userstyle.css? Also, would the note have to be in a certain folder? Second item might be too complex and looks prone to issues (more to that later).
The 3rd option is straightforward and if people are smart they have the css in a note (which is synced) anyway, so adding it back after re-installation or installation is a matter of copy and paste.
Of course you could combine option 3 and 2, so that the data you enter in settings is synced as a special file. However, a whole lot of edge cases come to mind. Is this valid across devices? What, if you wanted different css for mobile and desktop? Do you create a unique file per installation? In that case it would have to be a unique file per device actually, otherwise the data is gone after a re-install. Just saying, a lot of cases to think about....
1 Like
I actually think this is the best option. Joplin already handles duplicate names pretty gracefully so we don't need to worry about that case. I think it makes sense to put it into a config notebook, that way we can support mobile only css and desktop only css.
Additionally I've been thinking about how we can support new note templates in Joplin and this would be a nice way to handle that as well.
2 Likes
In the mean time, can you revert the grey checkboxes change?
As I understand this can later be added easily (should the user want it) with some custom css.
Wait, I love this idea with the grey checkboxes, is it something everyone dislikes? I think it makes it a lot clearer which tasks I have finished in a long list.
Can you see how hypocritical this is?
You’re missing the point.
I have no problem adding a central custom css that will suit my needs. That’s the whole idea of custom css.
But I do have a problem having to manually add a piece of css to all my notes. It is a lot of work, and css in a note is visible and clobbers the view.
As discussed earlier there are workflows that use checkboxes just the other way around (checked items are important, unchecked items are not).
@sciurius, graying out the checkbox is consistent with the rest of the UI. In the note list, the completed tasks are also ticked and grayed out (and crossed out). The majority of people consider that “ticked” is done so that’s why it’s like this by default now.
2 Likes
Yea, if you have notes with the same name, but if you want to just reference the name, it will be a problem. Also, this also means that you only have one userstyle.css note for all clients, otherwise you would have to reference the id and not the name. IMO this is too fragile.
I'm strongly against creating folders for users. Remember the welcome notes and notebook mess, which btw still screws up people's installations? At least the tags are gone for the welcome notes now.
From all the discussions I believe you are the only one who uses this inverted checkbox logic. But I understand your frustation, so let's hope there will be custom css for mobile soon.
2 Likes
In the end that would be the perfect solution for this and several other issues.
I like this solution at a technical level because it allows customising things easily, it's cross-platform, and we get free sync for it by re-using the existing architecture (and without having to make that architecture more complicated).
Then we can indeed add more config in there, including the templates you mentioned.
On the other hand, it's not very user-friendly. People will have to read the doc, manually create that config notebook with the right name (I agree with tessus that we shouldn't do it automatically), and the notes inside with the right name too.
I'm not concerned about duplicate names though - let's say for now the result of having two notes named userstyle.css will be undefined - the algorithm will pick the first one. Later maybe that algorithm could emit a warning, but it's not a big issue for now.
1 Like
Don't forget that with this solution you have one file that will determine the css for all your devices and all installations. This might not be wanted. I might want to have one css for my ipad, another one for my Android, and another one for desktop.
This was also the argument for the welcome notes...
I'm just saying, if you add it to settings, it will be bound to the instance of joplin, which is something I would prefer over syncing. And as I said, people can still put the css in a note for copy and paste purposes or for reference. Maybe other see it differently. I will tell you that using a notebook and note will be a mess. You will get all sorts of problems. IMO this is opening the proverbial can of worms.
This also means that people can't already have a folder that is called whatever you will pick for that name.
Another thing - I don't want a notebook called whatever that is visible to me. The notebooks are for my notes, not to configure the application. So, if I wanted to use a different css, I'd have to have a new folder which I don't want and which is in my way all the time?
Using notebooks and notes for configuration sounds nice and it could be an awesome feature, but it would require a lot more than what was discussed here. e.g. hiding notebooks and notes, a unique id per device that is appended to the config note name, merging of notes, .... this is highly complex when you want to do it right.
2 Likes
My thought had been that we would take a different approach to creating the config notebook because it is so special, and as you noted, you would need to be able to hide it. What would have been possible is to manually specify the ID and only refer to it by such (the users would then be free to rename it however they want). For example the config notebook could use the ID 00000000000000000000000000000000 because the probability that any specific ID is in use is extremely low. If this did cause problems (only possible during rollout) we would have to help the 1 or 2 users and then it’s done.
That said, typing this out makes sort of proves your point that it would be adding a lot of needless complexity and we’re sure to get complaints about the additional notes…
How about a compromise? We allow the user to select a userstyle.css in settings by having them point to a note with css in it. This way they can have separate css for each device and get the benefit of syncing infrastructure. We would also probably want to allow users to copy and paste css into settings for the users that don’t want configuration notes.
1 Like
Yes, this would certainly makes sense. However, I would rather use the link from Copy Markdown link to specify the file than entering the filename manually.