# Inline Markdown vs Block Markdown **URL:** \ **Category:** Uncategorized\ **Created:** [September 4, 2014, 6:02pm UTC](https://talk.commonmark.org/t/inline-markdown-vs-block-markdown/357 "2014-09-04T18:02:03Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![zzzzBov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zzzzbov/32/218_2.png) [@zzzzBov](https://talk.commonmark.org/u/zzzzBov)\ **Post date:** [September 4, 2014, 6:02pm UTC](https://talk.commonmark.org/t/inline-markdown-vs-block-markdown/357/1 "2014-09-04T18:02:03Z")
With content management systems it’s often necessary to add fields to manage content within a heading, link, or other context where [phrasing content](http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#phrasing-content) is expected. For example, with block markdown: ``` lorem *ipsum* dolor sit amet ``` would be parsed to: ```

lorem ipsum dolor sit amet ``` while with inline markdown it could be parsed to: ``` lorem ipsum 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. ---

**Author:** ![yamadapc](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/yamadapc/32/193_2.png) [@yamadapc](https://talk.commonmark.org/u/yamadapc)\ **Post date:** [September 4, 2014, 6:09pm UTC](https://talk.commonmark.org/t/inline-markdown-vs-block-markdown/357/2 "2014-09-04T18:09:32Z")
As far as I understand the spec separates blocks from inlines as in [“blocks and inlines”](http://jgm.github.io/stmd/spec.html#blocks-and-inlines). I’d say specific implementations could support parsing of only the inline markdown (as in [“inlines”](http://jgm.github.io/stmd/spec.html#inlines)), but maybe I’m missing the point. ---
**Author:** ![riking](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/riking/32/23_2.png) [@riking](https://talk.commonmark.org/u/riking)\ **Post date:** [September 4, 2014, 6:10pm UTC](https://talk.commonmark.org/t/inline-markdown-vs-block-markdown/357/3 "2014-09-04T18:10:37Z")
> [@zzzzbov](#): > > Filtering the output of a markdown parser through a whitelist or other post-processing system can solve the problem You will need to do this anyways if you are accepting user-submitted Markdown. Consider the following Markdown: ``` Hello guys! ``` You will need to pass it through a whitelist anyways. > [@yamadapc](#): > > I’d say specific implementations could support parsing of only the inline markdown (as in “inlines”), but maybe I’m missing the point. I think that is exactly the point, and would be pretty neat. ---
**Author:** ![zzzzBov](https://cdn.commonmark.org/user_avatar/talk.commonmark.org/zzzzbov/32/218_2.png) [@zzzzBov](https://talk.commonmark.org/u/zzzzBov)\ **Post date:** [September 4, 2014, 6:53pm UTC](https://talk.commonmark.org/t/inline-markdown-vs-block-markdown/357/4 "2014-09-04T18:53:03Z")
> [@riking](#): > > You will need to do this anyways if you are accepting user-submitted Markdown. 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

tags ``` in an inline context could be parsed into ``` All about <p> tags ``` or ``` All about tags ``` depending on whether the offending element is stripped or HTML encoded.