Fix problems in the markdown -> html pipeline #163
Conversation
a7c7e45
to
3df0f3a
Compare
I am also pondering what would be a good place for a domEquals function? Thinking of extracting one from assertDomEquals and putting those two functions somewhere where all helix code can use it… |
We may want to create a new helix-testutils project. I need to put my |
7c1c313
to
1eb1cb1
Compare
After fixing the missing support for the missing "referenceType" attribute in the mdast json schema, I can't get the example below to work; needs extra investigation but I do not think this is any error we introduced, since this is a highly specific property of the GFM & CommonMark specs (which flavor are we using by the way). As far as I can see, the markdown is already being parsed incorrectly…it parses Input Markdown# Foo
Hello World [link](<foobar) Expected result(As rendered by marked with GFM enabled and without) <h1 id="foo">Foo</h1>
<p>Hello World <a href="%3Cfoobar">link</a></p> Actual Result<h1>Foo</h1>
<p>Hello World [link](<foobar)</p> MDAST{ type: 'root',
children:
[ { type: 'heading',
depth: 1,
children:
[ { type: 'text',
value: 'Foo',
position:
Position {
start: { line: 1, column: 3, offset: 2 },
end: { line: 1, column: 6, offset: 5 },
indent: [] } } ],
position:
Position {
start: { line: 1, column: 1, offset: 0 },
end: { line: 1, column: 6, offset: 5 },
indent: [] } },
{ type: 'paragraph',
children:
[ { type: 'text',
value: 'Hello World ',
position:
Position {
start: { line: 3, column: 1, offset: 7 },
end: { line: 3, column: 13, offset: 19 },
indent: [] } },
{ type: 'linkReference',
identifier: 'link',
label: 'link',
referenceType: 'shortcut',
children:
[ { type: 'text',
value: 'link',
position:
Position {
start: { line: 3, column: 14, offset: 20 },
end: { line: 3, column: 18, offset: 24 },
indent: [] } } ],
position:
Position {
start: { line: 3, column: 13, offset: 19 },
end: { line: 3, column: 19, offset: 25 },
indent: [] } },
{ type: 'text',
value: '(<foobar)',
position:
Position {
start: { line: 3, column: 19, offset: 25 },
end: { line: 3, column: 28, offset: 34 },
indent: [] } } ],
position:
Position {
start: { line: 3, column: 1, offset: 7 },
end: { line: 3, column: 28, offset: 34 },
indent: [] } } ],
position:
{ start: { line: 1, column: 1, offset: 0 },
end: { line: 3, column: 28, offset: 34 } } } HAST{ type: 'root',
children:
[ { type: 'element',
tagName: 'h1',
properties: {},
children:
[ { type: 'text',
value: 'Foo',
position:
{ start: { line: 1, column: 3, offset: 2 },
end: { line: 1, column: 6, offset: 5 } } } ],
position:
{ start: { line: 1, column: 1, offset: 0 },
end: { line: 1, column: 6, offset: 5 } } },
{ type: 'text', value: '\n' },
{ type: 'element',
tagName: 'p',
properties: {},
children:
[ { type: 'text',
value: 'Hello World ',
position:
{ start: { line: 3, column: 1, offset: 7 },
end: { line: 3, column: 13, offset: 19 } } },
{ type: 'text',
value: '[link]',
position:
{ start: { line: 3, column: 14, offset: 20 },
end: { line: 3, column: 18, offset: 24 } } },
{ type: 'text',
value: '(<foobar)',
position:
{ start: { line: 3, column: 19, offset: 25 },
end: { line: 3, column: 28, offset: 34 } } } ],
position:
{ start: { line: 3, column: 1, offset: 7 },
end: { line: 3, column: 28, offset: 34 } } } ],
position:
{ start: { line: 1, column: 1, offset: 0 },
end: { line: 3, column: 28, offset: 34 } } } |
0da7757
to
0fea673
Compare
Codecov Report
@@ Coverage Diff @@
## master #163 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 39 39
Lines 839 833 -6
Branches 164 160 -4
=====================================
- Hits 839 833 -6
Continue to review full report at Codecov.
|
Please do not merge yet; wip |
Btw, this PR removes the VDOM.process function; is it used anywhere outside pipe? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are using GFM. If you've discovered an issue in the remark tools, file an issue against the project and create a PR. @woorm is generally fast to respond, review, merge and release.
* Turns the MDAST into a basic DOM-like structure using Hyperscript | ||
* @returns {Node} a simple DOM node (not all DOM functions exposed) | ||
*/ | ||
process() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea of this function is to be used in project-code, e.g. if you want to override the way HTML is being generated, you'd be able to register a new handler and then run process
in your pre.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I guess just using getDocument
is easier.
5d74c5a
to
035a8e2
Compare
Content can be directly provided to the html pipeline; in this mode the pipline does not make an http request to fetch the data, instead the content provided is used. Until this commit, the pipeline would disregard the content passed to it, if the content is an empty string. In this case an http request would be performed to fetch the data. This behaviour is fixed by this commit
This wrapping div would be added when there was more then one element in the markdown (which is the usual case) by hyperscript because hyperscript has no concept of multiple elements in the root node. Our code came to expect this wrapping which led to markdowns with a single element being rendered as an empty document in some cases (the single element would be deleted during the emit-html when generating .content.children). This commit fixes this issue by using hast-util-to-html instead of hyperscript for the hast -> html conversion which does indeed have a concept of multiple elements at the root node. Fixes #157
It was deprecated Fixes #105
035a8e2
to
711b625
Compare
Should be ready to merge as soon as the branch in helix-shared is merged. |
arff... no... too fast... |
This fixes two issues with markdown rendering and adds an infrastructure for testing whether for a specific markdown input, the correct output is produced.
Not sure whether
test/testHTMLFromMarkdown.js
should not be merged intotest/testHTML.js
; I kind of like having all the markdown tests in their own place, on the other hand a lot of boilerplate is required to put them there…