The inevitable "MarkdownExtra" topic

My point is that this is part of “Standard Markdown”.

Extensibility has been a huge thing for me also. The implementation I’ve usually used is showdown and the major win for it is that it allows pretty easy extensions even though it isn’t maintained at all.

I would switch to stmd immediately if extensions were easy.

Extensions can come later. This project has the limited goal of
standardizing “core” markdown features. There’s plenty to worry about
there before we go to extensions.


I couldn’t find that in my (cursory) reading of the standard. The Markdown Extra syntax is not supported:

Header 1            {#header1}

[Link to the first header.](#header1)

Try it out.

But maybe there’s a different syntax?

1 Like

Yeah, I think we need to come up with a way to add extensions to the spec in a way that the extensions make sense.

E.g., the extension should specify whether it is adding a container block, leaf block, or inline element. I think that’s the #1 thing - several “existing extensions” come up with their own syntax that breaks the container/leaf/inline categorization.

And it should probably specify how conflicts are resolved with the standard spec.

Sorry, I was explicitely referring to the link stuff only. Tables and such are not in the spec, yes.

So, I suppose that would be something like…

This extension modifies 4.3, Setext Headers to allow the declaration of link anchors.

A setext header anchor begins with the #symbol and is enclosed in braces (…)

Ah, okay. I need to read more. :blush: OTOH (!) it doesn’t appear that Standard Markdown (at § 4.7) quite supplies the same possibility as MardkownExtra. For example, in StdMd this Md > HTML is possible:

## [My Title][mt]
[mt]: /title "name"

to produce:

<h2><a href="/title" title="name">My Title</a></h2>

But I can’t see a way of producing:

<h2 id="name">My Title</h2>

which is the type of name/anchor markup used in the Standard Markdown link above, for example. It would be good to have both, of course. The difference between them is the the latter doesn’t need to have a bogus link, and get marked up as <a href="#">...</a> text, of course.

1 Like

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!)

1 Like

I agree that this would be a good extension to support, but right now
the focus is on core features.

Suggestion: reserve reStructuredText’s tagged block and inline syntax for use by future extensions. The block syntax looks approximately like this:

.. tag:

with mandatory blank lines before and after, and the inline syntax looks approximately like this:

text text text :tag:`tagged text` text text text

(Both have a lot of additional hair that may or may not be worth bringing over.)

I just wanted to speak up here and say that I too would love to see Footnote support added along the lines of how Multimarkdown or Markdown Extra implements Footnotes.

1 Like

I suggest someone should create a topic about how best to include simple extensibility points for extensions, ways to namespace them and handle order so they don’t conflict, etcetera. That is the best thing to discuss right now.

1 Like

See Feature request: automatically generated ids for headers - #5 by zwol for the discussion about this feature

One extension I love is the definition lists one: actually they are implemented by Kramdown. PHP Markdown extra, pandoc, MultiMarkdown and other interpreters, in various flavours.

I use a lot this extension (and in general HTML definition lists): I find it useful for example for changelogs. Consider the readability this:

## ChangeLog

: Update README
: Update of the script comment in order to reflect the README
: Fix minor bug
: First release

Compared to the HTML version:

## ChangeLog

  <dt>1.0.2</dt> <dd>Update README</dd>
                 <dd>Update the script comment in order to reflect the README</dd>
  <dt>1.0.1</dt> <dd>Fix minor bug</dd>
  <dt>1.0.0</dt> <dd>First release</dd>

This is the result (definition lists formatting colud be improved here IMHO :blush:):


Update the script comment in order to reflect the README
Fix minor bug
First release

If CommonMark is focusing on getting core features standardized right now, then it’s not the time to discuss particular extension proposals but it’s getting late to start discussing how optional features might in principle be added to the spec.

I’d go as far as to say version 1.0.1 of the spec should include a sample or near-trivial extension so any difficulties can be worked through now rather than when things are more settled, do you agree?


There’s another thread on “plugins” which might be a good place for that discussion. (An even earlier thread got attached to the “Spec” category, as the “Extensions” category wasn’t available then.)

Thanks for the links, I’ve started a new topic as name-spaced extensions aren’t exactly what I had in mind.

Probably most of MarkdownExtra could fit in the directives plugin proposal.

I moved 3 posts to a new topic: How should footnotes behave?