diff options
Diffstat (limited to 'test/data/markdown')
| -rw-r--r-- | test/data/markdown/spec.txt | 6150 |
1 files changed, 0 insertions, 6150 deletions
diff --git a/test/data/markdown/spec.txt b/test/data/markdown/spec.txt deleted file mode 100644 index fce87924..00000000 --- a/test/data/markdown/spec.txt +++ /dev/null @@ -1,6150 +0,0 @@ ---- -title: CommonMark Spec -author: -- John MacFarlane -version: 2 -date: 2014-09-19 -... - -# Introduction - -## What is Markdown? - -Markdown is a plain text format for writing structured documents, -based on conventions used for indicating formatting in email and -usenet posts. It was developed in 2004 by John Gruber, who wrote -the first Markdown-to-HTML converter in perl, and it soon became -widely used in websites. By 2014 there were dozens of -implementations in many languages. Some of them extended basic -Markdown syntax with conventions for footnotes, definition lists, -tables, and other constructs, and some allowed output not just in -HTML but in LaTeX and many other formats. - -## Why is a spec needed? - -John Gruber's [canonical description of Markdown's -syntax](http://daringfireball.net/projects/markdown/syntax) -does not specify the syntax unambiguously. Here are some examples of -questions it does not answer: - -1. How much indentation is needed for a sublist? The spec says that - continuation paragraphs need to be indented four spaces, but is - not fully explicit about sublists. It is natural to think that - they, too, must be indented four spaces, but `Markdown.pl` does - not require that. This is hardly a "corner case," and divergences - between implementations on this issue often lead to surprises for - users in real documents. (See [this comment by John - Gruber](http://article.gmane.org/gmane.text.markdown.general/1997).) - -2. Is a blank line needed before a block quote or header? - Most implementations do not require the blank line. However, - this can lead to unexpected results in hard-wrapped text, and - also to ambiguities in parsing (note that some implementations - put the header inside the blockquote, while others do not). - (John Gruber has also spoken [in favor of requiring the blank - lines](http://article.gmane.org/gmane.text.markdown.general/2146).) - -3. Is a blank line needed before an indented code block? - (`Markdown.pl` requires it, but this is not mentioned in the - documentation, and some implementations do not require it.) - - ``` markdown - paragraph - code? - ``` - -4. What is the exact rule for determining when list items get - wrapped in `<p>` tags? Can a list be partially "loose" and partially - "tight"? What should we do with a list like this? - - ``` markdown - 1. one - - 2. two - 3. three - ``` - - Or this? - - ``` markdown - 1. one - - a - - - b - 2. two - ``` - - (There are some relevant comments by John Gruber - [here](http://article.gmane.org/gmane.text.markdown.general/2554).) - -5. Can list markers be indented? Can ordered list markers be right-aligned? - - ``` markdown - 8. item 1 - 9. item 2 - 10. item 2a - ``` - -6. Is this one list with a horizontal rule in its second item, - or two lists separated by a horizontal rule? - - ``` markdown - * a - * * * * * - * b - ``` - -7. When list markers change from numbers to bullets, do we have - two lists or one? (The Markdown syntax description suggests two, - but the perl scripts and many other implementations produce one.) - - ``` markdown - 1. fee - 2. fie - - foe - - fum - ``` - -8. What are the precedence rules for the markers of inline structure? - For example, is the following a valid link, or does the code span - take precedence ? - - ``` markdown - [a backtick (`)](/url) and [another backtick (`)](/url). - ``` - -9. What are the precedence rules for markers of emphasis and strong - emphasis? For example, how should the following be parsed? - - ``` markdown - *foo *bar* baz* - ``` - -10. What are the precedence rules between block-level and inline-level - structure? For example, how should the following be parsed? - - ``` markdown - - `a long code span can contain a hyphen like this - - and it can screw things up` - ``` - -11. Can list items include headers? (`Markdown.pl` does not allow this, - but headers can occur in blockquotes.) - - ``` markdown - - # Heading - ``` - -12. Can link references be defined inside block quotes or list items? - - ``` markdown - > Blockquote [foo]. - > - > [foo]: /url - ``` - -13. If there are multiple definitions for the same reference, which takes - precedence? - - ``` markdown - [foo]: /url1 - [foo]: /url2 - - [foo][] - ``` - -In the absence of a spec, early implementers consulted `Markdown.pl` -to resolve these ambiguities. But `Markdown.pl` was quite buggy, and -gave manifestly bad results in many cases, so it was not a -satisfactory replacement for a spec. - -Because there is no unambiguous spec, implementations have diverged -considerably. As a result, users are often surprised to find that -a document that renders one way on one system (say, a github wiki) -renders differently on another (say, converting to docbook using -pandoc). To make matters worse, because nothing in Markdown counts -as a "syntax error," the divergence often isn't discovered right away. - -## About this document - -This document attempts to specify Markdown syntax unambiguously. -It contains many examples with side-by-side Markdown and -HTML. These are intended to double as conformance tests. An -accompanying script `runtests.pl` can be used to run the tests -against any Markdown program: - - perl runtests.pl spec.txt PROGRAM - -Since this document describes how Markdown is to be parsed into -an abstract syntax tree, it would have made sense to use an abstract -representation of the syntax tree instead of HTML. But HTML is capable -of representing the structural distinctions we need to make, and the -choice of HTML for the tests makes it possible to run the tests against -an implementation without writing an abstract syntax tree renderer. - -This document is generated from a text file, `spec.txt`, written -in Markdown with a small extension for the side-by-side tests. -The script `spec2md.pl` can be used to turn `spec.txt` into pandoc -Markdown, which can then be converted into other formats. - -In the examples, the `→` character is used to represent tabs. - -# Preprocessing - -A [line](#line) <a id="line"></a> -is a sequence of zero or more characters followed by a line -ending (CR, LF, or CRLF) or by the end of -file. - -This spec does not specify an encoding; it thinks of lines as composed -of characters rather than bytes. A conforming parser may be limited -to a certain encoding. - -Tabs in lines are expanded to spaces, with a tab stop of 4 characters: - -. -→foo→baz→→bim -. -<pre><code>foo baz bim -</code></pre> -. - -. - a→a - ὐ→a -. -<pre><code>a a -ὐ a -</code></pre> -. - -Line endings are replaced by newline characters (LF). - -A line containing no characters, or a line containing only spaces (after -tab expansion), is called a [blank line](#blank-line). -<a id="blank-line"></a> - -# Blocks and inlines - -We can think of a document as a sequence of [blocks](#block)<a -id="block"></a>---structural elements like paragraphs, block quotations, -lists, headers, rules, and code blocks. Blocks can contain other -blocks, or they can contain [inline](#inline)<a id="inline"></a> content: -words, spaces, links, emphasized text, images, and inline code. - -## Precedence - -Indicators of block structure always take precedence over indicators -of inline structure. So, for example, the following is a list with -two items, not a list with one item containing a code span: - -. -- `one -- two` -. -<ul> -<li>`one</li> -<li>two`</li> -</ul> -. - -This means that parsing can proceed in two steps: first, the block -structure of the document can be discerned; second, text lines inside -paragraphs, headers, and other block constructs can be parsed for inline -structure. The second step requires information about link reference -definitions that will be available only at the end of the first -step. Note that the first step requires processing lines in sequence, -but the second can be parallelized, since the inline parsing of -one block element does not affect the inline parsing of any other. - -## Container blocks and leaf blocks - -We can divide blocks into two types: -[container blocks](#container-block), <a id="container-block"></a> -which can contain other blocks, and [leaf blocks](#leaf-block), -<a id="leaf-block"></a> which cannot. - -# Leaf blocks - -This section describes the different kinds of leaf block that make up a -Markdown document. - -## Horizontal rules - -A line consisting of 0-3 spaces of indentation, followed by a sequence -of three or more matching `-`, `_`, or `*` characters, each followed -optionally by any number of spaces, forms a [horizontal -rule](#horizontal-rule). <a id="horizontal-rule"></a> - -. -*** ---- -___ -. -<hr /> -<hr /> -<hr /> -. - -Wrong characters: - -. -+++ -. -<p>+++</p> -. - -. -=== -. -<p>===</p> -. - -Not enough characters: - -. --- -** -__ -. -<p>-- -** -__</p> -. - -One to three spaces indent are allowed: - -. - *** - *** - *** -. -<hr /> -<hr /> -<hr /> -. - -Four spaces is too many: - -. - *** -. -<pre><code>*** -</code></pre> -. - -. -Foo - *** -. -<p>Foo -***</p> -. - -More than three characters may be used: - -. -_____________________________________ -. -<hr /> -. - -Spaces are allowed between the characters: - -. - - - - -. -<hr /> -. - -. - ** * ** * ** * ** -. -<hr /> -. - -. -- - - - -. -<hr /> -. - -Spaces are allowed at the end: - -. -- - - - -. -<hr /> -. - -However, no other characters may occur at the end or the -beginning: - -. -_ _ _ _ a - -a------ -. -<p>_ _ _ _ a</p> -<p>a------</p> -. - -It is required that all of the non-space characters be the same. -So, this is not a horizontal rule: - -. - *-* -. -<p><em>-</em></p> -. - -Horizontal rules do not need blank lines before or after: - -. -- foo -*** -- bar -. -<ul> -<li>foo</li> -</ul> -<hr /> -<ul> -<li>bar</li> -</ul> -. - -Horizontal rules can interrupt a paragraph: - -. -Foo -*** -bar -. -<p>Foo</p> -<hr /> -<p>bar</p> -. - -Note, however, that this is a setext header, not a paragraph followed -by a horizontal rule: - -. -Foo ---- -bar -. -<h2>Foo</h2> -<p>bar</p> -. - -When both a horizontal rule and a list item are possible -interpretations of a line, the horizontal rule is preferred: - -. -* Foo -* * * -* Bar -. -<ul> -<li>Foo</li> -</ul> -<hr /> -<ul> -<li>Bar</li> -</ul> -. - -If you want a horizontal rule in a list item, use a different bullet: - -. -- Foo -- * * * -. -<ul> -<li>Foo</li> -<li><hr /></li> -</ul> -. - -## ATX headers - -An [ATX header](#atx-header) <a id="atx-header"></a> -consists of a string of characters, parsed as inline content, between an -opening sequence of 1--6 unescaped `#` characters and an optional -closing sequence of any number of `#` characters. The opening sequence -of `#` characters cannot be followed directly by a nonspace character. -The closing `#` characters may be followed by spaces only. The opening -`#` character may be indented 0-3 spaces. The raw contents of the -header are stripped of leading and trailing spaces before being parsed -as inline content. The header level is equal to the number of `#` -characters in the opening sequence. - -Simple headers: - -. -# foo -## foo -### foo -#### foo -##### foo -###### foo -. -<h1>foo</h1> -<h2>foo</h2> -<h3>foo</h3> -<h4>foo</h4> -<h5>foo</h5> -<h6>foo</h6> -. - -More than six `#` characters is not a header: - -. -####### foo -. -<p>####### foo</p> -. - -A space is required between the `#` characters and the header's -contents. Note that many implementations currently do not require -the space. However, the space was required by the [original ATX -implementation](http://www.aaronsw.com/2002/atx/atx.py), and it helps -prevent things like the following from being parsed as headers: - -. -#5 bolt -. -<p>#5 bolt</p> -. - -This is not a header, because the first `#` is escaped: - -. -\## foo -. -<p>## foo</p> -. - -Contents are parsed as inlines: - -. -# foo *bar* \*baz\* -. -<h1>foo <em>bar</em> *baz*</h1> -. - -Leading and trailing blanks are ignored in parsing inline content: - -. -# foo -. -<h1>foo</h1> -. - -One to three spaces indentation are allowed: - -. - ### foo - ## foo - # foo -. -<h3>foo</h3> -<h2>foo</h2> -<h1>foo</h1> -. - -Four spaces are too much: - -. - # foo -. -<pre><code># foo -</code></pre> -. - -. -foo - # bar -. -<p>foo -# bar</p> -. - -A closing sequence of `#` characters is optional: - -. -## foo ## - ### bar ### -. -<h2>foo</h2> -<h3>bar</h3> -. - -It need not be the same length as the opening sequence: - -. -# foo ################################## -##### foo ## -. -<h1>foo</h1> -<h5>foo</h5> -. - -Spaces are allowed after the closing sequence: - -. -### foo ### -. -<h3>foo</h3> -. - -A sequence of `#` characters with a nonspace character following it -is not a closing sequence, but counts as part of the contents of the -header: - -. -### foo ### b -. -<h3>foo ### b</h3> -. - -Backslash-escaped `#` characters do not count as part -of the closing sequence: - -. -### foo \### -## foo \#\## -# foo \# -. -<h3>foo #</h3> -<h2>foo ##</h2> -<h1>foo #</h1> -. - -ATX headers need not be separated from surrounding content by blank -lines, and they can interrupt paragraphs: - -. -**** -## foo -**** -. -<hr /> -<h2>foo</h2> -<hr /> -. - -. -Foo bar -# baz -Bar foo -. -<p>Foo bar</p> -<h1>baz</h1> -<p>Bar foo</p> -. - -ATX headers can be empty: - -. -## -# -### ### -. -<h2></h2> -<h1></h1> -<h3></h3> -. - -## Setext headers - -A [setext header](#setext-header) <a id="setext-header"></a> -consists of a line of text, containing at least one nonspace character, -with no more than 3 spaces indentation, followed by a [setext header -underline](#setext-header-underline). A [setext header -underline](#setext-header-underline) <a id="setext-header-underline"></a> -is a sequence of `=` characters or a sequence of `-` characters, with no -more than 3 spaces indentation and any number of trailing -spaces. The header is a level 1 header if `=` characters are used, and -a level 2 header if `-` characters are used. The contents of the header -are the result of parsing the first line as Markdown inline content. - -In general, a setext header need not be preceded or followed by a -blank line. However, it cannot interrupt a paragraph, so when a -setext header comes after a paragraph, a blank line is needed between -them. - -Simple examples: - -. -Foo *bar* -========= - -Foo *bar* ---------- -. -<h1>Foo <em>bar</em></h1> -<h2>Foo <em>bar</em></h2> -. - -The underlining can be any length: - -. -Foo -------------------------- - -Foo -= -. -<h2>Foo</h2> -<h1>Foo</h1> -. - -The header content can be indented up to three spaces, and need -not line up with the underlining: - -. - Foo ---- - - Foo ------ - - Foo - === -. -<h2>Foo</h2> -<h2>Foo</h2> -<h1>Foo</h1> -. - -Four spaces indent is too much: - -. - Foo - --- - - Foo ---- -. -<pre><code>Foo ---- - -Foo -</code></pre> -<hr /> -. - -The setext header underline can be indented up to three spaces, and -may have trailing spaces: - -. -Foo - ---- -. -<h2>Foo</h2> -. - -Four spaces is too much: - -. -Foo - --- -. -<p>Foo ----</p> -. - -The setext header underline cannot contain internal spaces: - -. -Foo -= = - -Foo ---- - -. -<p>Foo -= =</p> -<p>Foo</p> -<hr /> -. - -Trailing spaces in the content line do not cause a line break: - -. -Foo ------ -. -<h2>Foo</h2> -. - -Nor does a backslash at the end: - -. -Foo\ ----- -. -<h2>Foo\</h2> -. - -Since indicators of block structure take precedence over -indicators of inline structure, the following are setext headers: - -. -`Foo ----- -` - -<a title="a lot ---- -of dashes"/> -. -<h2>`Foo</h2> -<p>`</p> -<h2><a title="a lot</h2> -<p>of dashes"/></p> -. - -The setext header underline cannot be a lazy line: - -. -> Foo ---- -. -<blockquote> -<p>Foo</p> -</blockquote> -<hr /> -. - -A setext header cannot interrupt a paragraph: - -. -Foo -Bar ---- - -Foo -Bar -=== -. -<p>Foo -Bar</p> -<hr /> -<p>Foo -Bar -===</p> -. - -But in general a blank line is not required before or after: - -. ---- -Foo ---- -Bar ---- -Baz -. -<hr /> -<h2>Foo</h2> -<h2>Bar</h2> -<p>Baz</p> -. - -Setext headers cannot be empty: - -. - -==== -. -<p>====</p> -. - - -## Indented code blocks - -An [indented code block](#indented-code-block) -<a id="indented-code-block"></a> is composed of one or more -[indented chunks](#indented-chunk) separated by blank lines. -An [indented chunk](#indented-chunk) <a id="indented-chunk"></a> -is a sequence of non-blank lines, each indented four or more -spaces. An indented code block cannot interrupt a paragraph, so -if it occurs before or after a paragraph, there must be an -intervening blank line. The contents of the code block are -the literal contents of the lines, including trailing newlines, -minus four spaces of indentation. An indented code block has no -attributes. - -. - a simple - indented code block -. -<pre><code>a simple - indented code block -</code></pre> -. - -The contents are literal text, and do not get parsed as Markdown: - -. - <a/> - *hi* - - - one -. -<pre><code><a/> -*hi* - -- one -</code></pre> -. - -Here we have three chunks separated by blank lines: - -. - chunk1 - - chunk2 - - - - chunk3 -. -<pre><code>chunk1 - -chunk2 - - - -chunk3 -</code></pre> -. - -Any initial spaces beyond four will be included in the content, even -in interior blank lines: - -. - chunk1 - - chunk2 -. -<pre><code>chunk1 - - chunk2 -</code></pre> -. - -An indented code block cannot interrupt a paragraph. (This -allows hanging indents and the like.) - -. -Foo - bar - -. -<p>Foo -bar</p> -. - -However, any non-blank line with fewer than four leading spaces ends -the code block immediately. So a paragraph may occur immediately -after indented code: - -. - foo -bar -. -<pre><code>foo -</code></pre> -<p>bar</p> -. - -And indented code can occur immediately before and after other kinds of -blocks: - -. -# Header - foo -Header ------- - foo ----- -. -<h1>Header</h1> -<pre><code>foo -</code></pre> -<h2>Header</h2> -<pre><code>foo -</code></pre> -<hr /> -. - -The first line can be indented more than four spaces: - -. - foo - bar -. -<pre><code> foo -bar -</code></pre> -. - -Blank lines preceding or following an indented code block -are not included in it: - -. - - - foo - - -. -<pre><code>foo -</code></pre> -. - -Trailing spaces are included in the code block's content: - -. - foo -. -<pre><code>foo -</code></pre> -. - - -## Fenced code blocks - -A [code fence](#code-fence) <a id="code-fence"></a> is a sequence -of at least three consecutive backtick characters (`` ` ``) or -tildes (`~`). (Tildes and backticks cannot be mixed.) -A [fenced code block](#fenced-code-block) <a id="fenced-code-block"></a> -begins with a code fence, indented no more than three spaces. - -The line with the opening code fence may optionally contain some text -following the code fence; this is trimmed of leading and trailing -spaces and called the [info string](#info-string). -<a id="info-string"></a> The info string may not contain any backtick -characters. (The reason for this restriction is that otherwise -some inline code would be incorrectly interpreted as the -beginning of a fenced code block.) - -The content of the code block consists of all subsequent lines, until -a closing [code fence](#code-fence) of the same type as the code block -began with (backticks or tildes), and with at least as many backticks -or tildes as the opening code fence. If the leading code fence is -indented N spaces, then up to N spaces of indentation are removed from -each line of the content (if present). (If a content line is not -indented, it is preserved unchanged. If it is indented less than N -spaces, all of the indentation is removed.) - -The closing code fence may be indented up to three spaces, and may be -followed only by spaces, which are ignored. If the end of the -containing block (or document) is reached and no closing code fence -has been found, the code block contains all of the lines after the -opening code fence until the end of the containing block (or -document). (An alternative spec would require backtracking in the -event that a closing code fence is not found. But this makes parsing -much less efficient, and there seems to be no real down side to the -behavior described here.) - -A fenced code block may interrupt a paragraph, and does not require -a blank line either before or after. - -The content of a code fence is treated as literal text, not parsed -as inlines. The first word of the info string is typically used to -specify the language of the code sample, and rendered in the `class` -attribute of the `code` tag. However, this spec does not mandate any -particular treatment of the info string. - -Here is a simple example with backticks: - -. -``` -< - > -``` -. -<pre><code>< - > -</code></pre> -. - -With tildes: - -. -~~~ -< - > -~~~ -. -<pre><code>< - > -</code></pre> -. - -The closing code fence must use the same character as the opening -fence: - -. -``` -aaa -~~~ -``` -. -<pre><code>aaa -~~~ -</code></pre> -. - -. -~~~ -aaa -``` -~~~ -. -<pre><code>aaa -``` -</code></pre> -. - -The closing code fence must be at least as long as the opening fence: - -. -```` -aaa -``` -`````` -. -<pre><code>aaa -``` -</code></pre> -. - -. -~~~~ -aaa -~~~ -~~~~ -. -<pre><code>aaa -~~~ -</code></pre> -. - -Unclosed code blocks are closed by the end of the document: - -. -``` -. -<pre><code></code></pre> -. - -. -````` - -``` -aaa -. -<pre><code> -``` -aaa -</code></pre> -. - -A code block can have all empty lines as its content: - -. -``` - - -``` -. -<pre><code> - -</code></pre> -. - -A code block can be empty: - -. -``` -``` -. -<pre><code></code></pre> -. - -Fences can be indented. If the opening fence is indented, -content lines will have equivalent opening indentation removed, -if present: - -. - ``` - aaa -aaa -``` -. -<pre><code>aaa -aaa -</code></pre> -. - -. - ``` -aaa - aaa -aaa - ``` -. -<pre><code>aaa -aaa -aaa -</code></pre> -. - -. - ``` - aaa - aaa - aaa - ``` -. -<pre><code>aaa - aaa -aaa -</code></pre> -. - -Four spaces indentation produces an indented code block: - -. - ``` - aaa - ``` -. -<pre><code>``` -aaa -``` -</code></pre> -. - -Code fences (opening and closing) cannot contain internal spaces: - -. -``` ``` -aaa -. -<p><code></code> -aaa</p> -. - -. -~~~~~~ -aaa -~~~ ~~ -. -<pre><code>aaa -~~~ ~~ -</code></pre> -. - -Fenced code blocks can interrupt paragraphs, and can be followed -directly by paragraphs, without a blank line between: - -. -foo -``` -bar -``` -baz -. -<p>foo</p> -<pre><code>bar -</code></pre> -<p>baz</p> -. - -Other blocks can also occur before and after fenced code blocks -without an intervening blank line: - -. -foo ---- -~~~ -bar -~~~ -# baz -. -<h2>foo</h2> -<pre><code>bar -</code></pre> -<h1>baz</h1> -. - -An [info string](#info-string) can be provided after the opening code fence. -Opening and closing spaces will be stripped, and the first word, prefixed -with `language-`, is used as the value for the `class` attribute of the -`code` element within the enclosing `pre` element. - -. -```ruby -def foo(x) - return 3 -end -``` -. -<pre><code class="language-ruby">def foo(x) - return 3 -end -</code></pre> -. - -. -~~~~ ruby startline=3 $%@#$ -def foo(x) - return 3 -end -~~~~~~~ -. -<pre><code class="language-ruby">def foo(x) - return 3 -end -</code></pre> -. - -. -````; -```` -. -<pre><code class="language-;"></code></pre> -. - -Info strings for backtick code blocks cannot contain backticks: - -. -``` aa ``` -foo -. -<p><code>aa</code> -foo</p> -. - -Closing code fences cannot have info strings: - -. -``` -``` aaa -``` -. -<pre><code>``` aaa -</code></pre> -. - - -## HTML blocks - -An [HTML block tag](#html-block-tag) <a id="html-block-tag"></a> is -an [open tag](#open-tag) or [closing tag](#closing-tag) whose tag -name is one of the following (case-insensitive): -`article`, `header`, `aside`, `hgroup`, `blockquote`, `hr`, `iframe`, -`body`, `li`, `map`, `button`, `object`, `canvas`, `ol`, `caption`, -`output`, `col`, `p`, `colgroup`, `pre`, `dd`, `progress`, `div`, -`section`, `dl`, `table`, `td`, `dt`, `tbody`, `embed`, `textarea`, -`fieldset`, `tfoot`, `figcaption`, `th`, `figure`, `thead`, `footer`, -`footer`, `tr`, `form`, `ul`, `h1`, `h2`, `h3`, `h4`, `h5`, `h6`, -`video`, `script`, `style`. - -An [HTML block](#html-block) <a id="html-block"></a> begins with an -[HTML block tag](#html-block-tag), [HTML comment](#html-comment), -[processing instruction](#processing-instruction), -[declaration](#declaration), or [CDATA section](#cdata-section). -It ends when a [blank line](#blank-line) or the end of the -input is encountered. The initial line may be indented up to three -spaces, and subsequent lines may have any indentation. The contents -of the HTML block are interpreted as raw HTML, and will not be escaped -in HTML output. - -Some simple examples: - -. -<table> - <tr> - <td> - hi - </td> - </tr> -</table> - -okay. -. -<table> - <tr> - <td> - hi - </td> - </tr> -</table> -<p>okay.</p> -. - -. - <div> - *hello* - <foo><a> -. - <div> - *hello* - <foo><a> -. - -Here we have two code blocks with a Markdown paragraph between them: - -. -<DIV CLASS="foo"> - -*Markdown* - -</DIV> -. -<DIV CLASS="foo"> -<p><em>Markdown</em></p> -</DIV> -. - -In the following example, what looks like a Markdown code block -is actually part of the HTML block, which continues until a blank -line or the end of the document is reached: - -. -<div></div> -``` c -int x = 33; -``` -. |