Optional features (was: Markdown Extra Specification (First Draft))

Michel Fortin michel.fortin at michelf.com
Thu May 22 22:33:45 EDT 2008

Le 2008-05-22 à 2:10, Aristotle Pagaltzis a écrit :

> It is, mind, perfectly fine to have two (or maybe three?) specs

> of which one is a superset of the other, as seems to be Michel’s

> current thrust with Markdown vs Markdown Extra. Assuming that no

> feature in either spec is optional, that means you would be able

> to expect Markdown Extra documents to work in all Markdown Extra

> processors, and all Markdown documents to work in all Markdown

> and Markdown Extra processors. The scope of the problem is much

> smaller in such a scenario, enough so to be perfectly tractable.

I perfectly agree with this by the way: optional features should be
kept to a minimum. It may be interesting to note there are currently
two configurable parsing-related[^1] in PHP Markdown:

Tab width (default = 4)

: This one comes from a similar configuration option in

Markdown.pl and is essentially the size in spaces for one
indent through a Markdown document. When John Gruber says
"four spaces or one tab" in his syntax description document,
he really means "<tab-width> spaces or one tab", where
tab-width is a configurable parameter defaulting to 4.

I'm not aware of anyone changing this parameter, and I'm not
even sure of how well it works, but it is clear that changing
this will break many documents written with a different tab
width in mind.

No markup (default = false)
No entities (default = false)

: This one prevents the parser from skipping over HTML tags

and/or HTML character entities. I was originally opposed to
it, and in some way I still am. I decided to add it because
there was too much people attempting to disable HTML by
preprocessing the input with strip_tags or a substitution
regular expression without realizing they were breaking
automatic links, code spans and code blocks with HTML in
them, and sometimes blockquotes.

I'm no fan of this mode, but I feel it was the best way to
avoid people breaking the syntax by accident, so I've added
it in.

I'm not sure those "features" should be formally part of the spec. I
believe however that if the spec is well written it should be pretty
trivial to see what must be changed to achieve them.

A "parsing-related setting" is a setting that changes the
interpretation of the document given in output. The oposite
is an "output-related setting", which changes the HTML
output but does not affect the interpretation the parser
makes of the document.

Michel Fortin
michel.fortin at michelf.com

More information about the Markdown-Discuss mailing list