Marginalia via html comments

The idea is simple but I like it.

  • The ability to turn html comments at the top of a text block into marginalia, without the “<!–…” noise.
  • It would be able to react to the size of the pane, jumping back atop the paragraph if needed,
    • and it would alternate sides if vertical space was needed.

This is the very not-what-I-want CSS I managed to come up with as a non-coder myself (hi, I don’t code). I believe we need some JS wizardy to make it cool and useful:

/* Because I don't know how to target HTML comments only via
CSS, I'm forced to include all exceptions to the .cm-comment class */
  > .cm-comment:not(.cm-hmd-frontmatter):not(
    + *):not( {
  position: absolute;
  width: 190px;
  color: inherit;
  font-size: 0.8em;
  opacity: 0.9;

.cm-line:nth-child(odd) > .cm-comment {
  left: -210px;

.cm-line:nth-child(even) > .cm-comment {
  right: -210px;

I always leave a margin on paper notes for review and for getting good SRS prompts for my index cards, be it paper or Anki.

That’s it. Thank your for stopping by! :slight_smile:

These would be comments on a copy of a text that someone else wrote?

Sorry if “marginalia” is not the right word, I’m not an english speaker.

Mostly not, it would be comments on your own notes,

  • to give a paragraph a handle so you can glance at the margins and know what the note is about without going deep into it,
  • or to design possible questions for an Anki prompt, extract keypoints, etc.

I also like to write a summary for the entire note or even just for an h1 heading; and having the paragraphs already annotated with keywords and questions helps.

Does it make sense? The fact it is at the margins is only to skim the annotations more easily, nothing else (I think, so far, I dunno).

Also the fact they are HTML comments it’s just an implementaton detail. I thought HTML comments would be a good option, since I don’t want to see these notes when I export a document say, using pandoc.

“Marginalia” is appropriate. I was trying to understand your intended use better, in part because I thought HTML comments might not be the most appropriate way. I think it’s probably fine, but you might consider using the HTML <aside> element instead — it’s probably about as “right”, and might be easier to style.

I think you (or someone) should be able to do what you want with only CSS, except maybe the alternating sides.

EDIT: We posted at the same time, so I hadn’t seen your last post about HTML comments when I wrote this.

1 Like

Wouldn’t using an element like aside imply coding a filter for exporting with pandoc? Comments are automatically filtered, that’s why I chose them, I think, in retrospect. Not that I’m not open to understand your point of course.

Yeah, I realized. Funny I was answering the same thing you were replying to, sort of. ^^

Thank you!

Haha, yes, we were thinking on the same topic!

Yes, using an element like <aside> would probably require at least a little extra attention with pandoc. It might be easy, or not, I don’t know — pandoc has a lot of features. :sweat_smile: You might just need to style them as hidden (like display: none;, I think?) in the version you send to pandoc.

Another advantage of <aside> that occurs to me is that you can add classes, id, etc. if needed for styling or whatever. You can’t do that with comments (but if you don’t need to then it doesn’t matter).

(I’m not arguing that using comments is wrong; either is probably fine.)

1 Like

I get that, makes sense. But I use pandoc for LaTeX, I don’t know how to feed CSS to that. Maybe with some JS one could potentially take the rendered span elements and give them classes for better CSS targeting, and even use the semantically appropriate aside tag.

Well. I guess the CSS I wrote sort of works for now. It’s a bit jumpy, I won’t lie :P.
I added some changes like a smaller font and smaller line-height. That is better than just being at the top for me, so for now I’ll take what little I could achieve.

Next thing could be just using your tag, but I have to figure out pandoc with latex first.

The gods of procrastination should be pleased enough by now.

Thank you!

I was thinking pandoc might exclude hidden elements when exporting to some formats, or have an option to do so. I don’t know what it does when exporting LaTeX.

Anyway, good luck! :slight_smile:

1 Like

Not sure if it’s the same idea you’re talking about, but I’ve long wanted the ability to add marginalia to markdown text. If there were a way to do it with footnote syntax such that it displayed the associated comment in the margin like that, that would be awesome! (And that would probably allow one to either include or exclude them during export, since I could see use cases for both options.)

1 Like

So you want footnotes to be on the margins while you edit the document, right?

I want html coments on the margins, because these comments are not meant, in principle, to make it into the final document when I export a PDF or .docx.

Optionally, though, I might look into writing a pandoc filter to have the option to include the HTML comments in the final print, for reviewing purposes (my marginalia is usually questions reflecting the paragraph’s content used for reviewing/studying).

So I think we agree on having notes on the margins, we just disagree in which type of notes those would be: footnotes, html comments.

Maybe an implementation could allow you to choose the type of entity you want to see on the margins? (obsidian comment, html comment, footnote, etc.)

I guess I gravitate towards footnotes because in my mind they would be easier to “cite” elsewhere. Each footnote has a unique “tag” that I could point to—e.g., “As I realized while reading XYZ (see [^thought] in…” It would make it easier to link thoughts and ideas back to their sources.

It might also work with HTML-style comments, though, if I reference a paragraph number instead: e.g., “As I realized while reading XYZ (see note on paragraph 14)…”

One distinct advantage of the footnote approach is its unintrusiveness in the text file. The only thing cluttering up the body of the text is the [^thought] reference, while the text of the footnote goes elsewhere in the document. (In contrast, I assume HTML comments have to be placed in the paragraph they’re associated with.)

It’s my fault, I’m being very unclear and peculiar. I suppose I make a very specific use of the HTML comments.

I would be doing the same you do with footnotes, and referencing them like so. BUT the html comments fulfill the sole purpose of surmising a paragraph with a question, for skimming to see which paragraphs I care to read in the future, and for reviewing on the spot (active recall). Not for extra annotations, and so, I would never reference an HTML comment elsewhere which, like you say, would make things complicated, you would be totally correct.

Well. I did it. I learned how to write a pandoc filter in lua, how to target the HTML comments, turn them into margins with \marginpar and that’s it.

It looks non-pretty in obsidian and it is not dynamic at all, so I must be carefull on the size of the marginalia text.

But I refuse to spend precious time I don’t have teaching myself proper javascript and plugin development in the near future. So… Let’s hope future me or future random-internet-surfer sees this and takes it to the finish line.

Trigger warning, I wrote it sleep deprived. If there ever was code not DRY, here it is:

-- takes HTML comments, turns them into marginalia

local count = 0

return {
        RawBlock = function (elem)

            -- Get element field to string
            local elementFormat = tostring(elem.format)

            -- target HTML comments
            if (elementFormat == "html" and string.find(elem.text, "<!%-%-")) then

                -- Get the comment, clean it up
                local elementContent = string.gsub(elem.text, "<!%-%- ", "")
                elementContent = string.gsub(elementContent, " %-%->", "")
                elementContent = tostring(elementContent)

                -- count the occurrence
                count = count + 1

                local marginParWidth = pandoc.RawInline('latex', '\\setlength\\marginparwidth{85pt}')

                local openLatex = pandoc.RawInline('latex', '\\marginpar{\\scriptsize {')
                local closeLatex = pandoc.RawInline('latex', '}}')
                local reverseMarginpar = pandoc.RawInline('latex', '\\reversemarginpar')
                local normalMarginpar = pandoc.RawInline('latex', '\\normalmarginpar')

                local openAlignRight = pandoc.RawInline('latex', "\\raggedright{")
                local closeAlignRight = pandoc.RawInline('latex', '}')

                -- define margin left or right
                if (count % 2 == 0) then
                    -- even, goes in right
                    return {

                    return {
1 Like

I think that your idea is going to be much more used, but would perhaps not work via CSS alone like what I did. So I can’t help you for that reason, not in the near future at least.

If you make that a request I’m sure someone with JS skills can jump into action, doesn’t sound like it would be terribly hard, and it does sound like more people would like the idea.