Age | Commit message (Collapse) | Author |
|
two empty lines no longer end any list context (unfortunately)
|
|
|
|
|
|
Closes #526.
|
|
Closes #563.
|
|
Note that `openers_bottom` needs to be indexed to
delimiter run lengths as well as types.
Closes #563.
|
|
The "not separated by more than one blank line" was a left-over
from an earlier version of the spec in which two blank lines
ended a list.
Closes #543.
|
|
We disallow backticks in info strings after backtick fences
only. Both backticks and tildes are allowed in info strings
after tilde fences. Added example.
Closes #119.
|
|
* make_spec.lua: rename children to child
Naming a variable "children" when it holds one child is confusing, and blocks
naming actual children.
* make_spec.lua: fix migration of children nodes in create_anchors
Prior to this commit, when migrating the children of a node to a new one,
children are moved as they are iterated via `cmark_node_next`; however, when a
child is moved under the new node, its next relationship with its sibling is
broken, so in fact at most one child is migrated, and the rest are lost. This
resulted in cases like
[Decimal numeric character
references](@)
consist of...
(note the softbreak) being eventually rendered as
<a ...>Decimal numeric character</a>
consist of...
|
|
Prior to this commit, the link opened is always `/dingus/?text=` (no text),
because `$(this)` is `code.language-markdown`, so `.find`ing `code` in its
descendants turns up nothing.
|
|
|
|
Closes #469.
|
|
* Clarify the left- and right-flanking definitions
A few more words make the definitions easier to understand, without changing the meaning.
Links to the current definitions:
- [left-flanking delimiter run](https://github.github.com/gfm/#left-flanking-delimiter-run)
- [right-flanking delimiter run](https://github.github.com/gfm/#right-flanking-delimiter-run)
* Change numbering to 1, 2a and 2b
1, 2a and 2b is more conventional than a, b1 and b2, which I suggested earlier.
|
|
|
|
Removed the complex rule about ignoring newlines adjacent
to spaces. Now newlines are simply converted to spaces.
|
|
Closes #532.
|
|
pluralization (#531)
|
|
...in start condition #6 of HTML blocks. meta tags are used
in some inline contexts (though this isn't valid HTML5), e.g.
in schema.org. Example:
```
This paragraph is closed right after an opening span:
<span itemprop="contentLocation" itemscope itemtype="https://schema.org/City">
<meta itemprop="name" content="Springfield">
<span itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
<meta itemprop="addressCountry" content="US">
<span itemprop="addressLocality">Springfield</span>,
<span itemprop="addressRegion">Oregon</span>
<meta itemprop="postalCode" content="97477">
</span>
</span>
```
Closes #527.
|
|
|
|
|
|
|
|
Based on https://talk.commonmark.org/t/suggestion-of-a-new-example-to-be-put-on-the-specs/2646
|
|
|
|
Closes #480.
|
|
This is all that is needed given the upper bound on
unicode code points.
Closes commonmark/CommonMark#487.
|
|
This reverts a change in 0.24 and should make things easier
for people working with image paths containing spaces.
Closes #503.
|
|
The tests did not accord with the spec here; these
lines should be continuation lines (if no blank space)
or indented code blocks (if blank space).
Closes #497.
|
|
two empty lines no longer end any list context (unfortunately)
|
|
|
|
|
|
* Info string is trimmed of all whitespace
As noted in https://github.com/github/cmark/issues/60, the info string is not
only trimmed of "spaces" (U+0020) but indeed all whitespace. Update the spec to
reflect this.
* "spaces" => "spaces or tabs" after thematic breaks
|
|
as per HTML spec. cf:
https://html.spec.whatwg.org/multipage/syntax.html#unquoted
|
|
|
|
Update GitHub links
|
|
It appears that the repositories have been moved to a GitHub
organization. This fixes the links to CommonMark, cmark and
commonmark.js repositories.
|
|
Add spec.json generator to Makefile
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Clarify HTML blocks re: "nested" blocks
|
|
Say explicitly that normalization involves stripping off
leading and trailing bracket characters, before stripping
leading and trailing whitespace.
See #479.
|
|
|
|
Mention removing surrounding whitespace from link labels
|
|
|
|
Clarify precedence of thematic break
|
|
|