Several kinds of inline markup in doc comments don't produce corresponding HTML tags.
For instance, test-files/golden-tests/javadoc/inline/styled.cpp contains _italic_, which produces a doc::EmphInline in the metadata, but the HTML golden renders it as the bare text "italic", with no <em> wrapper. The XML golden has <emph>...</emph> correctly; the AsciiDoc golden renders _italic_ correctly.
Cause
Each affected share/mrdocs/addons/generator/common/partials/doc/inline/.hbs invokes a markup/i partial:
{{#> markup/i }}{{> doc/inline-container }}{{/markup/i}}
For AsciiDoc, share/mrdocs/addons/generator/adoc/partials/markup/i.adoc.hbs exists and renders _..._, so all of these end up rendered identically as italic in Adoc, which happens to be visually correct for emphasis but is semantically wrong for the others. For HTML, share/mrdocs/addons/generator/html/partials/markup/i.html.hbs does not exist; the partial-block invocation produces nothing, and only the inner content survives, hence the missing wrappers.
The shared markup/i indirection conflates several semantically different inline kinds. Each kind should map to its own HTML element.
Several kinds of inline markup in doc comments don't produce corresponding HTML tags.
For instance, test-files/golden-tests/javadoc/inline/styled.cpp contains
_italic_, which produces adoc::EmphInlinein the metadata, but the HTML golden renders it as the bare text "italic", with no<em>wrapper. The XML golden has<emph>...</emph>correctly; the AsciiDoc golden renders_italic_correctly.Cause
Each affected share/mrdocs/addons/generator/common/partials/doc/inline/.hbs invokes a
markup/ipartial:For AsciiDoc, share/mrdocs/addons/generator/adoc/partials/markup/i.adoc.hbs exists and renders
_..._, so all of these end up rendered identically as italic in Adoc, which happens to be visually correct for emphasis but is semantically wrong for the others. For HTML, share/mrdocs/addons/generator/html/partials/markup/i.html.hbs does not exist; the partial-block invocation produces nothing, and only the inner content survives, hence the missing wrappers.The shared
markup/iindirection conflates several semantically different inline kinds. Each kind should map to its own HTML element.