RubyGems - radiantcms-couchrest_model - Versions diffs - 0.1.4 → 0.1.5 - Mend

radiantcms-couchrest_model 0.1.4 → 0.1.5

Files changed (1438) hide show

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

@@ -1,1521 +0,0 @@
----
-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}