Markdown extensions
Richard Taytor
dick at gutz.com
Wed Jul 4 19:41:06 EDT 2007
In addition to the Markdown extensions/modifications of [Markdown Extra][] and [Pandoc][], I find these following to be of essential utility and I post them here for the interest of others wishing to extend Markdown, and to cultivate coherent common syntax. I invite comment/criticism regarding the nature of these extensions in form and function; however, I wish to avoid debate of the question of their fundamental utility/necessity.
1. element attributes
2. div & span
3. alternative headings
### element attributes (the attribute list)
example: `{#id .class name="value"}`
- the attribute list may contain (in any order):
- zero or one: #id
- one or more: .class, name="value" (name/value pairs may be written without quotes if the value contains no whitespace)
- for all elements, the attribute list:
- may appear either before or after the element contents
- *must* appear within element delimiters[^1]
- *special case*, for links and images:
- may appear inside the parentheses (with the other attributes: href and title), or in the definition for reference-style links
- for block elements, the attribute list:
- may appear on its own line, adjacent to the block (separated by a single newline)
### div
example:
[[[
Div contents here...
]]]
- three or more [ and ] indicate open and close div tags (respectively)
- whitespace between div contents and markers may be omitted
### span
example: `spans are {use}ful`
- a primary advantage of span syntax is to attach an attribute list (though it can be useful without one as well)
- it may seem odd to use braces (too similar to the attribute list) but nesting is disambiguated (when the open and close markers are different)
### alternative headings (two kinds)
example: `###2 heading text`
- this syntax is identical to that of "unclosed" atx, except:
- one or more # may be used (to augment or diminish visual emphasis as desired, in the source text) with no effect on rendered output
- the # string *must* be followed by the heading level (1-6), and one or more space/tab
example: `#.1.3.12 heading text`
- same as above except
- the # string *must* be followed by a period, one or more integers separated by periods, and one or more space/tab
- the count of periods corresponds to the heading level
- the numeric string (integers separated by periods) is included in the heading (without the leading period)
[^1]: Of course, if the location of the attribute list is restricted (only before, or only after), then it may appear outside the element delimiters. For some reason, this seems to be a point of contention. I believe that a syntax extension of *natural* language should minimise restriction of the author (in the case of natural language, [TMTOWTDI][]).
Some reasons to keep the attribute list inside element delimiters:
- permits inclusion of whitespace around the attribute list (to make the source text more readable)
- increases consistency
for links/images, this locates the attribute list with the other element attributes (href and title)
like this: `[text](href "title" {attr})`
not this: `[text](href "title"){attr}`
- reduces ambiguity
`### [heading](href) {attr}`
is very similar but potentially quite different (the difference should be more obvious in the syntax) to
`### [heading](href){attr}`
- easy to parse
Some reasons to let the attribute list appear before *or* after element contents:
- to augment or diminish visual emphasis as desired, in the source text
- to make the source text more readable
- example: for adjacent inline elements, the attribute lists may be arranged to make the source text more readable
like this: `Inevitably, *{attr}Mark**down{attr}* will evolve, and/or fork.`
not this: `Inevitably, *Mark*{attr}*down*{attr} will evolve, and/or fork.`
- I see no compelling reason not to do this
[Markdown Extra]: http://www.michelf.com/projects/php-markdown/extra/
[Pandoc]: http://sophos.berkeley.edu/macfarlane/pandoc/README.html
[TMTOWTDI]: http://en.wikipedia.org/wiki/TMTOWTDI
More information about the Markdown-Discuss
mailing list