How can CSS snippets be aware of Minimal-theme? (for compatibility)

Custom CSS & Theme Design
1

I was originally writing a CSS snippet depending on the ``line-width’’ of note contents when the Editor > Readable Line Width setting is on.

But the default theme does this by setting the container .markdown-preview-sizer { max-width: var(--file-line-width); } which is 700px (leaving auto margins like ~400px), whereas the Minimal theme fills the container .markdown-preview-sizer by max-width: 100% and fixes width: var(--line-width) which is 40rem (leaving auto margins like ~20rem) per line inside the container.

I’m only able to design my custom dimensions based on var(--file-line-width) or on var(--line-width) individually, but I can’t figure out how and when the Minimal theme is enabled and that my snippet codes should automatically switch to the other var ?

CSS selectors and queries can’t directly access those properties, and thus seem to be unaware of those changes in width and margin of .markdown-preview-sizer …

2

In general I don’t think you can do any if-then-else statements within CSS, and is often handled by doing media queries to some extent.

But if you specifically want to do stuff differently depending on the Minimal theme, can’t you then simply use rules like the following:


body.minimal-theme {
  background-color: blue;
}

body:not(.minimal-theme) {
 background-color: green;
}

At least in theory that should work, or the concept should work, as the Minimal theme should introduce specific classes only known to itself. Tests kind of indicate that my files always(?) have the minimal-theme added though, which I can’t really understand why.

In other words, I think the way forward would be to detect some change to the DOM when the Minimal theme is active, and then use that in a selector for your snippet to behave accordingly.

3

That was also my approach, but <body> always has the .minimal-theme class after the theme is installed. The mechanism seems to be that when you switch to the Minimal theme, one of the <style type="text/css"> elements in the <head> gets filled with the theme CSS, thus providing rules for those theme classes.

The only hack I can think of is to use .markdown-preview-sizer and .markdown-source-view .cm-sizer as containers, and to do container queries (width = 700px) for default theme case and (width < 700px) or (width > 700px) for Minimal theme case (but there’ll be false positive though). Luckily the elements that I want to apply CSS rules to are indeed inside these containers. (The hardcoded 700px is --file-line-width used by obsidian by default, but queries cannot include var() functions…)

But I still want some other more elegant solutions (if exist), something shipped with the Minimal theme that might indicate the switch of themes more distinctively… Plus, I already have two layers of nested container queries for various cases, adding this would be the third layer…

4

I also forgot to mention that, if I create a container context for .cm-sizer or .cm-contentContainer (to detect Minimal-theme activation), it’ll have side-effects:

By default, the Minimal-theme puts .cm-gutters outside of .cm-contentContainer. But if .cm-contentContainer or .cm-sizer gets a container context, then .cm-gutters will be forced to move inside of .cm-contentContainer (for some reason I don’t know), causing line numbers to overlap with the content text.

I can’t come up with a solution other than reversing Minimal-theme’s modification on .cm-gutters (but I’m afraid that it might introduce other side-effects…)

5

Oh… … and there’re two scenarios where my (width < 700px) or (width > 700px) trick fails:
One is when Editor > Readable Line Width option is off, causing .markdown-preview-sizer or .cm-sizer to be (kinda) full-width instead of 700px; the other is when the editor space is smaller than 700px so that .markdown-preview-sizer or .cm-sizer also begins shrinking.
Both cases in default theme would make my container-width-query detector give a “Minimal theme” false positive…

6

Finally I use a container style(--file-margins: 32px) query (equivalently var(--size-4-8)) to indicate the default theme. At least, creating a container context on <body> doesn’t have those side-effects (unexpected change of the containing block reference for element positioning).

It’s just that, I can’t be sure that people won’t customize --file-margins to other values while still using the default theme, or that other themes won’t modify .cm-sizer width while leaving --file-margins untouched. The point is that, --file-margins is not as closely related to my concern as the .cm-sizer width…