markdown conversions

Bowerbird at aol.com Bowerbird at aol.com
Thu Jun 23 17:29:38 EDT 2011


alan said:

> I think I am in agreement,

> if by "isn't necessary" you mean to say that

> simply providing more features to Markdown

> doesn't force end users to use them,

> or even really know they exist.


except that wasn't what i meant.

i mean that it's not necessary to trade simplicity
in order to get the power of additional features...

indeed, i believe that -- in the purview of a system
whose chief asset is its simplicity -- that would be
a bad trade. and, as i've read gruber, so would he;
he is an admirer of the grace apple brings to bear.



> I know I am firmly on the side of "this stuff --

> footnotes, DLLs, fenced code, attributes on headers,

> automatic TOC -- is useful, and sensibly implemented

> in the Markdown plain-text spirit, and thus good," myself.


i am all in favor of all of those more-powerful features.

i just don't believe it's necessary to give up _simplicity_
in order to get them. you might have to sacrifice some
_customizability_, but that's an acceptable trade, for me.

at one point, i was ready to discuss a range of stuff that
could reduce the complexity of markdown variants, but
nobody else seemed interested in having that discussion.
so the moment passed. and i'm not inclined to do it now.

but, just as one for-instance, "markdown extra" lets you
assign an i.d. attribute to a header, by adding it like this:

> ## Header 2 ## {#header2}


the extra power that this gives users is undeniable, and
much-needed. but that convention is just an ugly hack.
it's extra work, and it's error-prone, plus it looks awful.
why wouldn't/shouldn't an i.d. be assigned automatically?

so other variants, such as "multimarkdown", do just that.
but, even in its own user-manual, it gets itself confused,
with multiple headers being auto-assigned the same i.d.:


> id="advanced"

> id="basic"

> id="bibtex"

> id="compiling"

> id="footnotes"

> id="images"

> id="rawhtml"


pandoc checks for such duplicates, and appends a suffix
(-1, -2, etc.) to assure that each one has a unique value...
that's an ok solution, except that it makes it difficult to
know what the i.d. is for any specific header because you
have no idea whether it required an appendage, or not...

i myself, with z.m.l., simply require that each header be
unique to begin with, thus avoiding that potential glitch.
and i assign an i.d. to each paragraph, because... why not?

that's how you give the user more power _without_ adding
more complexity. (or gumming up the file with any crap.)

-bowerbird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110623/0962d32a/attachment.html>


More information about the Markdown-Discuss mailing list