Getting around div tags

John Gruber gruber at
Sun Mar 21 13:59:00 EST 2004

Fletcher T.Penney <fletcher at> wrote on 03/20/04 at 6:40p:

> I am new to Markdown, [...]

Well, there are only around 5 people who aren't.  :^)

> I was sort of disappointed to see the posts looking at how to start 
> adding id and class tags to div's, etc, as this begins to approach 
> simply being another way of entering standard XHTML data.  Why not just 
> learn XHTML?

Allow me to emphasize that I agree with your general sentiment.
Markdown's syntax is, I assure you, very nearly complete. It's not
like 1.0 is the start, and it's going to grow new features every few
weeks and eventually double in size.

> I agree that adding optional support for some occasional "advanced" 
> features can be a good thing, but I wonder how adding a 
> {:left-centered} tag fits in with the principal that Markdown formatted 
> text should be readable in plain text and look "normal"....  I don't 
> normally see such {:left-centered} tags in any every day documents that 
> I read...  

Completely true. My proposal for adding the ability to specify
classes and id's is, admittedly, in violation of the First Rule of

The reason I think it might be worth making an exception is that
it'd be so frigging useful. For example, look at the source to
Markdown's Syntax docs:

I had to use HTML header tags because I wanted to assign id's to
each sub-head, so that individual sections could be linked to
directly. E.g.:


What I want to be able to do is write that header like this:

    ### Headers                                     {#header}

instead of:

    <h3 id="header">Headers</h3>

I'm willing to justify breaking the First Rule for this on the
grounds that:

*   Doing so would make the document so much easier to read
*   With just this one new rule, it would add unlimited flexibility
    with regard to assigning CSS to individual paragraphs and headers.

Also. It's not a syntax that is likely to occur accidentally, and so
most Markdown users can safely ignore it.

> I imagine that if Markdown gets too far away from this idiom 
> that many people will migrate to the next tool that rises up and tries 
> to stick more closely to a pure  implementation of that idiom.

I truly believe that bloat is the only danger facing Markdown. Which
is why I'm going to end up saying "no" to some feature suggestions
even though they're pretty good.

I'm glad that you and others seems to agree with this. Hopefully
you'll agree with me on the few areas where I'd still like to see it


More information about the Markdown-discuss mailing list