Skip to content




Do you find it obnoxious how the box updates every time you type a character? Would like for it to maybe wait a second until after you've stopped typing? Through absurd jank, I have achieved exactly that. The Delay Update setting will cause the renderer to wait that many milliseconds before updating.

Because of how this feature works, it's a teensy bit janky. If you have multiple infoboxes and move them around, they'll ghost for a second as each other before updating. I figure people probably won't be changing the order of infoboxes in their documents that much so it's probably fine.

This also breaks embeds, but my postpostpostprocessor repairs them (except for transclusions unfortunately).


Default Class - this class will be applied to boxes depending on the class behaviour setting. You can type any string as long as it's a valid class name, or open the dropdown to select one of my lovingly crafted and exceedingly stylish classes that come included (you have to empty the box before the options will show up though).

Class Behaviour - Select never to disable application of a default class, or only when none is provided which will apply the default only if you do not pass a .class to the zeroth argument.

Suppress Errors - Should the parser tolerate errors? For example: if enabled, arguments with unknown types will simply be skipped, whereas otherwise the table render would abort and display an error message. Some errors will still cause the render to fail even if this is enabled.

Fix Unloading

Because of how Obsidian works, the height of floated block elements that contain MarkdownRenderChildren (such as an infobox) is not measured properly, which means poor scroll syncing. This behaviour can be avoided by overriding the display type with CSS. This same behaviour also causes issues with tall infoboxes, which may become unloaded before actually being offscreen.

The setting Fix Unloading causes pages with infoboxes to not unload elements that are offscreen (a normal behavior of Obsidian that improves performance). If you experience issues with scroll-jumping, you can either use a positioning method other than float, or enable this setting. I have not noticed any performance issues with this, but it might be more significant on laptop or mobile devices (though fortunately on mobile you might be using anchored boxes which are not floated and thus not subject to this concern).

Regarding issues with floated elements and scroll sync: If an infobox is significantly larger than its defining codeblock, the scroll synchonization of linked panes may prevent you from actually keeping the part of the table you're editing and the codeblock in view at the same time. To work around this, temporarily unlink the panes.

Perhaps at some point in the future this issue will be resolved.