| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Code block with partially consumed tab.
|
|
In the blockquote with a tab following the `>`,
only one space should be consumed, yielding two
spaces at the beginning of the content.
|
|
See jgm/cmark#101
|
|
Closes #389.
|
|
|
|
|
|
|
|
The format for the spec examples has changed from
.
markdown
.
html
.
to
```````````````````````````````` example
markdown
.
html
````````````````````````````````
One advantage of this is that `spec.txt` becomes a valid
Markdown file.
`tests/spec_test.py` has been changed to use the new format.
The old `tools/makespec.py` has been replaced by a lua
program, `tools/make_spec.lua`, which uses the `lcmark` rock
(and indirectly libcmark). It can generate
html, latex, and commonmark versions of the spec.
Pandoc is no longer needed for the latex/PDF version.
And, since the new program uses the cmark API and operates
directly on the parse tree, we avoid certain bad results we
got with the regex replacements done by the python script.
|
|
|
|
Text like
Foo
bar
---
baz
is now interpreted as heading + paragraph, rather than
paragraph + thematic break + paragraph.
Existing implementations diverge quite a bit on this
case, with several interpretations:
1. paragraph, heading, paragraph
2. paragraph, break, paragraph
3. paragraph containing literal `---`
4. heading, paragraph
Interpretation 4 seems most natural, and it opens up an expressive
possibility otherwise closed off -- multiline headings.
Authors who want interpretation 2 can use a form that can't be
interpreted as a setext heading line, e.g.
Foo
bar
* * *
baz
or insert blank space around the thematic break.
Authors who want interpretation 3 can use backslash escapes.
Authors who want interpretation 1 can put a blank line
after the first paragraph.
|
|
See discussion at
http://talk.commonmark.org/t/minor-comments-and-unclarities-after-reading-the-spec/779
http://talk.commonmark.org/t/issues-to-resolve-before-1-0-release/1287/12
|
|
The additional test ensures that URI schemes must
be more than one character.
|
|
Now a scheme is any sequence of 2-32 characters, beginning
with an ASCII letter, and containing only ASCII letters,
digits, and the symbols `-`, `+`, `.`.
Changed several spec examples accordingly.
Discussion at
http://talk.commonmark.org/t/what-is-the-point-of-limiting-uri-schemes-in-autolinks/555/26
|
|
Entity references are not treated as literal text in
raw HTML; they are just passed through.
|
|
|
|
Not "unknown code point character."
|
|
|
|
in a reference link. This fixes the problem of
inadvertent capture:
[foo] [bar]
[foo]: /u1
[bar]: /u2
|
|
Closes #325.
Worth having this example, since there was a bug to this effect.
|
|
|
|
Closes #371.
|
|
Other whitespace won't do.
Added a test case and modified an existing one to
make this clearer.
Closes #373.
|
|
|
|
Entity references and numeric character references.
Closes #375.
|
|
which were actually HTML blocks, given the changes to
block parsing rules since these examples were written.
Closes #382.
|
|
This matches the HTML5 meaning for the hr element, and
recognizes that the element may be rendered in various
ways (not always as a horizontal rule).
See http://talk.commonmark.org/t/horizontal-rule-or-thematic-break/912/3
IN the DTD hrule is renamed 'thematic_break'.
|
|
This avoids a confusion that might arise now that HTML5 has
a 'header' element, distinct from the 'headings' h1, h2, ...
Our headings correspond to HTML5 headings, not HTML5 headers.
The terminology of 'headings' is more natural, too.
The only thing going for 'header' is that John Gruber used
it in his original Markdown syntax description.
See
http://talk.commonmark.org/t/naming-of-h1-6-should-be-headings-not-headers-per-w3c/1871
|
|
This is to match cmark's output, since we test cmark
without normalization.
|
|
Reworded the description, added a case with two blank lines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See
http://talk.commonmark.org/t/raw-html-blocks-proposals-comments-wanted/983/66?u=jgm
and following comments.
Closes #352.
|
|
Closes #361.
|
|
Closes #360.
|
|
Fixes a minor grammatical error found when reading through the spec.
|
|
The previous spec allowed, technically, that a line ending
in CR NL might be considered to have two line endings,
or that the CR might be considered part of the line and the
NL the line ending. These fixes rule out those interpretations.
Closes #357. Thanks to Lasse R.H. Nielsen.
|
|
Clarified that closing `#`s must be unescaped.
Removed misleading reference to "non-whitespace character" in
example.
Closes #356.
|
|
|
|
Add an example with mixed indentation code block in "Tabs" section
|
|
It is already covered by rule 1, so this removes an ambiguity.
Closes #355.
|
|
pre, script, style are excluded because they're covered
by other rules.
|
|
Closes #332.
|
|
|
|
Closes #349.
|
