Option to Use Classes Instead of Style
See original GitHub issueHey there! First, I wanted to say that this is a neat plugin idea. Thanks for writing it, and for sharing it with the community!
Currently, if I highlight some text, example text
, and pick, say, blue
, I get the following:
<mark style="background: #ADCCFFA6;">example text</mark>
If I were to change the value of “Blue” (which, an “edit” option doesn’t seem to currently be available in the plugin’s settings near as I can tell, but I can delete and recreate that name, for instance), if the file is open, I think it removes any instances of the highlight, and if it’s not, then the highlight’s mark remains configured to the old color. This makes it so notes can become “outdated” relative to a given configuration, which I think is not really compatible with the idea of a knowledge database.
Is there anything I’m missing, like some practical reason why classes cannot or should not be used for this?
My proposed solution would instead have it so your interface curates its own list of classes, while the plugin adds classes to notes, which can be updated / changed over time to reflect the user’s current use of / view on highlights, e.g.
So the markdown could look something like:
<mark class="highlightr-blue">example text</mark>
and elsewhere, something like:
highlightr-user.css
.highlightr-blue {
background: #ADCCFFA6;
}
Thanks again for sharing your plugin!
EDIT: An option to cost classes versus inline styling would likely be appropriate to cover all use cases.
Issue Analytics
- State:
- Created 2 years ago
- Comments:24 (1 by maintainers)
Top GitHub Comments
Personally, I prefer the way it works at the moment. I use my Obsidian files outside Obsidian all the time. Wouldn’t work if it depended on class.
I’m suggesting that the current solution is more in line with the ideals of Obsidian than the proposal here.