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)
But maybe thereâs a different syntax?
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. 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.
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!)
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:
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.)
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.
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.
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
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 ):
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
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.