Age | Commit message (Collapse) | Author |
|
|
|
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.
|
|
|
|
* 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
|
|
|
|
|
|
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
|
|
|
|
|
|
Add fenced code block example with not enough backticks.
|
|
|
|
Clarify definition of delimiter run
|
|
|
|
|
|
run of `*` or `_` respectively
|
|
Closes jgm/CommonMark#463.
|
|
These are sometimes interpreted as XOR (and that isn't meant
in this case).
Closes jgm/CommonMark#467.
|
|
|
|
|
|
|
|
|
|
There already exists the statement: "When both a thematic break and a list item are possible
interpretations of a line, the thematic break takes precedence".
This adjustment ensures that this precedence is achieved by the list item definition.
|
|
I guess this would have passed a spell checker since *theses* is the plural of *thesis*.
Listing the number of spaces the first tab is expanded into reduces the cognitive load required to figure out why the next line talks about six spaces.
|
|
|
|
|
|
|
|
Escaping `[` disables the markup, escaping `!` on top of that doesn't
change anything and is therefore misleading in this example.
|
|
|
|
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.
|
|
See #166. The rationale is that there are many URLs containing
unescaped nested parentheses.
|
|
|