radiantcms-couchrest_model 0.1.3 → 0.1.4

data/vendor/extensions/markdown_filter/vendor/kramdown/doc/syntax.page

@@ -0,0 +1,1521 @@
+---
+title: Syntax
+in_menu: true
+sort_info: 10
+--- name:sidebar
+<h1>Contents</h1>
+
+{menu: {used_nodes: fragments, min_levels: 4, max_levels: 6}}
+--- name:content
+
+# kramdown Syntax
+
+This is version **<%= ::Kramdown::VERSION %>** of the syntax documentation.
+
+The kramdown syntax is based on the Markdown syntax and has been enhanced with features that are
+found in other Markdown implementations like [Maruku], [PHP Markdown Extra] and [Pandoc]. However,
+it strives to provide a strict syntax with definite rules and therefore isn't completely compatible
+with Markdown. Nonetheless, most Markdown documents should work fine when parsed with kramdown. All
+places where the kramdown syntax differs from the Markdown syntax are highlighted.
+
+Following is the complete syntax definition for all elements kramdown supports. Together with the
+documentation on the available converters, it is clearly specified what you will get when a kramdown
+document is converted.
+
+
+## Source Text Formatting
+
+A kramdown document may be in any encoding, for example ASCII, UTF-8 or ISO-8859-1, and the output
+will have the same encoding as the source. The document consists of two types of elements, block
+level elements and span level elements:
+
+* Block level elements define the main structure of the content, for example, what part of the text
+  should be a paragraph, a list, a blockquote and so on.
+
+* Span level elements mark up small text parts as, for example, emphasized text or a link.
+
+Thus span level elements can only occur inside block level elements or other span level elements.
+
+You will often find references to the "first column" or "first character" of a line in a block level
+element descriptions. Such a reference is always to be taken relative to the current indentation
+level because some block level elements open up a new indentation level (e.g. blockquotes). The
+beginning of a kramdown document opens up the default indentation level which begins at the first
+column of the text.
+
+
+### Usage of Tabs
+
+kramdown assumes that tab stops are set at multiples of four. This is especially important when
+using tabs for indentation in lists. Also, tabs may only be used at the beginning of a line when
+indenting text and must not be preceded by spaces. Otherwise the results may be unexpected.
+
+
+### Automatic and Manual Escaping
+
+Depending on the output format, there are often characters that need special treatment. For example,
+when converting a kramdown document to HTML one needs to take care of the characters `<`, `>` and
+`&`. To ease working with these special characters, they are automatically and correctly escaped
+depending on the output format.
+
+This means, for example, that you can just use `<`, `>` and `&` in a kramdown document and need not
+think about when to use their HTML entity counterparts. However, if you *do use* HTML entitys or
+HTML tags which use one of the characters, the result will be correct nonetheless!
+
+Since kramdown also uses some characters to mark-up the text, there needs to be a way to escape
+these special characters so that they can have their normal meaning. This can be done by using
+backslash escapes. For example, you can use a literal backtick like this:
+
+    This \`is not a code\` span!
+
+Following is a list of all the characters (character sequences) that can be escaped:
+
+    \         backslash
+    .         period
+    *         asterisk
+    _         underscore
+    +         plus
+    -         minus
+    `         backtick
+    ()[]{}    left and right parens/brackets/braces
+    #         hash
+    !         bang
+    <<        left guillemet
+    >>        right guillemet
+    :         colon
+    |         pipe
+    "         double quote
+    '         single quote
+    $         dollar sign
+
+
+# Structural Elements
+
+All structural elements are block level elements and they are used to structure the content. They
+can mark up some text as, for example, a simple paragraph, a quote or as a list item.
+
+
+## Blank lines
+
+Any line that just contains white space characters such as spaces and tabs is considered a blank
+line by kramdown. One or more consecutive blank lines are handled as one empty blank line. Blank
+lines are mostly used to visually separate block level elements from each other and in this case
+they don't have semantic meaning. However, there are some cases where blank lines do have a semantic
+meaning:
+
+* When used in paragraphs -- see the [paragraphs section](#paragraphs)
+* When used in headers -- see the [headers section](#headers)
+* When used in lists -- see the [lists section](#lists)
+
+
+## Paragraphs
+
+Paragraphs are the most used block level elements. One or more consecutive lines of text are
+interpreted as one paragraph. Every line of a paragraph may be indented up to three spaces. You can
+separate two consecutive paragraphs from each other by using one or more blank lines. Notice that a
+line break in the source does not mean a line break in the output! If you want to have an explicit
+line break (i.e. a `<br />` tag) you need to end a line with two or more spaces or two backslashes!
+Note, however, that a line break on the last text line of a paragraph is not possible and will be
+ignored. Leading and trailing spaces will be stripped from the paragraph text.
+
+The following gives you an example of how paragraphs look like:
+
+    This para line starts at the first column. However,
+       the lines can be indented up to three spaces.
+    The para continues here.
+
+      This is another paragraph, not connected to the above one. But  
+    with a hard line break. \\
+    And another one.
+{: .show-whitespaces .ws-lr}
+
+
+## Headers
+
+kramdown supports so called Setext style and atx style headers. Both forms can be used inside a
+single document.
+
+### Setext Style
+
+Setext style headers are specified by a [blank line](#blank-lines) (except at the beginning of a
+document), followed by a line of text (the header text) and a line with only equal signs (for a
+first level header) or dashes (for a second level header). The header text may be indented up to
+three spaces but any leading or trailing spaces are stripped from the header text. The amount of
+equal signs or dashes is not significant, just one is enough but more may look better. The equal
+signs or dashes have to begin at the first column. For example:
+
+    First level header
+    ==================
+
+    Second level header
+    ------
+
+       Other first level header
+    =
+
+As mentioned you need to insert a blank line before (but not necessarily after) a Setext header:
+
+    This is a normal
+    paragraph.
+
+    And A Header
+    ------------
+    And a paragraph
+
+    > This is a blockquote.
+
+    And A Header
+    ------------
+
+However, it is generally a good idea to also use a blank line after a Setext header because it looks
+more appropriate.
+
+> The original Markdown syntax allows one to omit the blank line before a Setext header. However,
+> this leads to ambiguities and makes reading the document harder than necessary. Therefore it is
+> not allowed in a kramdown document.
+{: .markdown-difference}
+
+An edge case worth mentioning is the following:
+
+    header
+    ---
+    para
+
+One might ask if this represents two paragraphs separated by a [horizontal rule](#horizontal-rules)
+or a second level header and a paragraph. As suggested by the wording in the example, the latter is
+the case. The general rule is that Setext headers are processed before horizontal rules.
+
+### atx Style
+
+atx style headers are specified by a [blank line](#blank-lines) (except at the beginning of a
+document), followed by a line with one or more hash characters and then the header text. No spaces
+are allowed before the hash characters. The number of hash characters specifies the heading level:
+one hash character gives you a first level heading, two a second level heading and so on until the
+maximum of six hash characters for a sixth level heading. You may optionally use any number of
+hashes at the end of the line to close the header. Any leading or trailing spaces are stripped from
+the header text. For example:
+
+    # First level header
+
+    ### Third level header    ###
+
+    ## Second level header ######
+
+> Again, the original Markdown syntax allows one to omit the blank line before an atx style header.
+{: .markdown-difference}
+
+
+### Specifying a Header ID
+
+kramdown supports a nice way for explicitly setting the header ID which is taken from [PHP Markdown
+Extra] and [Maruku]: If you follow the header text with an opening curly bracket (separated from the
+text with a least one space), a hash, the ID and a closing curly bracket, the ID is set on the
+header. If you use the trailing hash feature of atx style headers, the header ID has to go after the
+trailing hashes. For example:
+
+    Hello        {#id}
+    -----
+
+    # Hello      {#id}
+
+    # Hello #    {#id}
+
+> This additional syntax is not part of standard Markdown.
+{: .markdown-difference}
+
+
+## Blockquotes
+
+A blockquote is started using the `>` marker followed by an optional space and the content of the
+blockquote. The marker itself may be indented up to three spaces. All following lines that are also
+started with the blockquote marker belong to the blockquote. The contents of a blockquote are block
+level elements. This means that if you are just using text as content that it will be wrapped in a
+paragraph. For example, the following gives you one blockquote with two paragraphs in it:
+
+    > This is a blockquote.
+    >on multiple lines.
+    >
+    > This is the second paragraph.
+
+Since the contents of a blockquote are block level elements, you can nest blockquotes and use other
+block level elements:
+
+    > This is a paragraph.
+    > > A nested blockquote.
+    >
+    > ## Headers work
+    >
+    > * lists too
+    >
+    > and all other block level elements
+
+Note that the first space character after the `>` marker does *not* count when counting spaces for
+the indentation of the block level elements inside the blockquote! So [code blocks](#code-blocks)
+will have to be indented with five spaces or one space and one tab, like this:
+
+    > A code block:
+    >
+    >     ruby -e 'puts :works'
+
+> The original Markdown syntax allowed "lazy" blockquotes, i.e. blockquotes where only the first line
+> needs a blockquote marker. This is disallowed in kramdown, you always need to use a blockquote
+> marker! The rational behind this is that most email programs and good text editors put the `>`
+> maker automatically before every quoted line and that things like the following work like
+> expected:
+>
+>     > > This is some quoted text.
+>     > > Spanning multiple lines.
+>     > This is the answer to the quoted text above.
+>     This is just a normal paragraph, with the answer to the above.
+{: .markdown-difference}
+
+
+## Code Blocks
+
+Code blocks can be used to represent verbatim text like markup, HTML or a program fragment because
+no syntax is parsed within a code block.
+
+### Standard Code Block
+
+A code block can be started by using four spaces or one tab and then the text of the code block. All
+following lines that adhere to this syntax belong to the same code block. The indentation (four
+spaces or one tab) is stripped from the text. Note that blank lines don't separate consecutive code
+blocks:
+
+        Here comes some code
+
+        This text belongs to the same code block.
+
+If you want to have one code block directly after another one, you need to use an [EOB
+marker](#eob-marker) to separate the two:
+
+        Here comes some code
+    ^
+        This one is separate.
+
+### Fenced Code Block
+
+> This alternative syntax is not part of the original Markdown syntax. The idea and syntax comes
+> from the [PHP Markdown Extra] package.
+{: .markdown-difference}
+
+kramdown also supports an alternative syntax for code blocks which does not use indented blocks but
+delimiting lines. The starting line needs to begin with three or more tilde characters (`~`) and the
+closing line needs to have at least the number of tildes the starting line has. Everything between
+is taken literally as with the other syntax but there is no need for indenting the text. For
+example:
+
+    ~~~~~~~~
+    Here comes some code.
+    ~~~~~~~~
+
+If you need lines of tildes in such a code block, just start the code block with more tildes. For
+example:
+
+    ~~~~~~~~~~~~
+    ~~~~~~~
+    code with tildes
+    ~~~~~~~~
+    ~~~~~~~~~~~~~~~~~~
+
+This type of code block is especially useful for copy-pasted code since you don't need to indent the
+code.
+
+
+## Lists
+
+kramdown provides syntax elements for creating ordered and unordered lists as well as definition
+lists.
+
+### Ordered and Unordered lists
+
+Both ordered and unordered lists follow the same rules.
+
+A list is started with a list marker (in case of unordered lists one of `+`, `-` or `*` -- you can
+mix them -- and in case of ordered lists a number followed by a period) followed by one tab or at
+least one space, optionally followed by an [IAL](#inline-attribute-lists) that should be applied to
+the list item and then the first part of the content of the list item. The leading tabs or spaces
+are stripped away from this first line of content to allow for a nice alignment with the following
+content of a list item (see below). All following list items with the same marker type (unordered or
+ordered) are put into the same list. The numbers used for ordered lists are irrelevant, an ordered
+list always starts at 1.
+
+The following gives you an unordered list and an ordered list:
+
+    * kram
+    + down
+    - now
+
+    1. kram
+    2. down
+    3. now
+
+> The original Markdown syntax allows the markers of ordered and unordered lists to be mixed, the
+> first marker specifying the list type (ordered or unordered). This is not allowed in kramdown. As
+> stated, the above example will give you two lists (an unordered and an ordered) in kramdown and
+> only one unordered list in Markdown.
+{: .markdown-difference}
+
+The first list marker in a list may be indented up to three spaces. The column number of the first
+non-space character which appears after the list item marker on the same line specifies the
+indentation that has to be used for the following lines of content of the list item. If there is no
+such character, the indentation that needs to be used is four spaces or one tab. If a line does not
+have the needed amount of indentation, it is not treated as list item content. The indentation is
+stripped from the content and the content (note that the content naturally also contains the content
+of the line with the item marker) is processed as text containing block level elements. All other
+list markers in the list may be indented up to three spaces or the number of spaces used for the
+indentation of the last list item minus one, whichever number is smaller. For example:
+
+    * This is the first line. Since the first non-space characters appears in column 3, all other
+      lines have to be indented 2 spaces so that the first characters align. This tells kramdown
+      that the lines belong to the list item.
+    *       This is the another item of the list. It uses a different number of spaces for
+            indentation which is okay but should generally be avoided.
+       * The list item marker is indented 3 spaces which is allowed but should also be avoided.
+
+So, while the above is possible and creates one list with three items, it is not advised to use
+different (marker and list content) indents for same level list items!
+
+> The original Markdown syntax also allows you to indent the marker, however, the behaviour of what
+> happens with the list items is not clearly specified and may surprise you.
+>
+> Also, Markdown uses a fixed number of spaces/tabs to indent the lines that belong to a list item!
+{: .markdown-difference}
+
+When using tabs for indenting the content of a list item, remember that tab stops occur at multiples
+of four for kramdown. Tabs are correctly converted to spaces for calculating the indentation. For
+example:
+
+    *   Using a tab to indent this line, the tab only counts as three spaces and therefore the
+        overall indentation is four spaces.
+
+       1.   The tab after the marker counts here as two spaces. Since the indentation of the marker
+            is three spaces and the marker itself takes two characters, the overall indentation
+            needed for the following lines is eight spaces or two tabs.
+
+It is clear that you might get unexpected results if you mix tabs and spaces or if you don't have
+the tab stops set to multiples of four in your editor! Therefore this should be avoided!
+
+The content of a list item is made up of either text or block level elements. Simple list items only
+contain text like in the above examples. They are not even wrapped in a paragraph tag. If the first
+list text is followed by one or more blank lines, it will be wrapped in a paragraph tag:
+
+    * kram
+
+    * down
+    * now
+
+In the above example, the first list item text will be wrapped in a paragraph tag since it is
+followed by a blank line whereas the second list item contains just text. There is obviously a
+problem for doing this with the last list item when it contains only text. You can circumvent this
+by leaving a blank line after the last list item and using an EOB marker:
+
+    * Not wrapped in a paragraph
+    * Wrapped in a paragraph due to the following blank line.
+
+    * Also wrapped in a paragraph due to the
+      following blank line and the EOB marker.
+
+    ^
+
+The text of the last list item is also wrapped in a paragraph tag if *all* other list items contain
+a proper paragraph as first element. This makes the following use case work like expected, i.e.
+*all* the list items are wrapped in paragraphs:
+
+    * First list item
+
+    * Second list item
+
+    * Last list item
+
+> The original Markdown syntax page specifies that list items which are separated by one or more
+> blank lines are wrapped in paragraph tags. This means that the first text will also be wrapped in
+> a paragraph if you have block level elements in a list which are separated by blank lines. The
+> above rule is easy to remember and lets you exactly specify when the first list text should be
+> wrapped in a paragraph. The idea for the above rule comes from the [Pandoc] package.
+{: .markdown-difference}
+
+As seen in the examples above, blank lines between list items are allowed.
+
+Since the content of a list item can contain block level elements, you can do the following:
+
+    *   First item
+
+        A second paragraph
+
+        * nested list
+        > blockquote
+
+    *   Second item
+
+However, there is a problem when you want to have a code block immediately after a list item. You
+can use an EOB marker to circumvent this problem:
+
+    *   This is a list item.
+
+        The second para of the list item.
+    ^
+        A code block following the list item.
+
+You can have any block level element as first element in a list item. However, as described above,
+the leading tabs or spaces of the line with the list item marker are stripped away. This leads to a
+problem when you want to have a code block as first element. The solution to this problem is the
+following construct:
+
+    * 
+            This is a code block (indentation needs to be 4(1)+4(1) spaces (tabs)).
+{: .show-whitespaces .ws-lr}
+
+Note that the list marker needs to be followed with at least one space or tab! Otherwise the line is
+not recognized as the start of a list item but interpreted as a paragraph containing the list
+marker.
+
+> The original Markdown syntax allows you to be lazy when you just use text for a list item. So the
+> following is possible with Markdown:
+>
+>     * First list item
+>     continued here
+>     *   Second list item
+>       continued here.
+>
+> This kind of syntax is disallowed in kramdown.
+{: .markdown-difference}
+
+If you want to have one list directly after another one (both with the same list type, i.e. ordered
+or unordered), you need to use an EOB marker to separate the two:
+
+    * List one
+    ^
+    * List two
+
+It is possible that a line gets parsed as ordered or unordered list although it shouldn't. This
+would be the case in the following example:
+
+    I have read the book
+    1984. It was great
+    - others say that, too!
+
+Therefore you have to insert a blank line after a paragraph if you want to follow the paragraph with
+a list. The only exception to this rule is when you want to create a compact nested list, i.e. a
+list where the text is not wrapped in paragraphs:
+
+    *   This is just text.
+        * this is a sub list item
+          * this is a sub sub list item
+    * This is just text,
+        spanning two lines
+      * this is a nested list item.
+
+Another way to remedy the problem with the list item marker appearing in plain text is by escaping
+the period in an ordered list or the list item marker in an unordered list (this is especially
+useful when the paragraph starts with something looking like a list item marker):
+
+    1984\. It was great
+    \- others say that, too!
+
+As mentioned at the beginning, an optional IAL for applying attributes to a list item can be used
+after the list item marker:
+
+    * {:.cls} This item has the class "cls".
+      Here continues the above paragraph.
+
+    * This is a normal list item.
+
+
+### Definition Lists
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [PHP Markdown Extra] package.
+{: .markdown-difference}
+
+Definition lists allow you to assign one or more definitions to one or more terms.
+
+A definition list is started when a normal paragraph is followed by a line with a definition marker
+(a colon which may be optionally indented up to three spaces), then at least one tab or one space
+and then the first part of the definition. The line with the definition marker may optionally be
+separated from the preceding paragraph by a blank line. The leading tabs or spaces are stripped away
+from this first line of the definition to allow for a nice alignment with the following definition
+content. Each line of the preceding paragraph is taken to be a term and the lines separately parsed
+as span level elements.
+
+The following is a simple definition list:
+
+    kramdown
+    : A Markdown-superset converter
+
+    Maruku
+    :     Another Markdown-superset converter
+
+The column number of the first non-space character which appears after a definition marker on the
+same line specifies the indentation that has to be used for the following lines of the definition.
+If there is no such character, the indentation that needs to be used is four spaces or one tab. If
+one of the following lines does not have the needed amount of indentation, it is not treated as part
+of the definition. The indentation is stripped from the definition and it (note that the definition
+naturally also contains the content of the line with the definition marker) is processed as text
+containing block level elements. If there is more than one definition, all other definition markers
+for the term may be indented up to three spaces or the number of spaces used for the indentation of
+the last definition minus one, whichever number is smaller. For example:
+
+    definition term 1
+    definition term 2
+    : This is the first line. Since the first non-space characters appears in column 3, all other
+      lines have to be indented 2 spaces so that they first characters align. This tells kramdown
+      that the lines belong to the definition.
+    :       This is the another definition for the same term. It uses a different number of spaces
+            for indentation which is okay but should generally be avoided.
+       : The definition marker is indented 3 spaces which is allowed but should also be avoided.
+
+So, while the above is possible and creates a definition list with two terms and three definitions
+for them, it is not advised to use different (definition marker and definition) indents in the same
+definition list!
+
+The definition for a term is made up of text and/or block level elements. If a definition is *not*
+preceded by a blank line, the first part of the definition will just be text if it would be a
+paragraph otherwise:
+
+    definition term
+    : This definition will just be text because it would normally be a paragraph and the there is
+      no preceding blank line.
+
+      > although the definition contains other block level elements
+
+    : This definition *will* be a paragraph since it is preceded by a blank line.
+
+The rules about having any block level element as first element in a list item also apply to a
+definition.
+
+
+## Tables
+
+> This syntax feature is not part of the original Markdown syntax. The syntax is based on the one
+> from the [PHP Markdown Extra] package.
+{: .markdown-difference}
+
+Sometimes one wants to include simple tabular data in a kramdown document for which using a
+full-blown HTML table is just too much. kramdown supports this with a simple syntax for ASCII
+tables.
+
+There are three different text line types that can be used in a table:
+
+* *Table rows* define the content of a table.
+
+  A table row is started with a pipe character, optionally indented up to three spaces, and then the
+  text of the first table cell. Subsequent table cells consist of a pipe character followed by the
+  cell text. One may optionally use a pipe character at the the end of a table row line.
+
+  Header rows, footer rows and normal rows are all done using these table rows. Table cells can only
+  contain a single line of text, no multiline text is supported. The text of a table cell is parsed
+  as span level elements. Note that literal pipe characters need to be escaped, even if they occur
+  in code spans!
+
+  Here are some example table rows:
+
+      | First cell|Second cell|Third cell
+      | First | Second | Third |
+
+* *Separator lines* are used to split the table body into multiple body parts.
+
+  A separator line is started with a pipe or plus character, optionally indented up to three spaces,
+  followed by an optional space, an optional colon, a dash and then any number and combination of
+  pipes, dashes, pluses, colons and spaces. The pipe and plus characters can be used to visually
+  separate columns although this is not needed. Multiple separator lines after another are treated
+  as one separator line.
+
+  Here are some example separator lines:
+
+      |----+----|
+      +----|----+
+      |---------|
+      |-
+      | :-----: |
+
+* The first separator line after at least one table row is treated specially, namely as *header
+  separator line*. It is used to demarcate header rows from normal table rows and/or to set column
+  alignments. All table rows above the header separator line are considered to be header rows.
+
+  The header separator line can be specially formatted to contain column alignment definitions: An
+  alignment definition consists of an optional space followed by an optional colon, one or more
+  dashes, an optional colon and another optional space. The colons of an alignment definition are
+  used to set the alignment of a column: if there are no colons, the column uses the default
+  alignment, if there is a colon only before the dashes, the column is left aligned, if there are
+  colons before and after the dashes, the column is center aligned and if there is only a colon
+  after the dashes, the column is right aligned. Each alignment definition sets the alignment for
+  one column, the first alignment definition for the first column, the second alignment definition
+  for the second column and so on.
+
+  Here are some example header separator lines with alignment definitions:
+
+      |---+---+---|
+      + :-: |:------| ---:|
+      | :-: :- -: -
+
+* A *footer separator line* is used to demarcate footer rows from normal table rows. All table rows
+  below the footer separator line are considered to be footer rows.
+
+  A footer separator line is like a normal separator line except that dashes are replaced by equal
+  signs. A footer separator line may only appear once in a table. If multiple footer separator lines
+  are used in one table, only the last is treated as footer separator line, all others are treated
+  as normal separator lines. Normal separator lines that are used after the footer separator line
+  are ignored.
+
+  Here are some example footer separator lines:
+
+      |====+====|
+      +====|====+
+      |=========|
+      |=
+
+Trailing spaces or tabs are ignored in all cases. To simplify table creation and maintenance,
+header, footer and normal separator lines need not specify the same number of columns as table rows;
+even `|-` and `|=` are a valid separators.
+
+Given the above components, a table is specified by
+
+* an optional separator line,
+* optionally followed by zero, one or more table rows followed by a header separator line,
+* one or more table rows, optionally interspersed with separator lines,
+* optionally followed by a footer separator line and zero, one or more table rows and
+* an optional trailing separator line.
+
+> The table syntax differs from the one used in [PHP Markdown Extra] as follows:
+>
+> * kramdown tables have to begin with a pipe character, this is optional in [PHP Markdown Extra].
+> * kramdown tables do not need to have a table header.
+> * kramdown tables can be structured using separator lines.
+> * kramdown tables can contain a table footer.
+{: .markdown-difference}
+
+Here is an example for a kramdown table with a table header row, two table bodies and a table footer
+row:
+
+    |-----------------+------------+-----------------+----------------|
+    | Default aligned |Left aligned| Center aligned  | Right aligned  |
+    |-----------------|:-----------|:---------------:|---------------:|
+    | First body part |Second cell | Third cell      | fourth cell    |
+    | Second line     |foo         | **strong**      | baz            |
+    | Third line      |quux        | baz             | bar            |
+    |-----------------+------------+-----------------+----------------|
+    | Second body     |            |                 |                |
+    | 2 line          |            |                 |                |
+    |=================+============+=================+================|
+    | Footer row      |            |                 |                |
+    |-----------------+------------+-----------------+----------------|
+
+The above example table is rather time-consuming to create without the help of an ASCII table
+editor. However, the table syntax is flexible and the above table could also be written like this:
+
+    |---
+    | Default aligned | Left aligned | Center aligned | Right aligned
+    |-|:-|:-:|-:
+    | First body part | Second cell | Third cell | fourth cell
+    | Second line |foo | **strong** | baz
+    | Third line |quux | baz | bar
+    |---
+    | Second body
+    | 2 line
+    |===
+    | Footer row
+
+
+## Horizontal Rules
+
+A horizontal rule for visually separating content is created by using three or more asterisks,
+dashes or underscores (these may not be mixed on a line), optionally separated by spaces or tabs, on
+an otherwise blank line. The first asterisk, dash or underscore may optionally be indented up to
+three spaces. The following examples show different possibilities to create a horizontal rule:
+
+    * * *
+
+    ---
+
+      _  _  _  _
+
+    ---------------
+
+
+## Math Blocks
+
+> This syntax feature is not part of the original Markdown syntax. The idea comes from the [Maruku]
+> and [Pandoc] packages.
+{: .markdown-difference}
+
+kramdown has built-in support for block and span level mathematics written in LaTeX.
+
+A math block is started using two dollar signs, optionally indented up to three spaces. The math
+block continues until the next two dollar signs (which may be on the same line or on one of the next
+lines) that appear at the end of a line, i.e. they may only be followed by whitespace characters.
+The content of a math block has to be valid LaTeX math. It is always wrapped inside a
+`\begin{displaymath}...\end{displaymath}` enviroment except if it begins with a `\begin` statement.
+
+The following kramdown fragment
+
+    $$
+    \begin{align*}
+      & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
+      = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
+      & (x_1, \ldots, x_n) \left( \begin{array}{ccc}
+          \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
+          \vdots & \ddots & \vdots \\
+          \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
+        \end{array} \right)
+      \left( \begin{array}{c}
+          y_1 \\
+          \vdots \\
+          y_n
+        \end{array} \right)
+    \end{align*}
+    $$
+
+renders as
+
+$$
+\begin{align*}
+  & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
+  = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
+  & (x_1, \ldots, x_n) \left( \begin{array}{ccc}
+      \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
+      \vdots & \ddots & \vdots \\
+      \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
+    \end{array} \right)
+  \left( \begin{array}{c}
+      y_1 \\
+      \vdots \\
+      y_n
+    \end{array} \right)
+\end{align*}
+$$
+
+Using inline math is also easy: just surround your math content with two dollar signs, like with a
+math block.
+
+If you don't want to start a math block or an inline math statement, just escape the dollar signs
+and they will be treated as simple dollar signs. If you want to start an inline math statement at
+the beginning of a paragraph, just escape the first dollar sign.
+
+
+## HTML Blocks
+
+> The original Markdown syntax specifies that an HTML block must start at the left margin, i.e. no
+> indentation is allowed. Also, the HTML block has to be surrounded by blank lines. Both
+> restrictions are lifted for kramdown documents. Additionally, the original syntax does not allow
+> you to use Markdown syntax in HTML blocks which is allowed with kramdown.
+{: .markdown-difference}
+
+An HTML block is potentially started if a line is encountered that begins with a non-span-level HTML
+tag or a general XML tag (opening or closing) which may be indented up to three spaces.
+
+The following HTML tags count as span level HTML tags and *won't* start an HTML block if found at
+the beginning of an HTML block line:
+
+    a abbr acronym b big bdo br button cite code del dfn em i img input
+    ins kbd label option q rb rbc rp rt rtc ruby samp select small span
+    strong sub sup textarea tt var
+
+Further parsing of a found start tag depends on the tag and in which of three possible ways its
+content is parsed:
+
+* Parse as raw HTML block: If the HTML/XML tag content should be handled as raw HTML, then only
+  HTML/XML tags are parsed from this point onwards and text is handled as raw, unparsed text until
+  the matching end tag is found or until the end of the document. Each found tag will be parsed as
+  raw HTML again. However, if a tag has a `markdown` attribute, this attribute controls parsing of
+  this one tag (see below).
+
+  Note that only correct XHTML is supported! This means that you have to use, for example, `<hr />`
+  instead of `<hr>` (although kramdown tries to fix such things if possible). If an invalid closing
+  tag is found, it is ignored.
+
+* Parse as block level elements: If the HTML/XML tag content should be parsed as text containing
+  block level elements, the remaining text on the line will be parsed by the block level parser as
+  if it appears on a separate line (**Caution**: This also means that if the line consists of the
+  start tag, text and the end tag, the end tag will not be found!). All following lines are parsed
+  as block level elements until an HTML block line with the matching end tag is found or until the
+  end of the document.
+
+* Parse as span level elements: If the HTML/XML tag content should be parsed as text containing span
+  level elements, then all text until the *next* matching end tag or until the end of the document
+  will be the content of the tag and will later be parsed by the span level parser. This also means
+  that if the matching end tag is inside what appears to be a code span, it is still used!
+
+If there is text after an end tag, it will be parsed as if it appears on a separate line except when
+inside a raw HTML block.
+
+Also, if an invalid closing tag is found, it is ignored.
+
+By default, kramdown parses all block HTML tags and all XML tags as raw HTML blocks. However, this
+can be configured with the `parse_block_html`. If this is set to `true`, then syntax parsing in HTML
+blocks is globally enabled. It is also possible to enable/disable syntax parsing on a tag per tag
+basis using the `markdown` attribute:
+
+* If an HTML tag has an attribute `markdown="0"`, then the tag is parsed as raw HTML block.
+
+* If an HTML tag has an attribute `markdown="1"`, then the default mechanism for parsing syntax in
+  this tag is used.
+
+* If an HTML tag has an attribute `markdown="block"`, then the content of the tag is parsed as block
+  level elements.
+
+* If an HTML tag has an attribute `markdown="span"`, then the content of the tag is parsed as span
+  level elements.
+
+The following list shows which HTML tags are parsed in which mode by default when `markdown="1"` is
+applied or `parse_block_html` is `true`:
+
+Parse as raw HTML block
+: 
+        script math option textarea
+
+    Also, all general XML tags are parsed as raw HTML blocks.
+
+Parse as block level elements
+: 
+        applet button blockquote colgroup dd div dl fieldset form iframe li
+        map noscript object ol table tbody thead tfoot tr td ul
+
+Parse as span level elements
+: 
+        a abbr acronym address b bdo big cite caption code del dfn dt em
+        h1 h2 h3 h4 h5 h6 i ins kbd label legend optgroup p pre q rb rbc
+        rp rt rtc ruby samp select small span strong sub sup th tt var
+
+> Remember that all span level HTML tags like `a` or `b` do not start a HTML block! However, the
+> above lists also include span level HTML tags in the case the `markdown` attribute is used on a
+> tag inside a raw HTML block.
+
+Here is a simple example input and its HTML output with `parse_block_html` set to `false`:
+
+    This is a para.
+    <div>
+    Something in here.
+    </div>
+    Other para.
+^
+    <p>This is a para.</p>
+    <div>
+    Something in here.
+    </div>
+    <p>Other para.</p>
+
+As one can see the content of the `div` tag will be parsed as raw HTML block and left alone.
+However, if the `markdown="1"` attribute was used on the `div` tag, the content would be parsed as
+block level elements and therefore converted to a paragraph.
+
+You can also use several HTML tags at once:
+
+    <div id="content"><div id="layers"><div id="layer1">
+    This is some text in the `layer1` div.
+    </div>
+    This is some text in the `layers` div.
+    </div></div>
+    This is a para outside the HTML block.
+
+However, remember that if the content of a tag is parsed as block level elements, the content that
+appears after a start/end tag but on the same line, is processed as if it appears on a new line:
+
+    <div markdown="1">This is the first part of a para,
+    which is continued here.
+    </div>
+
+    <p markdown="1">This works without problems because it is parsed as span level elements</p>
+
+    <div markdown="1">The end tag is not found because
+    this line is parsed as a paragraph</div>
+
+Since setting `parse_block_html` to `true` can lead to some not wanted behaviour, it is generally
+better to selectively enable or disable block/span level elements parsing by using the `markdown`
+attribute!
+
+Unclosed block level HTML tags are correctly closed at the end of the document to ensure correct
+nesting and invalidly used end tags are removed from the output:
+
+    This is a para.
+    <div markdown="1">
+    Another para.
+    </p>
+^
+    <p>This is a para.</p>
+    <div>
+      <p>Another para.</p>
+    </div>
+
+The parsing of processing instructions and XML comments is also supported. The content of both, PIs
+and XML comments, may span multiple lines. The start of a PI/XML comment may only appear at the
+beginning of a line, optionally indented up to three spaces. If there is text after the end of a PI
+or XML comment, it will be parsed as if it appears on a separate line. kramdown syntax in PIs/XML
+comments is not processed:
+
+    This is a para.
+    <!-- a *comment* -->
+    <? a processing `instruction`
+       spanning multiple lines
+    ?> First part of para,
+    continues here.
+
+
+
+# Text Markup
+
+These elements are used inside block level elements to markup text fragments. For example, one can
+easily create links or apply emphasis to certain text parts.
+
+Note that empty span level elements are not converted to empty HTML tags but are copied as-is to the
+output.
+
+
+
+## Links and Images
+
+Three types of links are supported: autolinks, inline links and reference links.
+
+### Autolinks
+
+This is the easiest one to create: Just surround a web address or an email address with angle
+brackets and the address will be turned into a proper link. The address will be used as link target
+and as link text. For example:
+
+    Information can be found on the <http://example.com> homepage.
+    You can also mail me: <me.example@example.com>
+
+It is not possible to specify a different link text using autolinks -- use the other link types for
+this!
+
+
+### Inline Links
+
+As the wording suggests, inline links provide all information inline in the text flow. Reference
+style links only provide the link text in the text flow and everything else is defined
+elsewhere. This also allows you to reuse link definitions.
+
+An inline style link can be created by surrounding the link text with square brackets, followed
+immediately by the link URL (and an optional title in single or double quotes preceded by at least
+one space) in normal parentheses. For example:
+
+    This is [a link](http://rubyforge.org) to a page.
+    A [link](../test "local URI") can also have a title.
+    And [spaces](<link with spaces.html>)!
+
+Notes:
+
+* The link text is treated like normal span level text and therefore is parsed and converted.
+  However, if you use square brackets within the link text, you have to either properly nest them or
+  to escape them. It is not possible to create nested links!
+
+* The link URL must not contain any spaces and it has to contain properly nested parentheses if no
+  title is specified, or the link URL must be contained in angle brackets (then spaces and
+  incorrectly nested parentheses are allowed). There must not be any spaces before the link URL, and
+  if no title is specified, no spaces are allowed between the link URL and the closing parenthesis.
+
+* The link title may not contain its delimiters and may not be empty.
+
+### Reference Links
+
+To create a reference style link, you need to surround the link text with square brackets (as with
+inline links), followed by optional spaces/tabs/line breaks and then optionally followed with
+another set of square brackets with the link identifier in them. A link identifier may only contain
+numbers, letters, spaces (line breaks and tabs are converted to spaces, multiple spaces are
+compressed to one) and punctuation characters (i.e. `_.:,;!?-`) and is not case sensitive. For
+example:
+
+    This is a [reference style link][linkid] to a page. And [this]
+    [linkid] is also a link. As is [this][] and [THIS].
+
+If you don't specify a link identifier (i.e. only use empty square brackets) or completely omit the
+second pair of square brackets, the link text is converted to a valid link identifier by removing
+all invalid characters and inserting spaces for line breaks. If there is a link definition found for
+the link identifier, a link will be created. Otherwise the text is not converted to a link.
+
+### Link Definitions
+
+The link definition can be put anywhere in the document. It does not appear in the output. A link
+definition looks like this:
+
+    [linkid]: http://www.example.com/ "Optional Title"
+
+> Link definitions are, despite being described here, block level elements.
+{: .information}
+
+The link definition has the following structure:
+
+* The link identifier in square brackets, optionally indented up to three spaces,
+* then a colon and one or more spaces/tabs,
+* then the link URL which must not contain any spaces or a left angle bracket, the link URL which may
+  contain spaces and a right angle bracket,
+* then optionally the title in single or double quotes, separated from the link URL by one or more
+  spaces or on the next line by itself indented any number of spaces/tabs.
+
+> The original Markdown syntax also allowed the title to be specified in parenthesis. This is not
+> allowed for consistency with the inline title.
+{: .markdown-difference}
+
+### Images
+
+Images can be specified via a syntax that is similar to the one used by links. The difference is
+that you have to use an exclamation mark before the first square bracket and that the link text of a
+normal link becomes the alternative text of the image link. As with normal links, image links can be
+written inline or reference style. For example:
+
+    Here comes a ![smiley](../images/smiley.png)! And here
+    ![too](../images/other.png 'Title text'). Or ![here].
+
+The link definition for images is exactly the same as the link definition for normal links.
+
+
+## Emphasis
+
+kramdown supports two types of emphasis: light and strong emphasis. Text parts that are surrounded
+with single asterisks `*` or underscores `_` are treated as text with light emphasis, text parts
+surrounded with two asterisks or underscores are treated as text with strong emphasis. Surrounded
+means that the starting delimiter must not be followed by a space and that the stopping delimiter
+must not be preceded by a space.
+
+Here is an example for text with light and strong emphasis:
+
+    *some text*
+    _some text_
+    **some text**
+    __some text__
+
+The asterisk form is also allowed within a single word:
+
+    This is un*believe*able! This d_oe_s not work!
+
+Text can be marked up with both light and strong emphasis, possibly using different delimiters.
+However, it is not possible to nest strong within strong or light within light emphasized text:
+
+    This is a ***text with light and strong emphasis***.
+    This **is _emphasized_ as well**.
+    This *does _not_ work*.
+    This **does __not__ work either**.
+
+If one or two asterisks or underscores are surrounded by spaces, they are treated literally. If you
+want to force the literal meaning of an asterisk or an underscore you can backslash-escape it:
+
+    This is a * literal asterisk.
+    These are ** two literal asterisk.
+    As \*are\* these!
+
+
+## Code Spans
+
+This is the span level equivalent of the code block element. You can markup a text part as code span
+by surrounding it with backticks `` ` ``. For example:
+
+    Use `<html>` tags for this.
+
+Note that all special characters in a code span are treated correctly. For example, when a code span
+is converted to HTML, the characters `<`, `>` and `&` are substituted by their respective HTML
+counterparts.
+
+To include a literal backtick in a code span, you need to use two or more backticks as delimiters.
+You can insert one optional space after the starting and before the ending delimiter (these spaces
+are not used in the output). For example:
+
+    Here is a literal `` ` `` backtick.
+    And here is ``  `some`  `` text (note the two spaces so that one is left in the output!).
+
+A single backtick surrounded by spaces is treated as literal backtick. If you want to force the
+literal meaning of a backtick you can backslash-escape it:
+
+    This is a ` literal backtick.
+    As \`are\` these!
+
+
+## HTML Spans
+
+HTML tags cannot only be used on the block level but also on the span level. Span level HTML tags
+can only be used inside one block level element, it is not possible to use a start tag in one block
+level element and the end tag in another. Note that only correct XHTML is supported! This means that
+you have to use, for example, `<br />` instead of `<br>` (although kramdown tries to fix such errors
+if possible).
+
+By default, kramdown parses kramdown syntax inside span HTML tags. However, this behaviour can be
+configured with the `parse_span_html` option. If this is set to `true`, then syntax parsing in HTML
+spans is enabled, if it is set to `false`, parsing is disabled. It is also possible to
+enable/disable syntax parsing on a tag per tag basis using the `markdown` attribute:
+
+* If an HTML tag has an attribute `markdown="0"`, then no parsing (except parsing of HTML span tags)
+  is done inside that HTML tag.
+
+* If an HTML tag has an attribute `markdown="1"`, then the content of the tag is parsed as span
+  level elements.
+
+* If an HTML tag has an attribute `markdown="block"`, then a warning is issued because HTML spans
+  cannot contain block level elements and the attribute is ignored.
+
+* If an HTML tag has an attribute `markdown="span"`, then the content of the tag is parsed as span
+  level elements.
+
+The content of a span level HTML tag is normally parsed as span level elements. Note, however, that
+some tags like `<script>` are not parsed, i.e. their content is not modified.
+
+Processing instructions and XML comments can also be used (their content is not parsed). However, as
+with HTML tags the start and the end have to appear in the same block level element.
+
+Span level PIs and span level XML comments as well as general span level HTML and XML tags have to
+be preceded by at least one non whitespace character on the same line so that kramdown correctly
+recognizes them as span level element and not as block level element. However, all span HTML tags,
+i.e. `a`, `em`, `b`, ..., (opening or closing) can appear at the start of a line.
+
+Unclosed span level HTML tags are correctly closed at the end of the span level text to ensure
+correct nesting and invalidly used end tags or block HTML tags are removed from the output:
+
+    This is </invalid>.
+
+    This <span>is automatically closed.
+^
+    <p>This is .</p>
+
+    <p>This <span>is automatically closed.</span></p>
+
+Also note that one or more consecutive new line characters in an HTML span tag are replaced by a
+single space, for example:
+
+    Link: <a href="some
+    link">text</a>
+^
+    <p>Link: <a href="some link">text</a></p>
+
+
+## Footnotes
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [PHP Markdown Extra] package.
+{: .markdown-difference}
+
+Footnotes in kramdown are similar to reference style links and link definitions. You need to place
+the footnote marker in the correct position in the text and the actual footnote content can be
+defined anywhere in the document.
+
+More exactly, a footnote marker can be created by placing the footnote name in square brackets.
+The footnote name has to start with a caret (`^`), followed by a word character or a digit and then
+optionally followed by other word characters, digits or dashes. For example:
+
+    This is some text.[^1]. Other text.[^footnote].
+
+The footnote name has to be unique in the whole kramdown document. Therefore you can't link to the
+same footnote definition twice. The actual naming of a footnote does not matter since the numbering
+of footnotes is controlled via the position of the footnote markers in the document (the first found
+footnote marker will get the number 1, the second footnote marker the number 2 and so on). If there
+is a footnote definition found for the identifier, a footnote will be created. Otherwise the
+footnote marker is not converted to a footnote link. Also note that all attributes set via a span
+IAL are ignored for a footnote marker!
+
+A footnote definition is used to define the content of a footnote and has the following structure:
+
+* The footnote name in square brackets, optionally indented up to three spaces,
+* then a colon and one or more optional spaces,
+* then the text of the footnote
+* and optionally more text on the following lines which have have to be indented by four spaces or
+  one tab (like with list items).
+
+> Footnote definitions are, despite being described here, block level elements.
+{: .information}
+
+The whole footnote content is treated like block level text and can therefore contain any valid
+block level element (also, any block level element can be the first element). If you want to have a
+code block as first element, note that all leading spaces/tabs on the first line are stripped away.
+Here are some example footnote definitions:
+
+    [^1]: Some *crazy* footnote definition.
+
+    [^footnote]:
+        > Blockquotes can be in a footnote.
+
+            as well as code blocks
+
+        or, naturally, simple paragraphs.
+
+    [^other-note]:       no code block here (spaces are stripped away)
+
+    [^codeblock-note]:
+            this is now a code block (8 spaces indentation)
+
+It does not matter where you put a footnote definition in a kramdown document; the content of all
+referenced footnote definitions will be placed at the end of the kramdown document. Not referenced
+foot note definitions are ignored. If more than one footnote definitions have the same footnote
+name, all footnote definitions but the last are ignored.
+
+
+## Abbreviations
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [PHP Markdown Extra] package.
+{: .markdown-difference}
+
+kramdown provides a syntax to assign the full phrase to an abbreviation. When writing the text, you
+don't need to do anything special. However, once you add abbreviation definitions, the
+abbreviations in the text get marked up automatically. Abbreviations can consist of any character
+except a closing bracket.
+
+An abbreviation definition is used to define the full phrase for an abbreviation and has the
+following structure:
+
+* An asterisk and the abbreviation in square brackets, optionally indented up to three
+  spaces,
+* then a colon and the full phrase of the abbreviation on one line (leading and trailing spaces are
+  stripped from the full phrase).
+
+Later abbreviation definition for the same abbreviation override prior ones and it does not matter
+where you put an abbreviation definition in a kramdown document. Empty definitions are also allowed.
+
+Here are some examples:
+
+    This is some text not written in HTML but in another language!
+
+    *[another language]: It's called Markdown
+    *[HTML]: HyperTextMarkupLanguage
+
+> Abbreviation definitions are, despite being described here, block level elements.
+{: .information}
+
+
+## Typographic Symbols
+
+> The original Markdown syntax does not support these transformations.
+{: .markdown-difference}
+
+kramdown converts the following plain ASCII character into their corresponding typographic symbols:
+
+* `---` will become an em-dash (like this ---)
+* `--` will become an en-dash (like this --)
+* `...` will become an ellipsis (like this ...)
+* `<<` will become a left guillemet (like this <<) -- an optional following space will become a
+  non-breakable space
+* `>>` will become a right guillemet (like this >>) -- an optional leading space will become a
+  non-breakable space
+
+It also replaces normal single `'` and double quotes `"` with "fancy quotes". There *may* be times
+when kramdown falsely replace the quotes. If this is the case, just \'escape\" the quotes and they
+won't be replaced with fancy ones.
+
+
+
+# Other Markup
+
+This section describes markup that is not widely used in kramdown documents but which are sometimes
+needed nonetheless.
+
+
+## End-Of-Block Marker    {#eob-marker}
+
+> The EOB marker is not part of the standard Markdown syntax.
+{: .markdown-difference}
+
+The End-Of-Block (EOB) marker -- a `^` as first character on an otherwise empty line -- is a block
+level element that can be used to specify the end of a block level element even if the block level
+element, after which it is used, would continue otherwise. If there is no block level element to
+end, the EOB marker is simply ignored.
+
+You won't find an EOB marker in most kramdown documents but sometimes it is necessary to use it to
+achieve the wanted results which would be impossible otherwise. However, it should only be used when
+absolutely necesary!
+
+For example, the following gives you one list with two items:
+
+    * list item one
+
+    * list item two
+
+By using an EOB marker, you can make two lists with one item each:
+
+    * list one
+    ^
+    * list two
+
+
+## Attribute List Definitions
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [Maruku] package.
+{: .markdown-difference}
+
+This is an implementation of [Maruku]'s feature for adding attributes to block and span level
+elements (the naming is also taken from Maruku). This block level element is used to define
+attributes which can be referenced later. The [Block Inline Attribute
+List](#block-inline-attribute-lists) is used to attach attributes to a block level element and the
+[Span Inline Attribute List](#span-inline-attribute-lists) is used to attach attributes to a span
+level element.
+
+Following are some examples of attribute list definitions (ALDs) and afterwards comes the syntax
+explanation:
+
+    {:ref-name: #myid .my-class}
+    {:other: ref-name #id-of-other title="hallo you"}
+    {:test: key="value \" with quote" and other='quote brace \}'}
+
+An ALD line has the following structure:
+
+* a left brace, optionally preceded by up to three spaces,
+* followed by a colon, the reference name and another colon,
+* followed by attribute definitions (allowed characters are backslash-escaped closing braces or any
+  character except a not escaped closing brace),
+* followed by a closing brace and optional spaces until the end of the line.
+
+The reference name needs to start with a word character or a digit, optionally followed by other word
+characters, digits or dashes.
+
+There are four different types of attribute definitions which have to be separated by one or more
+spaces:
+
+references
+
+:   This must be a valid reference name. It is used to reference an other ALD so that the attributes
+    of the other ALD are also included in this one. The reference name is ignored when collecting the
+    attributes if no attribute definition list with this reference name exists. For example, a
+    simple reference looks like `id`.
+
+key-value pairs
+
+:   A key-value pair is defined by a key name, which must follow the rules for reference names, then
+    an equal sign and then the value in single or double quotes. If you need to use the value
+    delimiter (a single or a double quote) inside the value, you need to escape it with a backslash.
+    Key-value pairs can be used to specify arbitrary attributes for block or span level elements. For
+    example, a key-value pair looks like `key1="bef \"quoted\" aft"` or `title='This is a title'`.
+
+ID name
+
+:   An ID name is defined by using a hash and then the identifier name which must follow the rules
+    for reference names. This is a short hand for the key-value pair `id="IDNAME"` since this is
+    often used. The ID name specifies the unique ID of a block or span level element. For example,
+    an ID name looks like `#myid`.
+
+class names
+
+:   A class name is defined by using a dot and then the class name. This is (almost, but not quite)
+    a short hand for the key-value pair `class="class-name"`. Almost because it actually means that
+    the class name should be appended to the current value of the `class` attribute. The following
+    ALDs are all equivalent:
+
+        {:id: .cls1 .cls2}
+        {:id: class="cls1" .cls2}
+        {:id: class="something" class="cls1" .cls2}
+        {:id: class="cls1 cls2}
+
+As can be seen from the example of the class names, attributes that are defined earlier are
+overwritten by ones with the same name defined later. Also, everything in the attribute definitions
+part that does not match one of the above four types is ignored.
+
+If there is more than one ALD with the same reference name, the attribute definitions of all the
+ALDs are processed like they are defined in one ALD.
+
+
+## Inline Attribute Lists
+
+These elements are used to attach attributes to another element.
+
+### Block Inline Attribute Lists
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [Maruku] package.
+{: .markdown-difference}
+
+This block level element is used to attach attributes to a block level element. A block inline
+attribute list (block IAL) has the same structure as an [ALD](#attribute-list-definitions) except
+that the colon/reference name/colon part is replaced by a colon. A block IAL (or two or more block
+IALs) has to be put directly before or after the block level element to which the attributes should
+be attached. If a block IAL is directly after *and* before a block level element, it is applied to
+preceding element. The block IAL is ignored in all other cases, for example, when the block IAL is
+surrounded by blank lines.
+
+Key-value pairs of an IAL take precedence over equally named key-value pairs in referenced ALDs.
+
+Here are some examples for block IALs:
+
+    A simple paragraph with an ID attribute.
+    {: #para-one}
+
+    > A blockquote with a title
+    {:title="The blockquote title"}
+    {: #myid}
+
+    {:.ruby}
+        Some code here
+
+### Span Inline Attribute Lists
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [Maruku] package.
+{: .markdown-difference}
+
+This is a version of the [block inline attribute list](#block-inline-attribute-lists) for span level
+elements. It has the same structure as the block IAL except that leading and trailing spaces are not
+allowed. A span IAL (or two or more span IALs) has to be put directly after the span level element
+to which it should be applied, no additional character is allowed between, otherwise it is ignored
+and only removed from the output.
+
+Here are some examples for span IALs:
+
+    This *is*{:.underline} some `code`{:#id}{:.class}.
+    A [link](test.html){:rel='something'} and some **tools**{:.tools}.
+
+
+## Extensions
+
+> This syntax feature is not part of the original Markdown syntax.
+{: .markdown-difference}
+
+Extensions provide additional functionality but use the same syntax for it. They are available as
+block as well as span level elements.
+
+The syntax for an extension is very similar to the syntax of [ALDs](#attribute-list-definitions).
+Here are some examples of how to specify extensions and afterwards is the syntax definition:
+
+    {::comment}
+    This text is completely ignored by kramdown - a comment in the text.
+    {:/comment}
+
+    Do you see {::comment}this text{:/comment}?
+    {::comment}some other comment{:/}
+
+    {::options key="val" /}
+
+An extension can be specified with or without a body. Therefore there exist a start and an end tag
+for extensions. The start tag has the following structure:
+
+* an left brace,
+* followed by two colons and the extension name,
+* optionally followed by a space and attribute definitions (allowed characters are backslash-escaped
+  closing braces or any character except a not escaped closing brace -- same as with ALDs),
+* followed by a slash and a right brace (in case the extension has no body) or only a right
+  brace (in case the extension has a body).
+
+The stop tag has the following structure:
+
+* a left brace,
+* followed by a colon and a slash,
+* optionally followed by the extension name,
+* followed by a right brace.
+
+A stop tag is only needed if the extension has a body!
+
+The above syntax can be used as is for span level extensions. The starting and ending lines for block level
+extensions are defined as:
+
+* The starting line consists of the extension start tag, optionally preceded by up to three spaces,
+  and followed by optional spaces until the end of the line.
+* The ending line consists of the extension stop tag, optionally preceded by up to three spaces,
+  and followed by optional spaces until the end of the line.
+
+If no end tag can be found for an extension start tag, the start tag is treated as if it has no
+body. If an invalid extension stop tag is found, it is ignored. If an invalid extension name is
+specified the extension (and the eventually specified body) are ignored.
+
+The following extensions can be used with kramdown:
+
+`comment`
+
+:   Treat the body text as a comment which does not show in the output.
+
+`nomarkdown`
+
+:   Don't process the body with kramdown but output it as-is.
+
+`options`
+
+:   Should be used without a body since the body is ignored. Is used for setting the global options
+    for the kramdown processor (for example, to disable automatic header ID generation). Note that
+    options that are used by the parser are immediately effective whereas all other options are not!
+    This means, for example, that it is not possible to set converter options only for some part of
+    a kramdown document.
+
+
+
+{include_file: doc/links.markdown}