Replies: 1 comment
-
Our perspective on this is that the fence is the standard CommonMark way to indicate unprocessed literal content in a Markdown document, so we're reluctant to support literal text in any arbitrary tag as it would create a lot of interoperability challenges with other parts of the Markdown ecosystem. We have seen a number of requests from users who want to be able to create more specialization around fences and use them in tag-like ways, so we are planning to add some functionality for that in the near future with a hybrid syntax that preserves interoperability with third-party Markdown tooling. Once we add that, you would be able to do something like:
That would explicitly convey both the fact that it's literal text and that it is subject to specific processing, and it would make it easier to define different kinds of processing for literal blocks. We don't have a timeline for adding this yet, but it'll likely be in the next few months. |
Beta Was this translation helpful? Give feedback.
-
I want to do special processing, to allow a custom tag to act like a code fence, however, when I use a custom tag, it strips out the spaces.
This is what I want to do:
I have it working with
However, I have noticed that the parsing is different for custom tags and code fences. Code fences add the raw contents into
attributes.content
with spaces, however within custom tags, parsing breaks down the content into markdoc nodes (in this case, paragraphs of text) stripping out the spaces. Is it possible to preserve the raw text when parsing custom tags? Alternatively, could it be parsed as if it's a code fence?The use case is that we prefer the tag syntax to the code fence one, so that it's explicit we are doing some extra transformation.
Beta Was this translation helpful? Give feedback.
All reactions