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,
(Continue reading)


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
(Continue reading)

Sean Leonard | 18 Oct 01:33 2014

New Version Notification for draft-seantek-text-markdown-use-cases-00.txt

Here is one.

From: internet-drafts <at>
Subject: New Version Notification for draft-seantek-text-markdown-use-cases-00.txt
Date: October 17, 2014 at 4:21:21 PM PDT

A new version of I-D, draft-seantek-text-markdown-use-cases-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-text-markdown-use-cases
Revision:	00
Title:		text/markdown Use Cases
Document date:	2014-10-17
Group:		Individual Submission
Pages:		20

 This document elaborates upon 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.
 Background information, local storage strategies, and additional
 syntax registrations are supplied.

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

Sean Leonard | 18 Oct 01:31 2014

text/markdown draft-03 guide (and use-cases-00 guide)

Hello Markdown World:

The following Internet-Drafts are about to be posted:


As discussed in apps-discuss <at> to make the drafts shorter yet more informative, I split them in
two. The secondary document has seven additional syntax registrations, background information, and
preservation strategies. The main registration document registers the media type. They are meant to be
read together; however, the secondary document makes no normative statements (no RFC 2119 key words).

  1. Introduction
  2. Markdown Media Type Registration Application
  3.  Optional Parameters
    3.1. syntax
    3.2. output-type
  4. Fragment Identifiers
  5.  Example

1. (Introduction)
    1.1. On Formats
    1.2. Markdown Design Philosophy
    1.3. Uses of Markdown
    1.4. Uses of Labeling Markdown Content as text/markdown
  2.  Strategies for Preserving Media Type and Parameters
  3.  Registration Templates for Common Markdown Syntaxes
    3.1. MultiMarkdown
(Continue reading)

Sean Leonard | 10 Oct 17:56 2014

(text/markdown) link label vs. link identifier and last-one-wins

In working on the text/markdown spec, I am making a reference to the syntax of links, specifically the things [1] and [Google] used in this construct:

Hello I am some [Markdown][1] and I use [Google][].

[Google]: "This is Google"

What is the common Markdown way of identifying this syntax element?

stmd (CommonMark) consistently calls it the "link label". (To be clear, it also calls [Markdown] a link label, even though that element does not have the same behavior as [1].)

However, [Markdown Syntax][MDSYNTAX] refers to it once as a "link identifier" in the bullet point: "Square brackets containing the link identifier (optionally indented from the left margin using up to three spaces)". Elsewhere it refers to it as a label. For example: "Reference-style links use a second set of square brackets, inside which you place a label of your choosing to identify the link" and "Then, anywhere in the document, you define your link label like this, on a line by itself".

I reviewed, which consistently uses the variable name $link_id (see also $g_urls, and comments such as # Link defs are in the form: ^[id]: url "optional title").

On this basis, I am going to call it "link identifier". Questions?

Also, seems to define last-wins behavior: the last link definition is indexed as the definition in $g_urls. (See _StripLinkDefinitions.) Older ones get overwritten by newer ones. Is this common or normative behavior? How do other implementations do it?

It's important that I keep the original reference list short; I would rather not refer normatively to documents other than Gruber's own Markdown rules.


Markdown-Discuss mailing list
Markdown-Discuss <at>

maybe we should discuss it

in terms of my last post here:


i was intrigued to see this today:


this mirrors earlier flipboard tech:


p.s.  by now, you might have figured out that
you can search twitter for "beyond markdown".
mofo syne | 4 Oct 05:34 2014

Sub reddit for general discussion on lightweight markup languages

If anybody is a reddit user, let me know, I might need a few moderators.

Might want to also update the sidebar with useful information.

let us not discuss that here

ubi said:
>   shouldn't this be moved to some other mailing list?

i sent only one notification, of the series, and
that was because i did not want to be seen as
"dissing markdown" without giving a fair notice.

and, for the record, i'm _not_ "dissing markdown".

i'm doing what john gruber has always suggested,
which is to make my own thing, with its own name.

and, just for the record once again, i didn't need his
instruction or permission to do that, because i was
working on z.m.l. for many years before markdown.

and i've continued to work on my system long after
he pushed markdown out of his nest to make it fly.


>   I guess Markdown purists (is there such a thing?)
>   may be annoyed.

if markdown purists want to be annoyed at something,
i'd suggest they read my medium article from last year:

>   markdown considered harmful
> <at> bbirdiman/markdown-considered-harmful-495ccfe24a52

that article is eminently fair, but the internet knows that
has never stopped some people from being "annoyed".


i don't want to discuss any of the specifics of my system
on this listserve, for various reasons, but i think i must
correct a few misimpressions from the feedback here.

>   I don't know how I feel
>   about having to add a ">"
>   (which by your convention is
>   a placeholder for [space]>[space])
>   for every line.

you don't have to put a " > " on every line;
putting it on the first line will be sufficient...
thanks for showing me i should've said that.

>   what if the block-quote text is not poetry?

z.m.l. offers two different block-quote tags:
one retains the linebreaks, the other doesn't.

even in the form where lines are rewrapped,
there is a way to specify a specific linebreak
should be retained. (it is the method that is
used across the whole of z.m.l., so i didn't
want to discuss it there in that one context;
i will discuss it as a general rule, later on.
but thanks for showing me it is confusing.)


mofo said:
>   I do wonder if people would be willing to
>   use the [space][tag][space] system though.
>   E.g. when typing '>', will I be willing to
>   tolerate having to add an extra space?
>   Will be interesting to see how tolerable it is.

um, ok.  if that is my biggest problem, i'll have
huge problems and no problems, simultaneously.

>   Also what is a chunk anyway?

>   beyond markdown -- part 2 -- z.m.l. is built to be easy to 
> <at> bbirdiman/beyond-markdown-part-2-b3527d2b9dcf

any set of non-blank lines bordered by blank lines
is a chunk. (though there will be a future wrinkle,
in that there'll be occurrence of "empty" chunks,
a result of splitting the file on double-linebreaks.)

>   Does that include header?

most definitely.

headers will be fully discussed in part 4 or part 5.

>   I might find having to do that space thing
>   to be annoying for headers

you always have the comfort of markdown as a fallback.


ok, now let us not discuss this any more here...


money for mou

interesting to see if there is any demand: