| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
See jgm/commonmark.js#60.
|
|
This makes sure that implementations skip columns instead of offsets for
continued indented code blocks.
Background: I was implementing the new tab logic and was surprised that
all the spec tests passed even though I hadn't changed the continuation
logic of indented code blocks to skip columns. The added example checks
this.
|
|
It's already listed in alphabetical order on the next line.
|
|
|
|
|
|
|
|
|
|
|
|
Intent is to avoid problems with overflows.
See
http://talk.commonmark.org/t/what-is-or-what-should-be-the-range-of-indices-of-ordered-list-items/1249
Some browsers use signed 32-bit integers for indexing
the items of an ordered list, and this can lead to odd
or undefined behavior if 10-digit start numbers are allowed.
|
|
Added description of emphasis/link parsing algorithm.
|
|
This, together with previous changes in HTML block spec,
closes #239.
|
|
|
|
Not just end of the document. (Parallel to fenced code blocks.)
|
|
Insides weren't escaped properly.
|
|
|
|
Rectify omission of line tabulation, U+000B.
Closes #343.
|
|
Closes #346.
|
|
Closes #347.
Thanks for pointing this out.
We might want to revisit the decision to allow a list to
interrupt a paragraph. It's a minority opinion:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=Text+text%0A-+one%0A-+two%0A
And, in fact, in our initial discussions I was pretty strongly
opposed to it. Others felt strongly that people would naturally
create lists this way, and that it should be allowed. Some of
this is sumarized here:
http://talk.commonmark.org/t/requiring-a-blank-line-between-a-paragraph-and-list/657
The thread is a bit noisy but the point that sways me most is here:
http://talk.commonmark.org/t/requiring-a-blank-line-between-a-paragraph-and-list/657/13?u=jgm
|
|
|
|
|
|
|
|
Rename "non-space" to "non-whitespace"
|
