Posts with a "read more" that change their size may be picked up multiple times by the long post clipper tweak. This causes multiple "click here to expand" labels to appear at the bottom of the post.

This causes some elements to not have custom styles applied (see the settings page or the "following" page)

Cohostinator uses a combination of MutationObserver and setInterval waiting to grab elements from the page and apply custom classes so they can be easily modified later. Despite my best efforts this somehow is still not consistent enough to catch all elements we want to tweak. This is usually fixed just by reloading the page and giving the script another chance to catch all of the elements. I think this is down to my inexperience with writing JS that modifies a page while the document is loading, something userscripts have to deal with all the time.

Cohost has dark mode, light mode, and an option to follow your system's theme. All three options apply different changes to the DOM. This makes it very difficult to write a theming engine that works regardless of what setting the user chose. There are three options:

1. Wrangle all elements and delete the attributes/classes that cause colors to be applied, replacing them with custom ones. This thrashes the DOM and would be laggy, but allows for the easiest theming experience for the user.
2. Allow the user to directly edit all CSS variables. This gives the best customizability and probably would be easiest to implement, but not all of Cohost's colors are stored in variables, and there are so many variables that it would be overwhelming for the user.
3. Detect what base Cohost theme the user has selected, then, depending on this, apply different stylesheets and modifications to the DOM. This would probably have about the same performance as the current solution, but would introduce lots of code duplication.

I'm thinking option 1 or option 3 are probably best, but I'm dreading implementing any of the above.

This occurs if the navbar is not moved to the top of the page; the post width being increased causes the navbar to shrink to the minimum size it can that still fits its content. This causes word wrapping that looks kind of ugly.

If the new notification indicator loads before the top navigation bar tweak picks it up, the tweak will delete the indicator instead of the text.

I did not have any bookmarked tags while I was developing the topnav tweak, so I did not know it expanded! A good solution would just be to force it to link to /rc/bookmarks instead of expanding, maybe? Or maybe turning the dropdown into a separate floating div like the Chostinator settings