Technical post, skip to the MD Limitations section for the tldr
I’m building markdown support right now. This thread outlines the planned limitations of Kinopio’s markdown support.
Technical Reasoning
Generally, generating html from a markdown string requires:
markdown parsing lib - which converts text to html. eg *yo* to <b>yo</b> . limited markdown parsing is pretty fast, and can be written pretty small.
html sanitizer that prevents scripts from running inside the html. eg. *yo<script>be bad</script>* will execute if turned into html <b><script>be bad</script></b>. Sanitizing is medium speed, but the libs to do this comprehensively are Huge.
Running a bunch of em through sanitize-html v2.3.0 ❘ Bundlephobia returns gzipped sizes of around 50kb. For reference, all of kinopio is like 150kb so it’s hard to justify.
To do Kinopio markdown quickly and safely, I have to write my own markdown parsing lib that outputs data instead of raw html. (le sigh)
eg. *yo* turns into [{content: 'yo', type: 'bold', endPosition: 2}], which can be safely outputted without sanitization
MD Limitations
doesn’t support syntax nesting. So *_yo_* would just show a bold yo , instead a bold and italic yo
limited syntax support. Most fancy markdown features like tables etc. don’t really make sense inside cards anyways. I’m planning on doing:
bold
emphasis/italic
link
del/strikethrough
If there are any others you would use, lmk and I’ll consider it
All Markdown specs have single * or _ to indicate <em> and double ** or __ to indicate <strong>—this is contrary to your example (and the original userscript referenced here). So *emphasis* is the same as _emphasis_, etc.
Implementing links is interesting to me since it collides slightly with the existing functionality. Do you intend on still enforcing the literal character count, or would you exempt the link text? And we now already have tags and space links which are rendered in the name and are a form of links.
I’m on the fence w links, but if i did it I’d still enforce the regular character count. Adding special conditional logic for special cases creates long-term maintenance issues
I’ll use the correct ** for bold in the real thing
I’ve always been pretty okay with lack of Markdown because the whole point of Markdown is that it looks good even when it’s not rendered as HTML. But having this feature does enhance things and provide more tools to visually distinguish text and cards. I could see using italics for comments, e.g.
The only other styling I was considering was code (with the backtick syntax). But since the text is already monospace, I don’t know what that would add, or how you would even render it. So nevermind, but thought I’d just mention it.
I was also having this problem when experimenting with the userscript. Even if I set the element explicitly as bold or font-weight 700, it just doesn’t render as such. Just me?
I couldn’t repro but that’s maybe because of the fonts on my system, anyways I made the bold more obvious in general by using the system monospace font for bold (instead of having the browser apply fake bolding to the kinopio font)
seems that way. An alternative would be for bold text, keeping the font weight the same but using a background color to make it appear stronger , roughly like
I’m ambivalent on that, especially since I know the spaces aren’t strictly the same But am cool with altering the rendering of **text like this** because semantically, it means <strong>, so it doesn’t necessarily have to change the font weight
If possible, a different color (maybe a more pink/red color) or a greyer background. Maybe even a black background with white text to be like a terminal. I have a project that includes access logs and code highlighting would be nice here:
But am cool with altering the rendering of 
