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.
Environment
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.
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.
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!
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.
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.
