I just pushed a new version, which now adds polish
to the languages and also rewritten to use OKLCH colors instead of the old #RGBA (thanks @mjf for the tip), also added new more uniform styled icons from Lucide.
If you are using my Library Update command, make sure you are always using the latest and freshest
We should standardize on a single color space across all of SilverBullet’s CSS. I suggest using OKLCH. The key benefits of OKLCH over HEX or RGB are that it offers perceptually uniform lightness (making colors easier to adjust and predict), a dedicated hue control, and the ability to define wide-gamut P3 colors (beyond the sRGB gamut). It’s also very easy to understand and intuitive to work with. So it’s a win from the user perspective too.
We should also standardize on a single approach for relative size units throughout SilverBullet’s CSS. I recommend standardizing on rem for global scaling and layout components, as it offers reliable, relative sizing based on the user’s root font size, while reserving ch for text containers to ensure predictable line lengths regardless of the font face. vh and vw should be introduced only when for specific design requirements, such as side panels. All of these are easy to understand and intuitive to work with too.
I’ve hinted at this here and there before, but I don’t consider CSS “architecture” a core strength of mine.
If there’s anybody around here that has more of an opinion how to architect and document this nicely, I’d happily accept a significant overhaul. Topics like theming, dark modes, predictable and sensible CSS classes do need a properly thought out solution I feel, otherwise we just keep hacking around indefinitely.
@mjf approached me about doing a general CSS classes overhaul together. I’m not an expert in CSS, but I do know a thing or two. I’m not sure I’m the right person for it, but I do enjoy experimenting with CSS. In SilverBullet, there’s often a lack of consistent classification and an overall structure for all the CSS classes.
In my opinion, the first step should be to do an as-is vs. to-be comparison, to see what currently works well and what needs improvement. After that, we can discuss colors and font sizes standards. But first, we need a uniform and consistent structure for classes and IDs.
At the moment, I constantly have to dig through the dev-tools to figure out which class controls what, and I keep having to find workarounds to achieve the desired styling. With a well-thought-out and structured class system, plus documentation that includes naming conventions and visual examples, we could make things much easier for users and contributors as well.
I’ll spend some time soon thinking about how we could reorganize the whole thing a bit. and we’ll keep in touch this regard.
PS: OKLCH is defininetely the right PATH on doing colors in 2025, i have been experimenting for the last two weeks with OKLCH, and its widely supported in most of the browsers, and it definetly simplifies things when it comes to color matching, or consistent lightnes and contrast of certain UI elements. It’s also the modern way to go on with CSS restyling.
The problem here is that it will break user created styles. This is the main reason there hasn’t been improvements here and also the main reason the codebase looks the way it looks. If this is touched, I think it should be done as one big change. Which probably means gutting big parts and rewriting the CSS, fixing some stuff about the HTML from the parse tree, fixing major issues (#1088, #895, Support for non-monospace fonts, etc.), etc …
It’s not easy, but half-assing it would probably not result in any improvement.
That’s essentially the plan. Our goal is to be as unobtrusive as possible while still doing things properly, keeping what works and reworking the rest, right down to the HTML DOM level if needed.
v2 broke a lot of user-created queries, scripts, and syntaxes. With this we’re aiming to modernise the entire CSS. That may temporarily break some themes and user styles, but we’ll provide documentation so users can rebuild their preferred styles and themes much more easily.
Here’s my “work in progress” document mapping the current CSS classes and structure, this will show where we need tweaks, fixes, or complete reworks. This serves as the current “as-is” CSS Structure Map.
The plan is to create a similar map for the future restyling, contributors and users will have a much easier time navigating and working with the CSS than they do today.
I also made a new Topic dedicated to this where we can continue the discussions and ideas about this topic:
And if we can’t deliver, we won’t PR it, and the user will still have at least a comprehensive & accurate structured CSS Map of the current version So it’s a win either way.