div & span support

Jacob Rus jrus at hcs.harvard.edu
Mon Mar 5 03:49:43 EST 2007

Andrea Censi wrote:

> On 3/5/07, Richard Taytor <dick at gutz.com> wrote:

>>> [John Fraser:] Being able to wrap Markdown text in divs and spans ...

>> I find div and span tags quite useful. Here is an example of the syntax I'm presently using.


>> [[ {#orchard}

>> Contents of div here. And ~this{.plum}~ is how I do spans.

>> ]]


> I also need DIVs and I will implement them in Maruku.


> I will be glad to hear suggestions for the syntax.


> Here is another hypothesis:


> +================ {#id}


> nested div:


> +========================

> inside nested DIV

> -========================


> -==============


> I like the fact that the line of `=` separates well the DIV's content

> from the rest of the document.

I don't mean to spoil the party, but IMO these are all non-solutions to
a non-problem, which make the markup significantly uglier than it was

The nice thing about Markdown is that it *doesn't try* to map exactly to
HTML, but instead tries to map to the parts people need when *writing*.
Notice: *writing is not the same as html*. None of these divs or
spans is necessary in a plain text format, such as conventional plain
email, or rfc writing style. Now sure, when you're making a complex web
page, it's nice to have all sorts of complex tags. But that's not the
same as the writing content, and IMO it should be separated.

Let me mirror JG: if you want to make complex html tags, just use bloody
html! Let's not invent another (equally complex) syntax for it; it's a
solved problem (the w3c didn't create the best solution ever, but it's
not too bad), and we're just making matters worse by introducing our own
syntax in this case.

Now, tables, notes, definition lists, and inline formulas are another
matter. For this reason, I think it would be neat to have some sort of
more general extension mechanism. But that's a discussion for another day.

In general, I don't think it helps the basic markdown format for us to
add features just because we can. Especially not features that are only
relevant in the context of html documents, add not inconsiderable
complexity to the appearance of the text, and through their inclusion
limit the future use of similar syntax for more useful purposes.

More information about the Markdown-Discuss mailing list