You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a few gripes with the mdCodeSpans2html function we are currently shipping. First, it uses the wrong naming convention for conversion functions (includes the 2 digit) rather than spelling out the word to like all the other standard methods found in the JS language. The other has to do with its very limited ability. Even though the only functionality we have needed so far has been the conversion of Markdown code spans (text enclosed in backticks) to HTML code elements, we should plan to be able to handle several other Markdownisms (e.g., bold, italic, strikethru, underline, etc.).
Interestingly, Jekyll provides the markdownify filter, which converts any Markdown-formatted string into HTML, which would be more suitable for future use cases. I am, however, not so sure about the naming of it since we are really making to conversion into HTML (i.e., HTML-izing or HTML-ifying) the string rather than the opposite (as Jekyll's naming seems to imply). We could have that coded up as a JS function with perhaps a better name and ship that instead. Other than this being a major breaking change, I see no immediate problem with doing this instead. It certainly seems like it would be a more practical function to have available. It may also be possible that since the contents of the text being fed into it are not always known, a more complete conversion of this nature would be necessary to be accurately compiled to HTML.
The text was updated successfully, but these errors were encountered:
At the very least, I think it would be wise to begin by taking mdCodeSpans2html through a deprecation cycle once the new API has been added. We can start by doc-deprecating it, then move on to runtime-deprecating for a period before making a semver-major release completely removing it. We would want to let the ecosystem adapt and be provided with an opportunity to express any feedback that may be solicited by these deprecations.
I have a few gripes with the
mdCodeSpans2html
function we are currently shipping. First, it uses the wrong naming convention for conversion functions (includes the2
digit) rather than spelling out the wordto
like all the other standard methods found in the JS language. The other has to do with its very limited ability. Even though the only functionality we have needed so far has been the conversion of Markdown code spans (text enclosed in backticks) to HTMLcode
elements, we should plan to be able to handle several other Markdownisms (e.g., bold, italic, strikethru, underline, etc.).Interestingly, Jekyll provides the
markdownify
filter, which converts any Markdown-formatted string into HTML, which would be more suitable for future use cases. I am, however, not so sure about the naming of it since we are really making to conversion into HTML (i.e., HTML-izing or HTML-ifying) the string rather than the opposite (as Jekyll's naming seems to imply). We could have that coded up as a JS function with perhaps a better name and ship that instead. Other than this being a major breaking change, I see no immediate problem with doing this instead. It certainly seems like it would be a more practical function to have available. It may also be possible that since the contents of the text being fed into it are not always known, a more complete conversion of this nature would be necessary to be accurately compiled to HTML.The text was updated successfully, but these errors were encountered: