CSS Live Preview Tags wrong styling

Before opening a new bug report, please search the forum for duplicates and follow the Troubleshooting Guide.

  • We only consider bugs that are reproducible in the sandbox vault or a vault with no third-party plugins/no css snippets/default theme.
  • For Linux, we only accept bug reports that are reproducible with our Appimage package under Gnome or KDE.
  • Developer issues with the API should go here

Once you’ve done the above, delete everything above this line.

Steps to reproduce

Open a new file.
Add a Tag(#T1)
Create a Table
Add a Tag(#T2) in the Table

setup custom css Snipet with:

	--tag-size:	none;
	--tag-color:	none;
	--tag-radius:	none;

go to live preview

Did you follow the troubleshooting guide? [Y]

So, how can I file a bug report about your support for custom css if you are telling me that I should not use a snippet in my snippet bug?
I opened a new vanilla vault and tested it.

Expected result

I expect my tag to be in my custom css style and not the default style.

Actual result

Tags inside a table have the applied style.
Tags outside the table have the default style.


Additional information

In my actual vault, I used a normal theme and just changed some basic colors.
These colors stay. So my guess is that the custom css is somehow not seen or overwritten by another css class.

Pictures are from the vanilla vault.


Thanks in advance
Greetings FromOtterSpace

.tag isn’t going to do anything in Live Preview or Reading views. I think this is a CSS misunderstanding.



Moved to help for now.

Hi, thanks for the quick reply.

I don’t see the misunderstanding here.
The documentation is giving me the field I can change in the class I want to change.

Also, my pictures are proof that the snippet is doing exactly what I expect it to do.
The first shows the life preview with mixed results, the second shows what I expect to be the new default but just in reading view.

Can you elaborate on why it should not do anything?

Also, I forgot to mention, that I searched for similar Issues before filing the report and found this:

Here I just didn’t really get the solution.
For me, it feels like there is some documentation missing.

Sorry, shouldn’t this be a.tag ?

1 Like

Thanks for your reply,
can you elaborate on what exactly you mean by a.tag?

Like so


I tried that, but that does not change the behavior.

If I am missing a class declaration I am even more confused as to why the styling works perfectly in reading mode and in a table(even in the live preview) but not in the normal space.

What should the a invoke that in your opinion changes the styling?

In fact, live preview and reading view are completely different things.
Live preview just imitates reading view, and actually, they are working with very different mechanisms.

As a result, in many cases (with a few exceptions), you must change your CSS snippets’ target.

To see this, inspect your tag with the developer tool.

As you can see, a tag is expressed as an anchor element with the tag class (a.tag) in the reading view.

In the live preview, however, it is in fact span.cm-hashtag (plus many other classes). (Here, cm stands for CodeMirror, the editor library that the live preview uses to mimic the reading view as well as providing the fundamental editor functionalities.)

So the following snippet will correctly set the background color of tags to be red.

/* For reading view; if it doesn't work, add .markdown-preview-view + SPACE at the head */
a.tag {
  background-color: red;

/* For live preview */
.cm-hashtag {
  background-color: red;

Your CSS didn’t work because tags in live preview are not a.tag in the first place.

So, do we really have to be familiar with those complex selectors? The answer is no!

Obsidian’s built-in CSS variables allow us to forget about these details and just write something like this:

/* Works for both reading view & live preview */
.theme-dark {
  --tag-background: red;

Thanks for the very comprehensive answer!

I was thinking that it would be kinda object oriented so I straight up went to .tag which worked but not the way I expected.
From the documentation I did not understand that I could just change the fields of the “objects” in my current theme.

I am still wondering why in a table the styling actually worked with .tag{...}, which seems like a weird/buggy behavior to me, but I’m just a noob when it comes to CSS so that might as well be correct.

For next time, if something seems off or you are unsure, post in the Help category. Thanks!

Again, live preview mimics the reading view.
As for a table, it replaces the original source code with a rendered table. (I think it’s CodeMirror’s replace decoration)
“Rendered” means everything inside the table looks as if it’s in reading view, including tags. That’s why tags in the table are a.tag, unlike those outside the table.

(Callouts also behaves similary to tables.)

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.