Properly escape inline link and image attributes. Fix #473. #474
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.
I have added proper escaping to images that is in line with the previous PR #460.
CommonMark specification defines rules for images +/- in the following way - "do the same as for links". So I have extracted the shared logic for escaping titles and links to dedicated functions.
Image
alt
attribute is used as link text. This text should have all markdown syntax escaped. For that purpose I have added new functionescapeMarkdown
, which is functionally the same asturndown.escape
. This was necessary to prevent circular dependency and unnecessary refactoring.A bit about new escapeMarkdown function
The new implementation is pretty different in a sense that it uses single regex with a mixture of non-capturing / capturing groups and a single look-ahead assertion. This means that some ancient runtime environment might have issues with it... Not sure if that is of any concertn, but at least compatibility tables on MDN and caniuse.com for the used features have the same versions as the RegExp itself:
We might want to create a single shared implementation of that function. But I am not sure how to approach this . The function is probably pretty good candidate for its own file (escape-markdown.js) or maybe it can be placed in utils.js.
Also we might want to do some performance testing to pick which function will perform better. The new regular expression is more complex, but the OG function executes 13 separate regular expressions on any given content. So my gut tells me that on any average sized content the new regex will perform better... would be nice to actually verify that.