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


_______________________________________________
Markdown-Discuss mailing list
Markdown-Discuss@six.pairlist.net
http://six.pairlist.net/mailman/listinfo/markdown-discuss

Reply via email to