Custom Block Syntax

[mcarmosi]

Markdown is close to being really good for writing math on the web. One issue remains; we need (at least) the following "block" environments, with labels to refer back to them:

• Theorem
• Lemma
• Proof
• Corollary
• Definition

These are, basically, the standard amsthm environments, and they are completely indispensable for writing mathematics. My desired output is shown below. Basically, emit a div where the optional "title" is the display title of the theorem, the optional "id" acts an an anchor for references and the "class" is an abbreviation for the block type (or the full block type, it doesn't really matter).

    <div class="thm" id="#primeNum" title="Many Prime Numbers">
    There are infinitely many prime numbers. 
    </div>

I don't know if this is the "right" desired output according to markdown philosophy. Currently I use JavaScript to auto-number and style these environments, inserting a heading and number directly into the DOM. It seems like real markdown might emit static HTML for the theorem environment title, number, and heading, with appropriate CSS classes for styling these elements. Or the CSS counter feature could be used to number theorems, but the title would at least be in the static HTML if present.

My proposal for the markdown syntax that emits these is to copy Madoko Custom Block Syntax, but extend it with an ability to specify the title of the block environment, which I don't think they have. The syntax would be:

~ <BlockType> <"Optional Title for Block"> <[ Optional label for block ]>
Block Content goes here.
~

For example:

 ~ Lemma "Left Cosets Lemma" [LeftCosetLemma]
Let $H$ be a subgroup of a group $G$, and let $x$ and 
$y$ be elements of $G$.  Suppose that $xH \cap yH$ is 
non-empty. Then $xH = yH$.
~

The meaning of mathematics is very hard to get across without these named block environments, which carefully offset important formal statements from the rest of the text. Lemmas, Theorems, and Proofs are not aesthetics, they are specific structural features of a text, just as important to mathematics as code blocks are to discussing programming. This is why I think these blocks should be supported by multimarkdown.

[fletcher]

I understand that this is very important to mathematicians, but hopefully you can also understand why this is not important to everyone else.

I try to limit features in MMD to those with a chance of being useful to a wide range of users, rather than those are only useful to a small subset.

I am not currently a fan of the syntaxes used in a few Markdown variants to assign classes to paragraphs or blocks. There may come a time when I decide to implement something like that, which could then of course be "hijacked" to support Lemmas, Theorems, and Proofs as needed.

Otherwise this would be the sort of thing that could be implemented in a "math-oriented" fork of MMD for the time being.

[mcarmosi]

I completely understand your lack of interest. Mathematicians and theoretical computer scientists are a tiny fraction of the population, so the chance of this feature being useful to any given user is near-zero.

Would you mind describing what you don't like about the Markdown variant syntaxes that assign classes to paragraphs or blocks? I am going to try and fork MMD to add math environments and I'd like to avoid what you don't like about the block-class syntax of other Markdown variants. I also do not like them -- I don't even like my suggestion above very much -- but I can't put my finger on what is wrong.

[fletcher]

My objection is also somewhat vague.

Markdown was fairly.... "elegant". It was simple. The syntax for apply a CSS div to plain text just seems out of place. It violates the overriding design goal expressed by Gruber:

The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

I understand the utility of the feature, but object to visuals of it. I'm open to considering something like this, but it would have to be unobtrusive when viewed in the raw source.

If you have any ideas, please share them!! ;)