[Suggestion] Make markdig renderer-agnostic #63

New Issue

claunia · 2026-01-29T14:24:20Z

claunia commented

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

Originally created by @Kryptos-FR on GitHub (Oct 16, 2016).

Currently Markdig is still coupled with its HTML renderer. This makes writing new renderers very challenging.

One of the issue I encountered recently is when trying to also support extensions in my XAML renderer. For example when configuring the pipeline the following way:

var pipelinenew MarkdownPipelineBuilder()
    .UseTaskLists()
    .Build();

the TaskList extension is adding aHtmlTaskListRenderer. But in my case I would like it to add my own custom XamlTaskListRenderer instead.

Arguably I could duplicate the whole extensions mechanism to inject my own implementations but I think this defeats the purpose. Ideally all the existing code for the extensions (parsers, inlines) with the exceptions of the renderer should stay the same. So it would be nice to have another way to match/replace renderers without breaking the whole extension mechanism.

Going further, the current Markdig could be split into two assemblies: Markdig.Core which is unaware of any specific renderer (e.g. in my case I don't need to ship the HTML rendering specific code) and Markdig.HTML for the HTML rendering (which in my case is replaced by Markdig.Xaml).

Originally created by @Kryptos-FR on GitHub (Oct 16, 2016). Currently Markdig is still coupled with its HTML renderer. This makes writing new renderers very challenging. One of the issue I encountered recently is when trying to also support extensions in my XAML renderer. For example when configuring the pipeline the following way: ``` csharp var pipelinenew MarkdownPipelineBuilder() .UseTaskLists() .Build(); ``` the `TaskList` extension is adding a`HtmlTaskListRenderer`. But in my case I would like it to add my own custom `XamlTaskListRenderer` instead. Arguably I could duplicate the whole extensions mechanism to inject my own implementations but I think this defeats the purpose. Ideally all the existing code for the extensions (parsers, inlines) with the exceptions of the renderer should stay the same. So it would be nice to have another way to match/replace renderers without breaking the whole extension mechanism. Going further, the current Markdig could be split into two assemblies: Markdig.Core which is unaware of any specific renderer (e.g. in my case I don't need to ship the HTML rendering specific code) and Markdig.HTML for the HTML rendering (which in my case is replaced by Markdig.Xaml).

claunia added the enhancement label 2026-01-29 14:24:20 +00:00

claunia closed this issue

2026-01-29 14:24:22 +00:00

claunia commented

2026-01-29 14:24:23 +00:00

@xoofx commented on GitHub (Oct 16, 2016):

I would like to avoid splitting assemblies, as the primary goal of Markdig is to provide a Markdown parser with a default HTML renderer.

The commit a5e53b0 should fix your issue as the call to the renderer (Setup) provides now an access to the pipeline from which you can query the existing active extensions used to parse the document with this pipeline.

Let me know if you encounter any problem.

@xoofx commented on GitHub (Oct 16, 2016): I would like to avoid splitting assemblies, as the primary goal of Markdig is to provide a Markdown parser with a default HTML renderer. The commit a5e53b0 should fix your issue as the call to the renderer (Setup) provides now an access to the pipeline from which you can query the existing active extensions used to parse the document with this pipeline. Let me know if you encounter any problem.

claunia commented

2026-01-29 14:24:24 +00:00

@xoofx commented on GitHub (Oct 27, 2016):

@Kryptos-FR Are you able to proceed further on your side with these changes?

@xoofx commented on GitHub (Oct 27, 2016): @Kryptos-FR Are you able to proceed further on your side with these changes?

claunia commented

2026-01-29 14:24:26 +00:00

@Kryptos-FR commented on GitHub (Oct 28, 2016):

@xoofx Ah sorry I did not use it yet. I will try this week-end.

@Kryptos-FR commented on GitHub (Oct 28, 2016): @xoofx Ah sorry I did not use it yet. I will try this week-end.

claunia commented

2026-01-29 14:24:27 +00:00

@jbaehr commented on GitHub (Nov 3, 2016):

I'm also interested in alternative render back-ends. My use case is MAML, to be able to write conceptual documentation with Sandcastle using Markdown.
I'm aiming for a SHFB Plugin that allows Markdown as input (either standalone pages or embedded). The template here is Immo's excelent xsddoc Plugin

@jbaehr commented on GitHub (Nov 3, 2016): I'm also interested in alternative render back-ends. My use case is MAML, to be able to write [conceptual documentation](http://ewsoftware.github.io/SHFB/html/5292ce5c-fda1-4a77-9155-a11755ef1730.htm) with [Sandcastle](https://github.com/EWSoftware/SHFB) using Markdown. I'm aiming for a [SHFB Plugin](http://ewsoftware.github.io/SHFB/html/e031b14e-42f0-47e1-af4c-9fed2b88cbc7.htm) that allows Markdown as input (either standalone pages or embedded). The template here is Immo's excelent [xsddoc Plugin](https://github.com/terrajobst/xsddoc)

claunia commented

2026-01-29 14:24:28 +00:00

@xoofx commented on GitHub (May 8, 2017):

Closing this issue as there should be nothing blocking for implementing a different renderer.

@xoofx commented on GitHub (May 8, 2017): Closing this issue as there should be nothing blocking for implementing a different renderer.

claunia referenced this issue

2026-01-29 14:48:06 +00:00

[PR #387] [MERGED] Add missing Descendants<T> api #977

claunia referenced this issue

2026-01-29 14:48:06 +00:00

[PR #387] Add missing Descendants<T> api #980

Sign in to join this conversation.