Skip to content
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

Closed
anderskaplan opened this issue Sep 21, 2022 · 2 comments
Closed

Question: Inconsistencies in the block tokens #163

anderskaplan opened this issue Sep 21, 2022 · 2 comments
Labels

Comments

@anderskaplan
Copy link
Contributor

anderskaplan commented Sep 21, 2022

There are some inconsistencies among the block tokens that maybe should be fixed before stepping up to version 1.0:

  1. Trailing newlines are sometimes preserved and sometimes not. CodeFence and BlockCode preserve them; Paragraph and HTMLBlock do not.
  2. CodeFence and BlockCode keep their content in a single RawText child node, whereas the HTMLBlock keeps it in the content property. In fact, the HTMLBlock is the only block token to have a content 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 all Paragraph'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 single RawText node, so it would be consistent with the other block tokens. Maybe keep its content property, too, in order to not break the API. The content property could be turned into a property getter and marked as deprecated.

Thoughts?

@anderskaplan anderskaplan changed the title Inconsistencies in the block tokens Question: Inconsistencies in the block tokens Oct 1, 2022
@pbodnar
Copy link
Collaborator

pbodnar commented Oct 30, 2022

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?

@anderskaplan
Copy link
Contributor Author

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.

anderskaplan added a commit to anderskaplan/mistletoe that referenced this issue Feb 11, 2023
…node, like all the other block tokens, instead of a content attribute.

See miyuchina#163.
Added a convenience wrapper to preserve backward compatibility.
anderskaplan added a commit to anderskaplan/mistletoe that referenced this issue Feb 26, 2023
…node, like all the other block tokens, instead of a content attribute.

See miyuchina#163.
Added a convenience wrapper to preserve backward compatibility.
pbodnar pushed a commit that referenced this issue Mar 4, 2023
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants