Fix parsing '>' in element content #37
Open
Conversation
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
Fix contnet of element body being truncated after first occurrence of a greater than sign (>), which can cause issues in some circumstances, such as a conditional evaluation inside a script tag. Relates to issue jenstornell#21
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 pull request fixes some cases where the HTML file is parsed incorrectly when there is a greater than symbol inside of an element content, such as a script tag, as reported in issue #21 .
For example, for the following (simple) input:
<script>var isBigger = 2 > 1 ? 'yes' : 'no'</script>When parsed using the current code in this repository, the result is:
<script>var isBigger = 2 </script>And with this PR, the result is:
<script>var isBigger = 2 > 1 ? 'yes' : 'no'</script>I've also modified the sample HTML in the tests directory to include an example of this behaviour.
I've used
diffto compare the output of the compile test before and after this modification, and nothing other than the intended chances is modified. I can't see a reason why this fix would cause issues to anything else, though am happy to fix my code if anyone can see any potential issues.