Markdown within HTML


Apologies for abandoning this thread for awhile. I’m super excited to see how much discussion this has generated!


I spent some time checking out all the work you’ve done, and I’m super impressed! These are exactly the steps I would have wanted to start with before doing a polyfill. I can see this test suite being super useful, and the fact that you have a spec doc setup for PRs already is also amazing. As @jonathank suggested, it would be great if we could push in some tests for JS parsers.

I had totally forgotten that the W3C group existed, and that I was a member of it. Is everybody here that’s interested in pursuing this already a member of that group? Should we move the discussion there?

Custom elements (i.e. web components) did come up earlier in this thread. As I mentioned earlier, I personally believe that focusing on attributes rather than elements is the best way forward, but I certainly wouldn’t discount web components—such as the one @briankardell linked to—as an option.

Yup. IMO, that’s another reason why an attribute-based version, which could support different flavours (e.g. format="markdown" vs. format="markdown-gfm" or format="markdown" flavor="gfm"), might be preferable. For me a goal would be not just to standardize a particular flavour of Markdown, but to standardize how those are and can be extended.

+1 for more generic, hence my suggestion of a format attribute.

How has it been a bad idea?


I’m not a member of the group mostly as I had not got the Community agreement signed by my employer yet.

I think the ability to filter out HTML would be worthwhile from a security stand point it seems to make sense just for pure markdown support and not markup from user input, having the ability to set a parameter in JS/HTML to filter the HTML would add belt and braces security to it. type="text/markdown-plain" or similar.

I think the only real way to bring a form of unity to the standard without fragmenting into the different flavours would be support all the nuances within each flavour. To my understanding that isn’t a large amount of features.

For example: I am pretty keen to see citation and anchor support as provided in an older version of MultiMarkdown(I have not checked if it is still supported).

As you mentioned there is two real tasks here:

  1. Standardising Markdown format which parsers can then follow, a validator can come out of the tests mentioned above.
  2. Standardising a module for HTML for embedding extensions like Markdown into HTML via either a tag or parameters.

I think that if Markdown can be standardised well then the embedding could be the <markdown> tag to match <math> and <svg>. The reason I currently was suggesting the attribute way of embedding was due to the fragmentation as mentioned.

However standardising the ability to extend HTML via an attribute would have its merits far beyond just Markdown especially as Web components don’t really seem to be suited to marking up a embedded text format/language.


I’m sure most people have seen this, but just in case:

So… assuming this takes off, it seems to take care of the “we need a standard syntax” bit.


Yup, and after reading the spec, I’m fairly excited about it. Let’s wait for it to stabilize and take off, then pursue this avenue again.


Chiming in that I’m working on a site to document the different standards / variations of Markdown at

What I’d like to see is a W3C/IETF/ANSI standard Markdown (that could then be referred to as “W3C Markdown” or “W3C Standard Markdown”, so as to avoid all the implied-ownership drama that surrounded the bare “Standard Markdown” name), with a parsing routine defined as thorougly as the HTML Living Standard, that is restrained to only the core features defined by the Gruber specification, and then some sensible “vendor” extensions made on top of that (like GFM).

And then, of course, Custom Elements for sites that want to do in-document Markdown parsing (since every site rightly has its own flavor of Markdown- look at Discourse and its Hybrid-BBCode-Markdown for an example).


CommonMark is doing just fine now - it’s getting tightened up and doing well. No more name drama!

Feel free to contribute to it - it’s got its own Discourse instance for talking about features, at


That would be of course.