Properly handle annotations in fenced code blocks #393
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 PR fixes issue #390 — annotations inside of fenced code blocks apply their attributes to the top-level document node. The expected behavior is for annotations inside of fenced code blocks to result in a validation error.
The logic inside of the parser sets the value of the
inlineParent
variable to the immediate parent when it detects that the current token has children. This behavior is mostly correct, because inmarkdown-it
the only tokens that ever have achildren
array are "inline" tokens. The processing for fenced code blocks is, however, a special case — we modify the token and put the synthesized tokens for the parsed interior text content into the fence'schildren
array. This inadvertently results in the fence's parent being treated as theinlineParent
for the nodes nested inside of the fence.To address this issue, I modified the parser logic so that it only sets the
inlineParent
variable when the current node type is explicitly "inline".Closes #390