diff options
| -rw-r--r-- | changelog.txt | 35 | ||||
| -rw-r--r-- | spec.txt | 35 |
2 files changed, 62 insertions, 8 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: @@ -5802,6 +5811,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 @@ -5851,19 +5869,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. @@ -5983,7 +6002,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 |