diff options
| -rw-r--r-- | changelog.txt | 35 | ||||
| -rw-r--r-- | spec.txt | 52 |
2 files changed, 73 insertions, 14 deletions
diff --git a/changelog.txt b/changelog.txt index 4ba1783..6881c13 100644 --- a/changelog.txt +++ b/changelog.txt @@ -1,3 +1,38 @@ +[0.28] + + * Allow unlimited balanced pairs of parentheses in link URLs + (@kivikakk, jgm/cmark#166). The rationale is that there are many URLs + containing unescaped nested parentheses. + * Change Rule 14 for Emphasis. Previously the nesting + Strong (Emph (...)) was preferred over Emph (Strong (...)). + This change makes Emph (Strong (...)) preferred. + Note that the commonmark reference implementations + were not entirely consistent about this rule, giving + different results for + + ***hi*** + + and + + ***hi**** + + This change simplifies parsing. It goes against the majority + of implementations, but only on something utterly trivial. + * Acknowledge Aaron Swartz's role in developing Markdown. + * Remove misleading backslash in example for disabling image markup + (Matthias Geier). + * Fix Unicode terminology (general category, not class) + (Philipp Matthias Schaefer). + * Add another illustrative case for code spans (#463). + * Remove possibly misleading 'either's (#467). + * Fix typo (Aidan Woods). + * Clarify that some blocks can contain code spans (Matthias Geier). + * Fix typo and clarified tab expansion rule (Scott Abbey). + * Add a missing "iff" (Matthias Geier). + * Add release checklist. + * Added npm package for spec (Vitaly Puzrin). + * Remove SPEC variable from Makefile. + [0.27] * Update statement on blank lines and lists (Jesse Rosenthal). @@ -1,8 +1,8 @@ --- title: CommonMark Spec author: John MacFarlane -version: 0.27 -date: '2016-11-18' +version: 0.28 +date: '2017-08-01' license: '[CC-BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/)' ... @@ -483,7 +483,7 @@ We can think of a document as a sequence of quotations, lists, headings, rules, and code blocks. Some blocks (like block quotes and list items) contain other blocks; others (like headings and paragraphs) contain [inline](@) content---text, -links, emphasized text, images, code, and so on. +links, emphasized text, images, code spans, and so on. ## Precedence @@ -1645,6 +1645,15 @@ With tildes: </code></pre> ```````````````````````````````` +Fewer than three backticks is not enough: + +```````````````````````````````` example +`` +foo +`` +. +<p><code>foo</code></p> +```````````````````````````````` The closing code fence must use the same character as the opening fence: @@ -3670,11 +3679,15 @@ The following rules define [list items]: If the list item is ordered, then it is also assigned a start number, based on the ordered list marker. - Exceptions: When the first list item in a [list] interrupts - a paragraph---that is, when it starts on a line that would - otherwise count as [paragraph continuation text]---then (a) - the lines *Ls* must not begin with a blank line, and (b) if - the list item is ordered, the start number must be 1. + Exceptions: + + 1. When the first list item in a [list] interrupts + a paragraph---that is, when it starts on a line that would + otherwise count as [paragraph continuation text]---then (a) + the lines *Ls* must not begin with a blank line, and (b) if + the list item is ordered, the start number must be 1. + 2. If any line is a [thematic break][thematic breaks] then + that line is not a list item. For example, let *Ls* be the lines @@ -5829,6 +5842,15 @@ we just have literal backticks: <p>`foo</p> ```````````````````````````````` +The following case also illustrates the need for opening and +closing backtick strings to be equal in length: + +```````````````````````````````` example +`foo``bar`` +. +<p>`foo<code>bar</code></p> +```````````````````````````````` + ## Emphasis and strong emphasis @@ -5878,19 +5900,20 @@ for efficient parsing strategies that do not backtrack. First, some definitions. A [delimiter run](@) is either a sequence of one or more `*` characters that is not preceded or -followed by a `*` character, or a sequence of one or more `_` -characters that is not preceded or followed by a `_` character. +followed by a non-backslash-escaped `*` character, or a sequence +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) either not followed by a [punctuation character], or +and (b) not followed by a [punctuation character], or 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) either not preceded by a [punctuation character], or +and (b) not preceded by a [punctuation character], or 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. @@ -6010,7 +6033,7 @@ the following principles resolve ambiguity: `<em><em>...</em></em>`. 14. An interpretation `<em><strong>...</strong></em>` is always - preferred to `<strong><em>..</em></strong>`. + preferred to `<strong><em>...</em></strong>`. 15. When two potential emphasis or strong emphasis spans overlap, so that the second begins before the first ends and ends after @@ -7599,7 +7622,8 @@ characters inside the square brackets. One label [matches](@) another just in case their normalized forms are equal. To normalize a -label, perform the *Unicode case fold* and collapse consecutive internal +label, perform the *Unicode case fold*, strip leading and trailing +[whitespace] and collapse consecutive internal [whitespace] to a single space. If there are multiple matching reference link definitions, the one that comes first in the document is used. (It is desirable in such cases to emit a warning.) |