handling inline html

[u-fischer]

I have a markdown file which contains x<sub>2</sub> to set x₂.

How is one supposed to define a renderer for this? The inlineHtmlTag only gets one argument, the html tag, and I see no way to get at the content between both tags to put braces around the argument?

As I have only one number I tried to cheat and let the begin tag grab the argument. That actually worked in a small example, but fails in the real document as relativeReferences disables the html processing ;-(

\documentclass{article}
\usepackage[%relativeReferences   %with it it doesn't work.         
            ]{markdown}
\ExplSyntaxOn
\markdownSetup {rendererPrototypes = 
 {
   inlineHtmlTag=\str_if_eq:nnT{#1}{<sub>}{\textsubscript}   
 }}
\ExplSyntaxOff 
\begin{document}
\begin{markdown}
x<sub>2</sub> 
\end{markdown}
\end{document}

[Witiko]

How is one supposed to define a renderer for this? The inlineHtmlTag only gets one argument, the html tag, and I see no way to get at the content between both tags to put braces around the argument?

With difficulty. You would need to scan ahead hoping for a closing HTML tag. There is no attempt to provide comprehensive support for rendering HTML elements at this moment.

We might add an option to enable a new parsing regime for HTML that would produce more useful renderers for all aspects of HTML code, similarly to YAML. However, there's currently no detailed proposal (see e.g. #517) for this feature, which would be required to start the implementation.

Since our parser already differentiates between different types of HTML content following CommonMark's model of HTML, we could start by exposing the corresponding PEG parsers as individual renderers. While it's unclear whether this would be sufficient for rendering HTML in TeX, it would be a start and definitely much less work than including a full-blown HTML parser in addition to the current CommonMark parser.

That actually worked in a small example, but fails in the real document as relativeReferences disables the html processing ;-(

That is an unintended consequence of our RFC-compliance: The option relativeReferences allows relative references enclosed in angle brackets to be parsed as hyperlinks. The main use is for fragments like <#identifier>, but in practice, almost any HTML tag is also an RFC-compliant relative reference enclosed in angle brackets. Therefore, with the option relativeReferences enabled, most inline HTML tags produce the link renderer instead of the inlineHtmlTag renderer.

On the first glance, this may seem like a bug: Shouldn't we always prefer HTML tags over hyperlinks? However, it's also a bit arbitrary and users may depend on the current behavior. Therefore, unless we want to start work on a new major release of the Markdown package that would be allowed to break backwards compatibility, we'd need to add a new option titled e.g. htmlOverLinks that would make the Markdown package always prefer HTML tags over hyperlinks. This new option would be enabled by default when the option experimental is also enabled. In the next major release, we would enable the new option by default always.