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

[Michel Fortin]

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.

[^1]:
     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
http://michelf.com/