I know we already have footnotes, which serves a similar function to comments, but since Obsidian already supports the %%inline comment%% syntax, it would be nice if those comments could be accessed in Reading Mode as well.
My idea is a plug-in that will read these inline comments and produce a Comments View or Comment Pop-ups to allow users to read their comments in Reading mode. Kind of like how comments work in Google Docs or Celtx.
Syntax
The plug-in would use Obsidian’s pre-existing inline commenting syntax. Someone could write,
# Chapter 5 Summary
Johnny finds an evil talking onion in a shady Walmart Parking lot. %% This is the moment where he absorbs the onion power.%%
and the plug-in will register This is the moment where he absorbs the onion power as a comment.
How it Works
My idea is that the plug-in would provide two ways to view comments:
By hovering over a icon positioned inline, in the exact spot where the comment begins. In my example, this icon would be at the end of the sentence Johnny finds an evil talking onion.... This would expand the comment so that the user could read it.
By opening a Comments View in the side dock. This view would also open automatically when a icon is clicked. This would list all the comments in the active note. Click on a comment in this view, and the note scrolls to the sentence or line where the comment is positioned. Double click on a comment to edit it right there from the sidebar.
Rendering Comments
The plug-in renders the comments in markdown. That way, attachments and such could be included in comments.
I have used the Comments plug-in, and I agree, it is a close solution. My only problem with it is that it uses HTML inputs with the class and styles inline. In a note with several comments, edit mode can start looking messy quickly. Also, if you uninstall the plug-in or view the note with another app, the comments are rendered as checkboxes or just normal text. The plug-in is what is creating the comments, so the comments are dependent on the plug-in to work.
But, a plug-in that simply renders native comments would fix all of that. Comments already exist in Markdown, so putting comments in the note this way would not interfere with formatting or readability if the plug-in is uninstalled or the note is viewed in another software. Instead of making an entirely new way to make comments, which would make the comments dependent on the plug-in, this plug-in would utilize the comments that are already there. The comments will always exist and be comments in any Markdown reader. This plug-in would just add more convenient ways of viewing and manipulating comments in Obsidian.
Strictly speaking, they don’t. Obsidian’s comment syntax only works in Obsidian (and partly in Ulysses). No other Markdown reader will recognize them as comments (tho of course you will recognize them as comments and that may be all that matters). Markdown does allow HTML, so in that sense it includes <!--HTML's comment syntax-->.
(I realize you may just mean the comments exist in the text.)
Ohh. I suppose I just assumed that %% was regular Markdown syntax. And I forgot about HTML comments.
I think even if %% comments aren’t recognized in other Markdown readers, such syntax would still be easier to read during editing. But, if this theoretical plug-in also supported HTML comments, that’d probably be the best solution.
+1 Also interested in this: in Ulysess I’m quite used to put some little comments inline while, to my knowledge that’s not possible in Obsidian. I’ve also tried what I was doing in the “old .doc days”: square brackets but those are rendered as normal text when in reading mode so there’s no visual glitch to highlight them.
What about a CSS Snippet? I’m not able to write myself but I guess it should be possible…
I have tried, but I can’t figure out how to make them appear in reading mode. They seem to be the same as %% comments. I was wondering if I could use the same method I used to make image alts appear in reading mode, but comments don’t have any attributes.
And there also seems to be only .cm comments, which I believe means they can appear in edit mode only? Assuming cm stands for Code Mirror. I don’t really understand Code Mirror, but I assume it means edit-mode only.
Because they don’t exist in markdown, the ‘markdown’ editors that have comments use different syntax and different closure rules.
I think Ulysses uses %% for comment blocks but ++ for inline comments++.
Tangent uses // at any point in a line to mark the start of a comment and the comment is only closed at the end of the line.
Writemonkey also uses //
I have developed my own system using emojis - they’re easy to use and find and have little effect on readability, and work in all editors - but no program understands what is going on.
I dislike HTML comments because they’re ugly and more awkward in use.
How do you use emojis? Youre wrapping a comment with emojis? say comment ?
And you make then not appear in reading view or anything similar in some way? Im mostly a newbie in Obsidian (and im not caring about straight markdown compatibility with other apps) - if theres a way to set customs wrapps/tags, simple ones (i hate html tags inline too), change how they look or if theyre rendered and even better if theyre queriable/searchable… that would interest me A LOT.
(…hopefully not too complicated)
My system is designed to be robust across apps whether they be plain text or rich. I don’t know when I might switch away from a program and I frequently use many programs to edit the same file.
Generally I don’t use wraps.
Simple system - I insert an emoji into the relevant point in the text. At the bottom of the section I have a subheader. In that I put the same emoji with the comment. I can hide the comment by folding in programs that support it.
A more complex inline system includes the emoji, but the comment is then simply hidden by folding. This works only in Writemonkey, but it ought to be possible to do the same in Obsidian using CSS.
It’s simple, quite primitive, but effective and works in most editors and word processors.
I checked in the developer tools, and HTML comments are not included in Reading View. Sorry for the bad tip. Obsidian treats the 2 kinds of comments differently so I thought the HTML ones would be treated as they are by most things that show HTML — included in the source but hidden to the viewer.
I agree, unlocking Obsidians comments would be useful for Reading view!
My theme Dune supported in previous versions custom tooltips for Reading view, but with the help of html tags.
I found this solution less comfortable so i removed it. If there is interest in this feature, i will add it again
I think themes allow already some flexibility in this direction - I remember how Blue Topaz added some pretty magic features like that, but idk if Blue Topaz is still maintained or forked by sb else. Sounds like you would like a core change
Critic Markup already exists and has gotten some support (which means it’s already somewhat interoperable), so there’s no sense reinventing something else that does the same thing.
Oh, I was wondering what you meant by custom tooltips. Yeah, that’s cool!
And if anyone wants comments that can be viewed in reading mode and attached to a certain line, I have this snippet that turns asides into hoverable comments.
If you use this snippet, you may have to place the aside before the sentence you are ‘commenting on’ for it to show up on the right line (otherwise it may appear beside the next line).
Now I’m starting to think–why would anyone use asides when we have footnotes? Why don’t I just use footnotes? Especially with the Better Footnotes Plug-in…it’s the same thing. I don’t know why, but I want to use comments, not footnotes, so I make a snippet to trick myself into thinking I’m making comments when it’s essentially the same thing. Like…why don’t I just make some css for footnotes so that they all have a litle symbol? It’d be the exact same thing!
So, this is an alternative to footnoes, I guess? If anyone wants to use it.
/* make asides "invisible" */
aside {
position: absolute;
color: transparent;
padding: 0.5em;
float:right;
clear: right;
width: fit-content;
/*margin: 0px 1em 0px 0px; */
width: 0px;
height: 0px;
z-index: 800;
margin: 0px calc(var(--file-line-width)*-0.07);
}
/* make text inside asides "invisible" */
aside > * {
color: transparent !important;
background-color: transparent !important;
}
/* make text inside asides visible again on hover */
aside:hover > * {
color: revert !important;
background-color: revert !important;
}
/* create the comment icon signifying the position of the aside */
aside:before {
color: black;
content: '💬';
font-size: 0.95em;
height: auto;
width: auto;
border-radius: 100%;
padding: 2px;
position: absolute;
top: 0;
}
/* Change the appearance of the comment icon slightly on hover */
aside:hover:before {
color: black;
content: '💬';
position: relative;
font-size: 1.5em;
background-color: transparent;
height: auto;
width: auto;
border: none;
box-shadow: none;
padding: 2px;
}
/* show the text in a comment-like modal when an aside is hovered */
aside:hover {
color: var(--text-muted);
background-color: var(--background-primary);
padding: 0.6em;
border: 1px var(--background-modifier-border) solid;
border-radius: var(--radius-m);
float:right;
clear: right;
width: 400px;
height:auto;
margin: -4px calc(var(--file-line-width)*-0.07);
max-width: unset;
font-size: var(--font-ui-medium);
box-shadow: var(--shadow-s);
}
icon positioned inline, in the exact spot where the comment begins. In my example, this icon would be at the end of the sentence 
