The spec update changes these things:
* It simplifies the HTML regex so that `<!-- a -- b -->` is an HTML
comment. HTML5 reports this as an error, but still parses it.
* It changes the set of known HTML block elements to match HTML5, adding
`search` and removing `source`.
* It adds Unicode Symbols to the set of punctuation characters that are
used to evaluate flankingness.
This commit also changes the declaration HTML regex to match lowercase,
even though that change was technically made in spec version 0.30.
Spec is not clear on how to handle this. Three variations exist:
```
$ echo '![text <textarea> text](image.png)' | /home/user/commonmark.js/bin/commonmark
<p><img src="image.png" alt="text <textarea> text" /></p>
$ echo '![text <textarea> text](image.png)' | /home/user/cmark/build/src/cmark
<p><img src="image.png" alt="text <textarea> text" /></p>
$ echo '![text <textarea> text](image.png)' | /home/user/.local/bin/commonmark
<p><img src="image.png" alt="text text" /></p>
```
Prior to this commit:
- when HTML tags are enabled, tags were removed (as in Haskell version)
- when HTML tags are disabled, tags were escaped (as in C version)
After this commit:
- tags will be escaped (as in C version) regardless of HTML flag
+ render hardbreaks as newlines, same as cmark
In this change set I am changing the guidance in the README
and in comments to put the class on the correct tag: `<code>`, not `<pre>`.
If you put the `hljs` class on `<pre>`, syntax highlighting
does not use the correct padding.
You can see from the default CSS stylesheet in the highlight.js
repo that the `hljs` tag is expected to be on the `<code>` tag:
84719c17a5/src/styles/default.css (L17-L25)
All the official highlight.js examples have the `hljs` class on `<code>`:
https://highlightjs.org/static/demo/
1st iteration before the loop is exactly the same as a part of that loop
this effectively replaces:
```
do(0)
for (i = 1; i < x; i++) do(i)
```
with:
```
for (i = 0; i < x; i++) do(i)
```
.substr() is deprecated so we replace it with .slice() which works similarily but isn't deprecated
Signed-off-by: Tobias Speicher <rootcommander@gmail.com>
For instance, in a list
1. Item 1
20. Item 2
the first list_item_open token will have token.info === '1', and the
second will have token.info === '20'.
This is useful for later rendering plugins that might want to
use the actual markers.