Skip to content

fix: Make styles compatible with Joplin 3.1.22 #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

personalizedrefrigerator
Copy link

@personalizedrefrigerator personalizedrefrigerator commented Nov 7, 2024

Summary

This pull request adjusts userchrome.css for compatibility with Joplin 3.1.22. This does not adjust userstyle.css.

Note

Many of the changes are related to the upgrade from CodeMirror v5 to v6. CodeMirror 6-specific styles have been marked with /* CM6 */ comments.

Important

This pull request is currently a draft — it needs more manual testing and potentially refactoring.

Screenshot (userchrome.css only)

image

@personalizedrefrigerator personalizedrefrigerator marked this pull request as draft November 7, 2024 04:50
@tessus tessus added bug Something isn't working enhancement New feature or request labels Nov 7, 2024
@tessus
Copy link
Owner

tessus commented Nov 7, 2024

Oh, wow. Thanks.

Yep, I've also noticed that the CSS requires tweaking for CM6, so thanks for adding the classes. The last few weeks have been crazy. Still dealing with the aftermath of a break-in.

So this certainly helps a lot.

@tessus
Copy link
Owner

tessus commented Nov 7, 2024

I tested it with Joplin 3.2.0 5a44f62fb, but it looks different on my system. I am using the new editor (unchecked the legacy editor):

image

Another oroblem is that the rendered HTML seems to have a bug. When I start Jolin and the note it displayed for the first time it looks ok, but when I go to another note and then back, the numbering of the headings is off:

image

I will have to look into this in more detail when I have more time.

@personalizedrefrigerator
Copy link
Author

personalizedrefrigerator commented Nov 7, 2024

I tested it with Joplin 3.2.0 5a44f62fb, but it looks different on my system. I am using the new editor (unchecked the legacy editor):

Thank you for testing it!

So far, I've only tried this pull request with Joplin 3.1.22 (and only the userchrome.css part). I plan to test with 3.2.0 in the near future.

@personalizedrefrigerator personalizedrefrigerator changed the title fix: Make userchrome.css compatible with Joplin 3.1.22 fix: Make styles compatible with Joplin 3.1.22 Nov 7, 2024
@personalizedrefrigerator
Copy link
Author

I tested it with Joplin 3.2.0 5a44f62fb, but it looks different on my system. I am using the new editor (unchecked the legacy editor):

Thank you for including a screenshot! The different editor styles seem to match cases where the CSS file references classes generated by CodeMirror's classHighlighter extension (the elements with tok-nameHere-style classes).

If the tok-nameHere classes are not present: In the past, there have been issues with CodeMirror's built-in CSS due to dependency conflicts (e.g. when yarn includes multiple copies of certain parts of the editor). If this is the case, the following procedure may help:

  1. Clear any local changes to yarn.lock.
  2. Re-run yarn install from the root Joplin directory.
  3. Re-run yarn tsc from the root Joplin directory.

If the tok-nameHere classes are present: In this case, it's possible that how CodeMirror 6 nests <span>s with different class names is not stable across devices. If so, this commit might fix some of the styling issues.

Additional notes:

  • I'm now testing with Joplin 3.2.0 5a44f62fb.
  • I have all plugins disabled.
  • I'm testing on a secondary profile.
  • I'm running Joplin on Fedora 41 Linux.
  • In settings, I've set Joplin's theme to "dark".
  • I'm currently testing by overwriting Joplin's userchrome.css and userstyle.css with the custom files (not by using the tcu script).

When I start Jolin and the note it displayed for the first time it looks ok, but when I go to another note and then back, the numbering of the headings is off:

That should be fixed by 0b189ce!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants