summaryrefslogtreecommitdiff
path: root/test/spec.txt
diff options
context:
space:
mode:
Diffstat (limited to 'test/spec.txt')
-rw-r--r--test/spec.txt298
1 files changed, 208 insertions, 90 deletions
diff --git a/test/spec.txt b/test/spec.txt
index 9fd5841..91551e5 100644
--- a/test/spec.txt
+++ b/test/spec.txt
@@ -514,8 +514,8 @@ 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 block](@)s,
-which can contain other blocks, and [leaf block](@)s,
+[container blocks](@),
+which can contain other blocks, and [leaf blocks](@),
which cannot.
# Leaf blocks
@@ -527,7 +527,7 @@ Markdown document.
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
+optionally by any number of spaces or tabs, forms a
[thematic break](@).
```````````````````````````````` example
@@ -1584,8 +1584,8 @@ 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](@).
-The [info string] may not contain any backtick
+whitespace and called the [info string](@). If the [info string] comes
+after a backtick fence, it 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.)
@@ -1973,6 +1973,18 @@ foo</p>
````````````````````````````````
+[Info strings] for tilde code blocks can contain backticks and tildes:
+
+```````````````````````````````` example
+~~~ aa ``` ~~~
+foo
+~~~
+.
+<pre><code class="language-aa">foo
+</code></pre>
+````````````````````````````````
+
+
Closing code fences cannot have [info strings]:
```````````````````````````````` example
@@ -1996,9 +2008,10 @@ by their start and end conditions. The block begins with a line that
meets a [start condition](@) (after up to three spaces
optional indentation). It ends with the first subsequent line that
meets a matching [end condition](@), or the last line of
-the document or other [container block]), if no line is encountered that meets the
-[end condition]. If the first line meets both the [start condition]
-and the [end condition], the block will contain just that line.
+the document or other [container block](#container-blocks)), if no
+line is encountered that meets the [end condition]. If the first line
+meets both the [start condition] and the [end condition], the block
+will contain just that line.
1. **Start condition:** line begins with the string `<script`,
`<pre`, or `<style` (case-insensitive), followed by whitespace,
@@ -2029,7 +2042,7 @@ followed by one of the strings (case-insensitive) `address`,
`footer`, `form`, `frame`, `frameset`,
`h1`, `h2`, `h3`, `h4`, `h5`, `h6`, `head`, `header`, `hr`,
`html`, `iframe`, `legend`, `li`, `link`, `main`, `menu`, `menuitem`,
-`meta`, `nav`, `noframes`, `ol`, `optgroup`, `option`, `p`, `param`,
+`nav`, `noframes`, `ol`, `optgroup`, `option`, `p`, `param`,
`section`, `source`, `summary`, `table`, `tbody`, `td`,
`tfoot`, `th`, `thead`, `title`, `tr`, `track`, `ul`, followed
by [whitespace], the end of the line, the string `>`, or
@@ -2043,10 +2056,11 @@ or the end of the line.\
**End condition:** line is followed by a [blank line].
HTML blocks continue until they are closed by their appropriate
-[end condition], or the last line of the document or other [container block].
-This means any HTML **within an HTML block** that might otherwise be recognised
-as a start condition will be ignored by the parser and passed through as-is,
-without changing the parser's state.
+[end condition], or the last line of the document or other [container
+block](#container-blocks). This means any HTML **within an HTML
+block** that might otherwise be recognised as a start condition will
+be ignored by the parser and passed through as-is, without changing
+the parser's state.
For instance, `<pre>` within a HTML block started by `<table>` will not affect
the parser state; as the HTML block was started in by start condition 6, it
@@ -2069,7 +2083,7 @@ _world_.
</td></tr></table>
````````````````````````````````
-In this case, the HTML block is terminated by the newline — the `**hello**`
+In this case, the HTML block is terminated by the newline — the `**Hello**`
text remains verbatim — and regular parsing resumes, with a paragraph,
emphasised `world` and inline and block HTML following.
@@ -2612,7 +2626,8 @@ bar
However, a following blank line is needed, except at the end of
-a document, and except for blocks of types 1--5, above:
+a document, and except for blocks of types 1--5, [above][HTML
+block]:
```````````````````````````````` example
<div>
@@ -2758,8 +2773,8 @@ an indented code block:
Fortunately, blank lines are usually not necessary and can be
deleted. The exception is inside `<pre>` tags, but as described
-above, raw HTML blocks starting with `<pre>` *can* contain blank
-lines.
+[above][HTML blocks], raw HTML blocks starting with `<pre>`
+*can* contain blank lines.
## Link reference definitions
@@ -2811,7 +2826,7 @@ them.
```````````````````````````````` example
[Foo bar]:
-<my%20url>
+<my url>
'title'
[Foo bar]
@@ -2877,6 +2892,18 @@ The link destination may not be omitted:
<p>[foo]</p>
````````````````````````````````
+The title must be separated from the link destination by
+whitespace:
+
+```````````````````````````````` example
+[foo]: <bar>(baz)
+
+[foo]
+.
+<p>[foo]: <bar>(baz)</p>
+<p>[foo]</p>
+````````````````````````````````
+
Both title and destination can contain backslash escapes
and literal backslashes:
@@ -3207,7 +3234,7 @@ aaa
# Container blocks
-A [container block] is a block that has other
+A [container block](#container-blocks) is a block that has other
blocks as its contents. There are two basic kinds of container blocks:
[block quotes] and [list items].
[Lists] are meta-containers for [list items].
@@ -3669,9 +3696,8 @@ in some browsers.)
The following rules define [list items]:
1. **Basic case.** If a sequence of lines *Ls* constitute a sequence of
- blocks *Bs* starting with a [non-whitespace character] and not separated
- from each other by more than one blank line, and *M* is a list
- marker of width *W* followed by 1 ≤ *N* ≤ 4 spaces, then the result
+ blocks *Bs* starting with a [non-whitespace character], and *M* is a
+ list marker of width *W* followed by 1 ≤ *N* ≤ 4 spaces, then the result
of prepending *M* and the following spaces to the first line of
*Ls*, and indenting subsequent lines of *Ls* by *W + N* spaces, is a
list item with *Bs* as its contents. The type of the list item
@@ -3981,8 +4007,7 @@ A start number may not be negative:
2. **Item starting with indented code.** If a sequence of lines *Ls*
constitute a sequence of blocks *Bs* starting with an indented code
- block and not separated from each other by more than one blank line,
- and *M* is a list marker of width *W* followed by
+ block, and *M* is a list marker of width *W* followed by
one space, then the result of prepending *M* and the following
space to the first line of *Ls*, and indenting subsequent lines of
*Ls* by *W + 1* spaces, is a list item with *Bs* as its contents.
@@ -4458,9 +4483,10 @@ continued here.</p>
6. **That's all.** Nothing that is not counted as a list item by rules
#1--5 counts as a [list item](#list-items).
-The rules for sublists follow from the general rules above. A sublist
-must be indented the same number of spaces a paragraph would need to be
-in order to be included in the list item.
+The rules for sublists follow from the general rules
+[above][List items]. A sublist must be indented the same number
+of spaces a paragraph would need to be in order to be included
+in the list item.
So, in this case we need two spaces indent:
@@ -5049,11 +5075,9 @@ item:
- b
- c
- d
- - e
- - f
- - g
- - h
-- i
+ - e
+ - f
+- g
.
<ul>
<li>a</li>
@@ -5063,8 +5087,6 @@ item:
<li>e</li>
<li>f</li>
<li>g</li>
-<li>h</li>
-<li>i</li>
</ul>
````````````````````````````````
@@ -5074,7 +5096,7 @@ item:
2. b
- 3. c
+ 3. c
.
<ol>
<li>
@@ -5089,6 +5111,49 @@ item:
</ol>
````````````````````````````````
+Note, however, that list items may not be indented more than
+three spaces. Here `- e` is treated as a paragraph continuation
+line, because it is indented more than three spaces:
+
+```````````````````````````````` example
+- a
+ - b
+ - c
+ - d
+ - e
+.
+<ul>
+<li>a</li>
+<li>b</li>
+<li>c</li>
+<li>d
+- e</li>
+</ul>
+````````````````````````````````
+
+And here, `3. c` is treated as in indented code block,
+because it is indented four spaces and preceded by a
+blank line.
+
+```````````````````````````````` example
+1. a
+
+ 2. b
+
+ 3. c
+.
+<ol>
+<li>
+<p>a</p>
+</li>
+<li>
+<p>b</p>
+</li>
+</ol>
+<pre><code>3. c
+</code></pre>
+````````````````````````````````
+
This is a loose list, because there is a blank line between
two of the list items:
@@ -5522,7 +5587,7 @@ foo
## Entity and numeric character references
All valid HTML entity references and numeric character
-references, except those occuring in code blocks and code spans,
+references, except those occurring in code blocks and code spans,
are recognized as such and treated as equivalent to the
corresponding Unicode characters. Conforming CommonMark parsers
need not store information about whether a particular character
@@ -5548,22 +5613,22 @@ references and their corresponding code points.
[Decimal numeric character
references](@)
-consist of `&#` + a string of 1--8 arabic digits + `;`. A
+consist of `&#` + a string of 1--7 arabic digits + `;`. A
numeric character reference is parsed as the corresponding
Unicode character. Invalid Unicode code points will be replaced by
the REPLACEMENT CHARACTER (`U+FFFD`). For security reasons,
the code point `U+0000` will also be replaced by `U+FFFD`.
```````````````````````````````` example
-&#35; &#1234; &#992; &#98765432; &#0;
+&#35; &#1234; &#992; &#0;
.
-<p># Ӓ Ϡ � �</p>
+<p># Ӓ Ϡ �</p>
````````````````````````````````
[Hexadecimal numeric character
references](@) consist of `&#` +
-either `X` or `x` + a string of 1-8 hexadecimal digits + `;`.
+either `X` or `x` + a string of 1-6 hexadecimal digits + `;`.
They too are parsed as the corresponding Unicode character (this
time specified with a hexadecimal numeral instead of decimal).
@@ -5578,9 +5643,13 @@ Here are some nonentities:
```````````````````````````````` example
&nbsp &x; &#; &#x;
+&#987654321;
+&#abcdef0;
&ThisIsNotDefined; &hi?;
.
<p>&amp;nbsp &amp;x; &amp;#; &amp;#x;
+&amp;#987654321;
+&amp;#abcdef0;
&amp;ThisIsNotDefined; &amp;hi?;</p>
````````````````````````````````
@@ -5669,9 +5738,15 @@ preceded nor followed by a backtick.
A [code span](@) begins with a backtick string and ends with
a backtick string of equal length. The contents of the code span are
-the characters between the two backtick strings, with leading and
-trailing spaces and [line endings] removed, and
-[whitespace] collapsed to single spaces.
+the characters between the two backtick strings, normalized in the
+following ways:
+
+- First, [line endings] are converted to [spaces].
+- If the resulting string both begins *and* ends with a [space]
+ character, a single [space] character is removed from the
+ front and back. This allows you to include code that begins
+ or ends with backtick characters, which must be separated by
+ whitespace from the opening or closing backtick strings.
This is a simple code span:
@@ -5683,10 +5758,11 @@ This is a simple code span:
Here two backticks are used, because the code contains a backtick.
-This example also illustrates stripping of leading and trailing spaces:
+This example also illustrates stripping of a single leading and
+trailing space:
```````````````````````````````` example
-`` foo ` bar ``
+`` foo ` bar ``
.
<p><code>foo ` bar</code></p>
````````````````````````````````
@@ -5701,58 +5777,69 @@ spaces:
<p><code>``</code></p>
````````````````````````````````
-
-[Line endings] are treated like spaces:
+Note that only *one* space is stripped:
```````````````````````````````` example
-``
-foo
-``
+` `` `
.
-<p><code>foo</code></p>
+<p><code> `` </code></p>
````````````````````````````````
+The stripping only happens if the space is on both
+sides of the string:
+
+```````````````````````````````` example
+` a`
+.
+<p><code> a</code></p>
+````````````````````````````````
-Interior spaces and [line endings] are collapsed into
-single spaces, just as they would be by a browser:
+Only [spaces], and not [unicode whitespace] in general, are
+stripped in this way:
```````````````````````````````` example
-`foo bar
- baz`
+` b `
.
-<p><code>foo bar baz</code></p>
+<p><code> b </code></p>
````````````````````````````````
-Not all [Unicode whitespace] (for instance, non-breaking space) is
-collapsed, however:
+[Line endings] are treated like spaces:
```````````````````````````````` example
-`a  b`
+``
+foo
+bar
+baz
+``
.
-<p><code>a  b</code></p>
+<p><code>foo bar baz</code></p>
````````````````````````````````
+```````````````````````````````` example
+``
+foo
+``
+.
+<p><code>foo </code></p>
+````````````````````````````````
-Q: Why not just leave the spaces, since browsers will collapse them
-anyway? A: Because we might be targeting a non-HTML format, and we
-shouldn't rely on HTML-specific rendering assumptions.
-(Existing implementations differ in their treatment of internal
-spaces and [line endings]. Some, including `Markdown.pl` and
-`showdown`, convert an internal [line ending] into a
-`<br />` tag. But this makes things difficult for those who like to
-hard-wrap their paragraphs, since a line break in the midst of a code
-span will cause an unintended line break in the output. Others just
-leave internal spaces as they are, which is fine if only HTML is being
-targeted.)
+Interior spaces are not collapsed:
```````````````````````````````` example
-`foo `` bar`
+`foo bar
+baz`
.
-<p><code>foo `` bar</code></p>
+<p><code>foo bar baz</code></p>
````````````````````````````````
+Note that browsers will typically collapse consecutive spaces
+when rendering `<code>` elements, so it is recommended that
+the following CSS be used:
+
+ code{white-space: pre-wrap;}
+
Note that backslash escapes do not work in code spans. All backslashes
are treated literally:
@@ -5768,6 +5855,19 @@ Backslash escapes are never needed, because one can always choose a
string of *n* backtick characters as delimiters, where the code does
not contain any strings of exactly *n* backtick characters.
+```````````````````````````````` example
+``foo`bar``
+.
+<p><code>foo`bar</code></p>
+````````````````````````````````
+
+```````````````````````````````` example
+` foo `` bar `
+.
+<p><code>foo `` bar</code></p>
+````````````````````````````````
+
+
Code span backticks have higher precedence than any other inline
constructs except HTML tags and autolinks. Thus, for example, this is
not parsed as emphasized text, since the second `*` is part of a code
@@ -5905,15 +6005,17 @@ of one or more `_` characters that is not preceded or followed by
a non-backslash-escaped `_` character.
A [left-flanking delimiter run](@) is
-a [delimiter run] that is (a) not followed by [Unicode whitespace],
-and (b) not followed by a [punctuation character], or
+a [delimiter run] that is (1) not followed by [Unicode whitespace],
+and either (2a) not followed by a [punctuation character], or
+(2b) followed by a [punctuation character] and
preceded by [Unicode whitespace] or a [punctuation character].
For purposes of this definition, the beginning and the end of
the line count as Unicode whitespace.
A [right-flanking delimiter run](@) is
-a [delimiter run] that is (a) not preceded by [Unicode whitespace],
-and (b) not preceded by a [punctuation character], or
+a [delimiter run] that is (1) not preceded by [Unicode whitespace],
+and either (2a) not preceded by a [punctuation character], or
+(2b) preceded by a [punctuation character] and
followed by [Unicode whitespace] or a [punctuation character].
For purposes of this definition, the beginning and the end of
the line count as Unicode whitespace.
@@ -6636,6 +6738,17 @@ cannot form emphasis if the sum of the lengths of
the delimiter runs containing the opening and
closing delimiters is a multiple of 3.
+
+For the same reason, we don't get two consecutive
+emphasis sections in this example:
+
+```````````````````````````````` example
+*foo**bar*
+.
+<p><em>foo**bar</em></p>
+````````````````````````````````
+
+
The same condition ensures that the following
cases are all strong emphasis nested inside
emphasis, even when the interior spaces are
@@ -7198,7 +7311,7 @@ following rules apply:
A [link destination](@) consists of either
- a sequence of zero or more characters between an opening `<` and a
- closing `>` that contains no spaces, line breaks, or unescaped
+ closing `>` that contains no line breaks or unescaped
`<` or `>` characters, or
- a nonempty sequence of characters that does not include
@@ -7219,7 +7332,8 @@ A [link title](@) consists of either
backslash-escaped, or
- a sequence of zero or more characters between matching parentheses
- (`(...)`), including a `)` character only if it is backslash-escaped.
+ (`(...)`), including a `(` or `)` character only if it is
+ backslash-escaped.
Although [link titles] may span multiple lines, they may not contain
a [blank line].
@@ -7269,9 +7383,8 @@ Both the title and the destination may be omitted:
<p><a href="">link</a></p>
````````````````````````````````
-
-The destination cannot contain spaces or line breaks,
-even if enclosed in pointy brackets:
+The destination can only contain spaces if it is
+enclosed in pointy brackets:
```````````````````````````````` example
[link](/my uri)
@@ -7279,13 +7392,14 @@ even if enclosed in pointy brackets:
<p>[link](/my uri)</p>
````````````````````````````````
-
```````````````````````````````` example
[link](</my uri>)
.
-<p>[link](&lt;/my uri&gt;)</p>
+<p><a href="/my%20uri">link</a></p>
````````````````````````````````
+The destination cannot contain line breaks,
+even if enclosed in pointy brackets:
```````````````````````````````` example
[link](foo
@@ -7295,7 +7409,6 @@ bar)
bar)</p>
````````````````````````````````
-
```````````````````````````````` example
[link](<foo
bar>)
@@ -8624,7 +8737,7 @@ a [single-quoted attribute value], or a [double-quoted attribute value].
An [unquoted attribute value](@)
is a nonempty string of characters not
-including spaces, `"`, `'`, `=`, `<`, `>`, or `` ` ``.
+including [whitespace], `"`, `'`, `=`, `<`, `>`, or `` ` ``.
A [single-quoted attribute value](@)
consists of `'`, zero or more
@@ -8745,9 +8858,13 @@ Illegal [whitespace]:
```````````````````````````````` example
< a><
foo><bar/ >
+<foo bar=baz
+bim!bop />
.
<p>&lt; a&gt;&lt;
-foo&gt;&lt;bar/ &gt;</p>
+foo&gt;&lt;bar/ &gt;
+&lt;foo bar=baz
+bim!bop /&gt;</p>
````````````````````````````````
@@ -8944,10 +9061,10 @@ bar</em></p>
Line breaks do not occur inside code spans
```````````````````````````````` example
-`code
+`code
span`
.
-<p><code>code span</code></p>
+<p><code>code span</code></p>
````````````````````````````````
@@ -9365,7 +9482,8 @@ just above `stack_bottom` (or the first element if `stack_bottom`
is NULL).
We keep track of the `openers_bottom` for each delimiter
-type (`*`, `_`). Initialize this to `stack_bottom`.
+type (`*`, `_`) and each length of the closing delimiter run
+(modulo 3). Initialize this to `stack_bottom`.
Then we repeat the following until we run out of potential
closers: