It would be useful to have standard syntax to identify a "plugin".

This would allow parsers & renderers to perform additional behavior (if they support it).

Perhaps something like the shortcodes in Hugo: http://hugo.spf13.com/extras/shortcodes/

Eg:

{{% youtube 09jf3ow9jfw %}}

Would generate appropriate HTML to generate an embedded Youtube link for HTML output but something else for some other output target.

Another example:

{{% figure src="/media/spf13.jpg" title="Steve Francia" %}}

to generate a properly formatted figure.

The spec could cover the basic plugin syntax and what happens when the plugin is not supported etc...

This is part of the more general concept of "markdown extensions".

Your definition of "plugin" is unnecessarily strict, in my opinion.

The spec could cover the basic plugin syntax and what happens when the plugin is not supported etc...

There shouldn't need to be just one "plugin syntax".

---

I would want to see something like this:

This Markdown Extension adds Hugo Shortcodes.

A shortcode is an inline element, and is parsed inside of both block and inline HTML.

A shortcode begins with two opening braces ....

There's some discussion over here about extensions:

True, and I appreciate that. It looks as if some minor "extensions" are already in the Standard though (as in the Link reference definitions noted elsehwere in this thread), so perhaps it's worth at least having this on the edge of the radar, with suitably managed expectation? (I hope?) (And while I'm at it, thank you for what you've done here -- I had been hoping for something like this for a while!)

My contribution to the topic is basically reproduced above - basically stating that extensions should have specs similar to the Standard Markdown spec.

This is definitely something Rust's documentation system Rustdoc would like to see in one form or another. We've been considering a migration to reStructuredText due to Markdown's poor standardization, and lack of extensibility. However we prefer markdown for its popularity and simplicity (we want writing docs to be super accessible). Standard Markdown of course resolves the former issue, so having a solution to the latter would be highly desirable!

In particular, we're interested in being able to write the following extensions:

• Mathjax support: adds a new inline and block element with similar semantics to the inline and block code elements that mathjax can correctly handle on the clientside
• "Relative" header levels for embedding markdown fragments. That is, # foo isn't an <h1>, but rather an <h(1 + base_level)>.
• Special known sections to be handled differently. Unclear at what level this would be exposed. Just a css class that gets added to be styled/selected on? Or extra metadata returned with the parse to be further used by the caller?
• Custom link types. In our case we'd like to be able to say something to the effect of "link to the function/struct/module with this name".