Sean Leonard | 12 Nov 00:47 2014

Opinions on in-band variation signaling

Regarding the text/markdown registration:

At least one commentator (Larry Masinter) specifically requested that the variant identifier be
included in-band in the Markdown content, rather than as part of the metadata. I disagree with in-band
signaling (as has been registered earlier on this list). Nevertheless, I wanted to take a straw poll and
see if anyone has tried to implement in-band Markdown variation identifiers, with any success. Do any
implementers have experience with picking the type of Markdown based on some info at the top of the
Markdown content? Does it work—or will it never work? Or is it “bad” for particular reasons?

By in-band, I mean a Markdown file with content like this:

% This is a Title
% Sean Leonard
% November 2014

Blah blah *blah*.
<<< (fortin’s suggestion)

[!pandoc]: # "This is a pandoc document."
% This is a Title
% Sean Leonard
% November 2014

Blah blah *blah*.
<<< (seantek’s suggestion)

(Continue reading)

Sean Leonard | 12 Nov 00:44 2014

Progress on text/markdown at IETF 91

Hello Markdown Community:

There was discussion and progress on text/markdown at IETF 91. Here are slides:

and here are the interim minutes:

The view is that the syntax parameter of draft-03 should be simplified to a parameter currently called
“variant”, which is a simple US-ASCII case-insensitive identifier. Other considerations are
discussed on the apps-discuss IETF mailing list. The proposal was posted last week, and is below.

I will work on draft-04 over the next couple of weeks.



Optional Parameters:
variant: An optional identifier that serves as a “hint” to the recipient of the specific Markdown
variant that the author intended. When omitted, there is no hint; the interpretation is entirely up to the
receiver and context. This identifier is plain US-ASCII and case-insensitive. People who want interop
can optionally register them using a simple webform (IANA registry), which just asks for the Identifier,
a Description, and Contact Information. If a receiver does not recognize the variant identifier, the
receiver MAY present the identifier to a user to inform him or her of it.
Other parameters MAY be included with the media type. The semantics of such parameters MAY be defined by the
variant; they are not defined here. As an alternative, the variant MAY be registered under another media
(Continue reading)

Jeff McNeill | 11 Nov 07:38 2014

Re: Markdown-Discuss Digest, Vol 139, Issue 3

> As a mere user, I've noticed the same thing. One of the purported 
> benefits of markdown is its portability, i.e., the ability of the user 
> to write in any editor, knowing that he can then load it into any number 
> of parsers and get consistent results.
> But, with all the different flavors out there, one now has to think, 
> "which parser will I use to convert this file?" and insert markdown 
> accordingly. I recently discovered at least four different ways in which 
> parsers deal with typographic quotes and dashes, from the original 
> SmartyPants to the Python Markdown implementation of SmartyPants to the 
> Calibre implementation of it to RMarkdown's implementation (not to 
> mention ReStructuredText and Textile, both of which do it differently, 
> yet). So, I have to commit to a given dialect and converter before I 
> begin to type. To me, that's defeating one of the fundamental purposes 
> of markdown.
> Virgil

I believe that is why a neutral, “Bland” Markdown recommendation is needed. Not as yet another parser
or syntax but as something to tell writers and editors to use, so that their content can be properly processed.

This is actually not too difficult.

Jeff McNeill 
Markdown-Discuss mailing list
Markdown-Discuss <at>
(Continue reading)


mou makes its funding goal for a 1.0 release

mou, as you may know, is a markdown editor.

with its second $5,000 company sponsorship,
mou has reached it's $20,000 indigogo goal...

albeit, the effort engendered some resistance:

the big thorn is that, because mou's developer
has lost interest in the project, trying to sell it,
a mou user stepped up to code an equivalent.

that led the mou developer to resume his effort,
issuing proclamations about "the crappy clones"
in his campaign to raise $20,000 to release 1.0.
(in all the time it's been out, mou's been "beta";
the goal to open-source the code is $100,000.)

i take no side in this dog-fight.

i have no argument with developers getting paid.

and i am not religious on the open-source sauce.

i even think open-source/proprietary tension can
-- in some cases -- create benefits for both sides.

i also believe in supporting developers who have
built a tool that i use constantly, like my text-editor.
(Continue reading)



virgil said:
>   Is  there any way that the developers can come
>   together on this very small part of the Markdown world?

i'd have to say it looks like your answer is "no", virgil.

if it's any consolation, it's not you; it's always like this.

have a nice weekend.

have a nice november.

have a nice 2014...

Virgil Arrington | 28 Oct 17:06 2014

SmartyPants and dashes

Please bear with me as I am just a user and, by no means, a developer. However, I've noticed some inconsistent behavior among different implementations of SmartyPants when it comes to en-dashes and em-dashes.

1. Calibre 2.7

When I recently uploaded a Markdown source file to Calibre and selected its "Smarten punctuation" feature, it converted a double-hyphen "--" into an em-dash, and a triple hyphen "---" into an en-dash. This behavior was the opposite that I have come to expect using both LaTeX and ReText, my default Markdown editor.

I reported the matter as a Calibre bug, but received a response saying that the Calibre behavior was based on the official SmartyPants source code, which states as follows:

"The string, with each instance of "--" translated to an em-dash HTML entity, and each "---" translated to an en-dash HTML entity. Two reasons why: First, unlike the en- and em-dash syntax supported by EducateDashesOldSchool(), it's compatible with existing entries written before SmartyPants 1.1, back when "--" was only used for em-dashes. Second, em-dashes are more common than en-dashes, and so it sort of makes sense that the shortcut should be shorter to type. (Thanks to Aaron Swartz for the idea.)"

Confused by this, I tested two other methods of using SmartyPants, and received inconsistent results.

2. Python Markdown v2.5.1

I use ReText as my Markdown editor. It uses the Smartypants extension that is provided with Python Markdown v2.5.1. It translates "--" as an endash and "---" as an emdash, the *opposite* as Calibre. Below is the translation table found at

ASCII symbol Replacements HTML Entities Substitution Keys
' ‘ ’ &lsquo; &rsquo; 'left-single-quote', 'right-single-quote'
" “ ” &ldquo; &rdquo; 'left-double-quote', 'right-double-quote'
<< >> « » &laquo; &raquo; 'left-angle-quote', 'right-angle-quote'
... &hellip; 'ellipsis'
-- &ndash; 'ndash'
--- &mdash; 'mdash'

At the bottom of the Python/SmartyPants extension page is the following:

"SmartyPants extension is based on the original SmartyPants implementation by John Gruber. Please read it’s documentation for details."

Based on this, I went to Gruber's page and got yet more inconsistency.

3. SmartyPants by John Gruber.

At Gruber's SmartyPants page, ( the following is found:

"SmartyPants can perform the following transformations:
  • Straight quotes ( " and ' ) into “curly” quote HTML entities
  • Backticks-style quotes (``like this'') into “curly” quote HTML entities
  • Dashes (“--” and “---”) into en- and em-dash entities
  • Three consecutive dots (“...”) into an ellipsis entity"

Based on the order of the dashes listed, it would appear as if Gruber is suggesting that "--" would turn into an en-dash, and "---" into an em-dash (consistent with ReText, but not with Calibre). But, if I use Gruber's online Dingus translator (, I get yet a third variation of the conversion. Gruber's online translator converts "--" into an em-dash (as does Calibre) but it turns "---" into an em-dash plus a hyphen (no en-dash). 

There appears to be either confusion or disagreement in the Markdown/SmartyPants world as to how to create typographic dashes. Is there any way that the developers can come together on this very small part of the Markdown world?

Markdown-Discuss mailing list
Markdown-Discuss <at>

the issue with markdown was that it was too simple

> <at> chacon/living-the-future-of-technical-writing-2f368bd0a272

>   scott chacon, github cofounder, author of "pro git", on release of 
the second edition

>   The issue with Markdown was that it was too simple.
>   It didn’t specify things like table formatting, cross references,
>   indexing, callouts, source code examples, etc.
>   All of which Asciidoc does in a format that is just as easy to 

if you want to correct someone, correct scott chacon. he said it, not 


Markdown-Discuss mailing list
Markdown-Discuss <at>
Sean Leonard | 24 Oct 21:46 2014

Using fragment identifiers with Markdown docs

Hi Markdown folks:

I wanted to see if people have feelings or opinions about using fragment 
identifiers with Markdown (and Markdown-derivative, such as pandoc, 
kramdown, etc.) content.

It is useful to say things like

So that a Markdown editor could scroll to the right content.

To my mind, the prime candidates for this treatment are the [link 
reference identifiers][lref] and for some formats, the attributed text 
{#blahblah }. Link reference identifiers are part of the original 
Markdown syntax. On the other hand, they don't produce any identifiers 
in HTML/XHTML. Clearly attributed text is useful to identify both 
Markdown and output regions.



mofo syne | 24 Oct 10:25 2014

markdown for speech synthesis?

Have anyone ever considered the possibility of using markdown to
perform speech synthesis markups?

Just a thought:

There is already a speech synthesis markup language call SSML:

However I do wonder if there is a need to perhaps consider what a
markdownish speech synthesis markup language may look like. I don't
think you can exactly use markdown syntax to do speech synth. Take for
example sarcasm, you can't exactly do it in pure text markup.

So far what I can think of:

* `...` :-- indicates pause in speech
* `*` :-- can be used to ephasis words in speech
* `\<switch>` :-- at end of the line indicates how entire sentence
should be carried out
 * `You must reallly love to be a good guy /s`
* `"scare quotes"` :-- Or maybe sarcasm is better done as scare quotes
`"` around the sarcastic expression?
* `:D` :-- emotion icons can perhaps be used to indicate previous
statement should be carried out in a certain tone. e.g. ` This really
doesn't make me feel good D: `
* `--> #id <--` :-- Allows the speaker to 'point' to a particular
section in a page?

What is your thoughts on this? If this can be included alongside or
inline with a markdown page, it might have some useful applications,
like say a modifiable automatic lecturer.


Here's a link to the current discussion page:

just announced

this was just announced, from
the folks who do


in a related note, i have finished
my "beyond markdown" series...
> <at> bbirdiman/beyond-markdown-part-11-444393af1ed0

i put up a web-app as a playground.

Sean Leonard | 18 Oct 01:35 2014

New Version Notification for draft-ietf-appsawg-text-markdown-03.txt

And here is the other.


From: internet-drafts <at>
Subject: New Version Notification for draft-ietf-appsawg-text-markdown-03.txt
Date: October 17, 2014 at 4:33:52 PM PDT

A new version of I-D, draft-ietf-appsawg-text-markdown-03.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-ietf-appsawg-text-markdown
Revision:	03
Title:		The text/markdown Media Type
Document date:	2014-10-17
Group:		appsawg
Pages:		22

  This document registers the text/markdown media type for use with
  Markdown, a family of plain text formatting syntaxes that optionally
  can be converted to formal markup languages such as HTML.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

The IETF Secretariat