HtmlInlineRenderer escape #597

New Issue

claunia · 2026-01-29T14:40:43Z

claunia commented

2026-01-29 14:40:43 +00:00

Originally created by @GilbertoTheMighty on GitHub (Apr 8, 2023).

Default implementation not using EnableHtmlEscape in HtmlInlineRenderer and HtmlBlockRenderer. I have a markdown like this:

This code defines a static class Connections that contains the following fields and methods:

- The NewCommand field, which is an EventHandler<Command> event. This event is raised when a new command is received from an IoT device.
- The Things field, which is a list of IoT objects. This list stores all connected IoT devices.

After default Markdown.ToHtml() <Command> is not escaped.

So I have to do a custom HtmlInlineRenderer that does renderer.WriteEscape

Why HtmlRenderer is not reusable? I would like to have a class member render to reuse it on each incoming text instead of creating 4 objects each time:

public string MakeMessage(string text)
        {
            var Writer = new StringWriter();
            var Render = new HtmlRenderer(Writer);

            Render.ObjectRenderers.Replace<HtmlBlockRenderer>(new CustomHtmlBlockRenderer());
            Render.ObjectRenderers.Replace<HtmlInlineRenderer>(new CustomHtmlInlineRenderer());

            Markdown.Convert(text, Render, Pipeline);

            return Writer.ToString();
        }

It would be nice to have Render.Reset()

Originally created by @GilbertoTheMighty on GitHub (Apr 8, 2023). Default implementation not using `EnableHtmlEscape` in `HtmlInlineRenderer` and `HtmlBlockRenderer`. I have a markdown like this: ``` This code defines a static class Connections that contains the following fields and methods: - The NewCommand field, which is an EventHandler<Command> event. This event is raised when a new command is received from an IoT device. - The Things field, which is a list of IoT objects. This list stores all connected IoT devices. ``` After default Markdown.ToHtml() `<Command>` is not escaped. So I have to do a custom `HtmlInlineRenderer` that does `renderer.WriteEscape` --------- Why HtmlRenderer is not reusable? I would like to have a class member render to reuse it on each incoming text instead of creating 4 objects each time: ``` public string MakeMessage(string text) { var Writer = new StringWriter(); var Render = new HtmlRenderer(Writer); Render.ObjectRenderers.Replace<HtmlBlockRenderer>(new CustomHtmlBlockRenderer()); Render.ObjectRenderers.Replace<HtmlInlineRenderer>(new CustomHtmlInlineRenderer()); Markdown.Convert(text, Render, Pipeline); return Writer.ToString(); } ``` It would be nice to have `Render.Reset()`

claunia added the question label 2026-01-29 14:40:43 +00:00

claunia commented

2026-01-29 14:40:44 +00:00

@xoofx commented on GitHub (Apr 22, 2023):

After default Markdown.ToHtml() is not escaped.
So I have to do a custom HtmlInlineRenderer that does renderer.WriteEscape

Don't remember the details about this, but PR welcome if you want this to be fixed.

Why HtmlRenderer is not reusable? I would like to have a class member render to reuse it on each incoming text instead of creating 4 objects each time:

You can keep a reference to a single HtmlRenderer (at least per thread) and reset the backend StringWriter (as long as you use it with the same render pipeline...etc.), so I would think that it is somehow reusable in some ways.

@xoofx commented on GitHub (Apr 22, 2023): > After default Markdown.ToHtml() <Command> is not escaped. > So I have to do a custom HtmlInlineRenderer that does renderer.WriteEscape Don't remember the details about this, but PR welcome if you want this to be fixed. > Why HtmlRenderer is not reusable? I would like to have a class member render to reuse it on each incoming text instead of creating 4 objects each time: You can keep a reference to a single HtmlRenderer (at least per thread) and reset the backend `StringWriter` (as long as you use it with the same render pipeline...etc.), so I would think that it is somehow reusable in some ways.

claunia referenced this issue

2026-01-29 14:50:16 +00:00

[PR #607] [MERGED] Start of documentation on parser #1138

claunia referenced this issue

2026-01-29 14:50:20 +00:00

[PR #607] Start of documentation on parser #1143

Sign in to join this conversation.