Logseq ecosystem conflicts: wrong CSS variable

[yoyurec]

Mia theme uses its own variable (https://github.com/search?q=repo%3Aplayerofgames%2Flogseq-mia-theme%20--content-font-family&type=code)

:root {
    --content-font-family:  "xxxxxxxxx";
}
...
font-family: var(--content-font-family);

To have compatibility with other plugins and follow Logseq CSS vars convention (https://github.com/logseq/logseq/blob/master/resources/css/common.css#L8) it should be dafault variable but overwritten:

/* long selector, not just ":root", cose same in Logseq css and should be overwritten */
.light-theme,
.dark-theme,
html[data-theme='light'],
html[data-theme='dark'] {
    --ls-font-family:  "xxxxxxxx";
}
...
`font-family: var(--ls-font-family);`;

[playerofgames]

It doesn't seem so simple; mia uses a mix of the system font and other fonts so has to override the font-family in certain elements, not just at the top. One could argue that the extension that overrides the font-family is also not doing things in a compatible way, because if two extensions had wanted to change the font list, they'd be incompatible.

Simply changing the variable at a point in the hierarchy does not work because of the way element attribute inheritance works (it is not recomputed per element based on css variable scope, unless the attribute is re-declared using the variable, which would not meet this need).

I'll ponder if there is an approach that achieves the theme's goals.

There is a workaround if you are keen to use the tabler icons. It looks like you are using miA Quattro based on the screen shot in the other issue. In that case, adding

:root {
    --content-font-family:  "iA Writer Quattro S", "tabler-icons";
}

to your custom.css appears to work.

[yoyurec]

as i see described things were not 100% clear...

is was not a full solution, but a small part of an example.... what i point is: 1) override Logseq war --ls-font-family

.light-theme,
.dark-theme,
html[data-theme='light'],
html[data-theme='dark'] {
    --ls-font-family:  var(--content-font-family);
}

2) reuse --ls-font-family as "new your" in some root elements or more narrow targeted selectors instead of --content-font-family 3) override one more time and reuse in some complicated cases

/* some UI, non-content zone elements, for example: /
#left-sidebar {
  --ls-font-family:  var(--another-mia-UI-font-family);
}
...
...
#left-sidebar a {
  font-family: var(--ls-font-family); /* still "system" var, but new scoped value. own. ANY */
}

and depending on your CSS it needs fewer or more editions. this should be a good start and if we are lucky - even full solution ))

One could argue that the extension that overrides the font-family is also not doing things in a compatible way

why? not agree. Tabler picker just extends Logseq font-family 1-to-1 as Logseq does. with the possibility to other themes still use their fonts (if CSS is done properly, which is not in a lot of themes) - https://github.com/yoyurec/logseq-tabler-picker/blob/main/src/tablerPicker.css#L6-L8

if two extensions had wanted to change the font list, they'd be incompatible.

of course - if it's a strict requirement of some plugins to ignore other plugins/themes font - it will be overwritten and ignored )) but this is the area of developer responsibility...

[playerofgames]

I'm inclined to disagree with your attribution of "responsibility" to various developers; each of them, including me, is changing a moving platform in ways it was not explicitly designed to be changed. I am using two font families across the product, one for UI, and one for content. This is not supported by current Logseq css without very specific style overrides.

However, I do agree that since the introduction of the --ls-font-family variable, it is worth updating how miA changes the fonts. I've opted to go with using this for the content font, as content is most likely to be 'targeted' by plugins.