You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This branch is used to implement the fix required to the issue: #580
Motivation
With the current implementation the parser will evaluate arbitraty html tags inside a <pre>...</pre> and with this patch, <pre> will behave more like <script>.
This behaviour should be optional as sometimes it also makes sense to parse tags inside a <pre>, for instance for styling but most often the content inside a <pre> should be pretty much ignored and copied 1:1 from the source document into the generated output document and not reformatted (removing spaces, newlines or tabs) or should the parsed content have any influence on the overal consistenty of the document.
That said:
<html><pre></html>test foo</pre></html> should not be fixed into
This shows that the content inside the <pre>...</pre> is grabbed and not parsed already. Yet the result should be no HTML escaped string but rather a 1:1 copy of the original tags.
This can be evaluated by running:
clear && cargo run --example html2html
Todo
Figure out why: process_to_completion is called for <script> but not for <pre>
Implement an option to the parser to include parsing of <pre>...</pre> content or not
the motivation to move away from this is the usage of rust compiled to WASM. i always wanted to make modifications to the way 'new virtual-dom patches are applied' with visual cues which i can't do with virtual-dom.
rphtml (fails)
first i tried to replace virtual-dom with rphtml. but i discovered problems with rphtml: fefit/rphtml#4
i tried to fix them but the code is very hard to read and after a few days of hacking i gave up.
notable mention: the issue of rphtml was very hard to track down as it works 'half' of the time where text nodes in combination to tags sometimes yield correct html documents after doc.render(...)
html5ever (fails)
the <pre> handling in html5ever also breaks the code generated by pandoc after a serialize/deserialize run but for a slightly different reason. it removes all the newlines from the <pre>... \n <span>...</span> \n ... </pre>.
the first attempt in fixing it using a string for all the <pre>...</pre> content might work but still might not implement the html parsing standard correctly.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This branch is used to implement the fix required to the issue: #580
Motivation
With the current implementation the parser will evaluate arbitraty html tags inside a
<pre>...</pre>and with this patch,<pre>will behave more like<script>.This behaviour should be optional as sometimes it also makes sense to parse tags inside a
<pre>, for instance for styling but most often the content inside a<pre>should be pretty much ignored and copied 1:1 from the source document into the generated output document and not reformatted (removing spaces, newlines or tabs) or should the parsed content have any influence on the overal consistenty of the document.That said:
<html><pre></html>test foo</pre></html>should not be fixed into<html><pre>test foo</pre></html>Status
branch: servo_issue_580 with hash: 2094a85
This evaluates:
<hello>XML</hello><pre>\n<bad> </bad>text-in pre</pre><p>asdf</p><script>script</html> magic string</script>into
<html><head></head><body><hello>XML</hello><pre>\n<bad> </bad>text-in pre</pre><p>asdf</p><script>script</html> magic string</script></body></html>This shows that the content inside the
<pre>...</pre>is grabbed and not parsed already. Yet the result should be no HTML escaped string but rather a 1:1 copy of the original tags.This can be evaluated by running:
clear && cargo run --example html2htmlTodo
process_to_completionis called for<script>but not for<pre><pre>...</pre>content or not