Markdown Extra Spec: Parsing Section

Michel Fortin michel.fortin at
Tue May 13 00:18:00 EDT 2008

Le 2008-05-12 à 21:55, John MacFarlane a écrit :

>>> I am assuming that there will be a different type to deal with link

>>> text.


>> There will.


> Is there any good reason for having two different types here?

The link text can contain other span-level elements, such as emphasis,
code blocks, etc. This *has* to be taken into account while parsing.
On the other hand, text in the reference part is just plain text.

> As far as

> I can see, allowing anything that can serve as link text to be a

> refname

> would not contradict anything in the official Markdown syntax

> specification. In addition, it is hard to imagine a realistic case

> where

> allowing brackets and newlines in refnames would break an existing

> document. Why make users remember extra restrictions? (I didn't even

> know about them until a few days ago, and I've used markdown for

> years.)

> And why expose users to the risk that their documents will break if

> they

> hard-wrap a long refname?

I'm in favor of allowing hard-wrapped reference names where the line
break is not significant, so that will probably end up in the spec
when I write the part about parsing the link span element.

Please keep in mind that the current refname construct is for the
reference name in link definitions, and may be different from the one
used in the link span element.

> I think the current behavior of phpmarkdown and is very

> confusing. This produces a link:


> [[hi]][]


> [[hi]]: /url


> But this doesn't produce a link:


> [hello][[hi]]


> [[hi]]: /url


> So either (a) not all link references begin with a refname, or (b)

> refnames can sometimes (but not always!) contain embedded brackets.

> Either option would conflict with Michel's syntax specification

> as it now stands.

This situation is indeed inconsistant. I'd be in favor of allowing
balanced square brakets in link reference, even though John Gruber
seems (or seemed in 2006) to think they should be disallowed completely.

Michel Fortin
michel.fortin at

More information about the Markdown-Discuss mailing list