The inevitable "MarkdownExtra" topic

Extensions
1

This is a fantastic development, and no mistake. That needs to be said first.

In discussions about Markdown implementation on Meta.StackExchange (of various kinds) some of the most desired features not implemented in Markdown have been identified: support for tables and footnotes appearing high in the pecking order, but definition lists and even “special attributes” might be added (this latter not nearly so significant, imo, but still worth noting).

These of course have long been found in MarkdownExtra and it seems inevitable that the question should be raised about where these fit in to the Standard Markdown initiative now that it has seen light of day.

So – what plans for implementing these “extensions”, then?

9 Likes
2

There are also site specific extensions (github task lists). I’m interested to know what the plan is.

1 Like
3

Markdown Extra also defines a syntax for making internal links to headers and such. It also included fenced code blocks, but I see that’s already part of the the standard.

1 Like
4

The link destination is not really restricted to anything, so relative URLs are already supported. For example:

[Relative link](/blog)
[back to top](#top)
5

The trick here, I think, is that setting the #top target isn’t possible in vanilla Markdown, although it is in MDExtra.

6

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

7

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.

8

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.

3 Likes
9

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
10

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.

11

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

12

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 (…)

13

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
14

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
15

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

16

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

.. tag:
    text

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

17

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
18

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
19

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

20

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

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

Compared to the HTML version:

## ChangeLog

<dl>
  <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>
</dl>

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

ChangeLog

1.0.2
Update README
Update the script comment in order to reflect the README
1.0.1
Fix minor bug
1.0.0
First release
2 Likes