Live Preview: Improve rendering of images (similar to tables and callouts, render per block rather than per image link?)

Use case or problem

Reading mode rendering of images just look so much better, specifically when using CSS snippets for improving image positions (like with the ITS theme, Minimal theme, and other themes and snippets).

Currently in the live preview editor: while vanilla use-cases probably work well, there are still some obvious issues when using CSS snippets:

  • Image grids snippets don’t work in live preview (not without a workaround at least). If the images are quite large, they can take up a lot of space in the editor, which means a less “optimized” view of the note, and a lot more scrolling. The images would perhaps be taking much less space (thus require less scrolling) when the image grids are displayed in reading mode, and without having to manually resize each image. Not to mention, the latter looks much neater and organized. Here are some examples (using Minimal’s image grids):

Img vs

You can tell which view/mode is which.

  • Not all image position and adjustment snippets work. The ITS theme’s ![[img.png|center]] works in live preview, but not ![[img.png|right]]; both work in reading mode. Though this might just be an issue that can be solved right from the css snippet itself, my point is that, ideally, how images are rendered in reading mode should be rendered the same way in live preview, regardless of whether or not the CSS has been coded to work properly in the latter. This should also mean less work for the theme devs: if the CSS works as intended in reading mode, it should also be the case in live preview. Thus, the devs can just focus on getting it to work in one of the views without having to worry about it not working in the other.

Proposed solution

While I believe that the new live preview tables can be improved, I think the current way that they’re rendered would work well with images: rendering them as how they would be displayed in reading mode, and only showing the source format when the cursor is located at the block of where the image links are; something like this perhaps:

Right now, the source format for image links show when the cursor is located on the image link itself—while still rendering the image itself:

Rendering images on the block-level as opposed to the current way would work better with image grids and with image position snippets without any text beside the images. I think the suggestion would also be an improvement for images with text beside them, though I’m not exactly sure how that can be rendered.
I’m also not sure whether the image should still be rendering while showing the source format (as is currently the case) or not (i.e., the images stop rendering or disappear when the source format is shown, which is currently the case for markdown tables and callouts).

Current workaround (optional)

From what I’m aware of, the workaround for live preview tables before they were natively implemented was to place these markdown tables inside Admonition blocks, that way they actually render in LP as though in reading mode.

We can use this same approach as a workaround for getting images to render properly in live preview by placing these image transclusions inside callouts:

> [!NOTE]
> ![[Image1.png#grid]]![[Image2.png#grid]]![[Image3.png#grid]]
>
> ![[Image4.png#grid]]![[Image5.png#grid]]

This workaround works with ITS’s image grids but not with Minimal’s (in fact, Minimal image grids don’t work inside callouts in reading mode either).

Some other comments:

I’m not a dev or coder by any means, CSS or otherwise. I have no idea how feasible this proposal is. The complaints and suggestions I’ve given come from a lack of knowledge of how these things actually work. The suggestions I gave might also be just useful for me but problematic or less preferable for other users.
In any case, I hope this can start some discussion about how live preview images are currently rendered and how they can improve, some other suggestions or thoughts I haven’t mentioned or considered, the problems that arise from actually implementing this, etc., etc.

6 Likes

So I just found out about @efemkay’s (sorry for the ping!) multi-column snippet, which I think can be used as an interesting workaround for live-preview image-grids (and other image adjustments). Here’s one way of doing so:

> [!multi-column]
> 
>> [!blank-container]
>> ![[Image1.png]]
>
>> [!blank-container]
>> ![[Image2.png]]
>
>> [!blank-container]
>> ![[Image3.png]]

Ok so it’s not as neat as with actual image-grids (the images don’t have the same height and the gap between them is too big), but combining both (ITS) image-grid and multi-column snippets, we get:

> [!multi-column]
>> [!blank-container]
>> ![[Image1.png#grid]]![[Image2.png#grid]]![[Image 3.png#grid]]

or

> [!blank-container]
> ![[Image1.png#grid]]![[Image2.png#grid]]![[Image 3.png#grid]]

Here, I’m not using/relying on multi-column per se, but the blank-container feature from the same snippet. The difference then with this and simply placing the same image links inside standard callouts is that… well, the former doesn’t look like a callout, since everything but the contents (in this case, the images) are invisible. This might be the closest so far in actually getting images to render properly in live preview as it does in reading mode, but it’s still not as intuitive compared to it working right out of the box

1 Like

thanks for the shout out. the reason this layout in live preview is difficult is because of how obsidian structure their html DOM. callout gives it a “wrapper container” that allow some creative layout.

anyway, i’m actually working on a custom callout for my MCL for image gallery just like your use. i’ll keep in mind to tag you when i done it.

1 Like

Ayy thanks for the quick response (apologies for mine not being quick at all :sweat_smile:). Really glad to know about the custom callout you’re planning (I guess pinging you wasn’t a mistake after all!). I’m really interested in what you come up with and what similarities and differences there are with this custom callout from the current image-grid solutions (ITS, Minimal, etc.)

Thanks for pointing this out, though I’m having a hard time understanding, especially the DOM part :sweat_smile:

Forgive me if the following is unrelated to your comment, but I’m curious how difficult live preview images are to implement compared to the already implemented live preview tables. I guess the difference is that tables and callouts are already blocks themselves if that makes sense, they already take up an entire block as opposed to image links which can have text and other stuff beside them; you can’t really have text “beside” tables and callouts (not even block-ids I think, they’d have to be after line-breaks), the two are just fundamentally different from images/image links, thus getting live preview images to work is not as simple as doing the same thing the devs did with live preview tables I assume.

well, i’m not the right resource person to answer your last para questions. but from my understanding, the editing view (hence live preview) is modified codemirror (CM) text editor.

the obsidian dev has done great effort making live preview close to reading view. columns are tricky to do with CM and thus things like table, the dev decided to render it block basis with editing the table still line by line (meaning if u add column to the top line, the bottom row doesn’t correspond accordingly)

i just updated my MCL collection to include image gallery (either using callout or yaml). check it out if this fits your use.