Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<img> not rendering in live preview for .html files #907

Closed
ncfreedman opened this issue Jan 27, 2022 · 4 comments
Closed

<img> not rendering in live preview for .html files #907

ncfreedman opened this issue Jan 27, 2022 · 4 comments
Assignees

Comments

@ncfreedman
Copy link

ncfreedman commented Jan 27, 2022

While working on .html files, elements using relative links are not rendered in the live preview and instead yield the broken image icon (<img src="image.png"> yeilds ) Any ideas for why this is? It would be such a great help if there was any way of fixing this.

@RickStrahl RickStrahl self-assigned this Jan 27, 2022
@RickStrahl
Copy link
Owner

RickStrahl commented Jan 27, 2022

The problem is that the previewer previews from a temporary file location and not in the folder that the actual file lives. So images aren't found unless there's a <base> reference back to the page:

For example, the Markdown Previews render into <tempPath>\_MarkdownMonster_Preview.html. It then sets the <base> back to the original document's folder:

<html lang="en">
<head>
    <base href="file:///C:/projects/MarkdownMonster/"/>

which allows it to find all the relative assets.

This is also true for HTML files because it's not just previewed but basically 'rendered' (copied as is in this case) and then previewed using the standard editor/Markdown preview. At the time I probably didn't think about this much, just kind of as a bonus that it worked out of box.

Agree with you though - MM should just open the file from the actual location.

There are two ways this could be fixed:

  1. Don't copy the HTML file, open from source

  2. Inject <base> ref back to the original path to the doc header

  3. is probably easier as everything will just work the way it does now. The problem with 1. is that it requires lots of special checks and handling to keep track of where output goes and where to render the preview from. Untitled documents wouldn't have a base folder for example, if the doc name changes the preview file has to change etc. This is no big deal if it was just a preview, but with it being tied to the editor this is all stuff that's already been solved in the MD->HTML rendering.

So I think I'll take a look and see about 2. which on the surface sounds pretty straight forward.

@RickStrahl
Copy link
Owner

I've added the <base> injection code into rendering for HTML documents and this seems to work really well - I'm now able to properly preview most documents with their related resources:

image

But this will not work, if the document already has a base tag and the base tag is not a fully qualified path.

It's a nice enhancements for the most common use case even if it has limitations compared to the much more full featured preview features of Markdown.

Thanks - this is a great addition!

@ncfreedman
Copy link
Author

Thanks for this!!

@RickStrahl
Copy link
Owner

Updated in 2.3.7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants