-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: Inconsistencies in the block tokens #163
Comments
The suggestions seem reasonable, I will try to review them soon. I guess there is an implicit expectation that suggested changes would change the output from renderers, making them possibly more consistent, isn't it? |
The proposal will mainly affect the AST. I think the output from the renderers would only change very little, if at all. But it would be easier to make their output more consistent, too, if desired. |
…node, like all the other block tokens, instead of a content attribute. See miyuchina#163. Added a convenience wrapper to preserve backward compatibility.
…node, like all the other block tokens, instead of a content attribute. See miyuchina#163. Added a convenience wrapper to preserve backward compatibility.
…he block tokens (#169) Modified the HTMLBlock token to store its content in a RawText child node, like all the other block tokens, instead of a content attribute. This will make traversing all block tokens easier. Also, all text-only block tokens (HTMLBlock, BlockCode and CodeFence) have a convenience `content` property getter now.
There are some inconsistencies among the block tokens that maybe should be fixed before stepping up to version 1.0:
CodeFence
andBlockCode
preserve them;Paragraph
andHTMLBlock
do not.CodeFence
andBlockCode
keep their content in a singleRawText
child node, whereas theHTMLBlock
keeps it in thecontent
property. In fact, theHTMLBlock
is the only block token to have acontent
property. It is typically used with span tokens.So what to do about it?
My suggestion would be to remove the trailing newlines from all block tokens. The other consistent option, to keep them for all block tokens, would add a trailing
LineBreak
to allParagraph
's, and that would just be a pain. Of course there's also the option to leave it as it is.I would also suggest to place the
HTMLBlock
content in a singleRawText
node, so it would be consistent with the other block tokens. Maybe keep itscontent
property, too, in order to not break the API. Thecontent
property could be turned into a property getter and marked as deprecated.Thoughts?
The text was updated successfully, but these errors were encountered: