WIP markdown support

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:

  1. 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.

  2. 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 https://bundlephobia.com/result?p=sanitize-html@2.3.0 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

  1. doesn’t support syntax nesting. So
    *_yo_* would just show a bold yo , instead a bold and italic yo

  2. 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

3 Likes

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.

1 Like

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

1 Like

looks like I got something working

Screen Shot 2021-01-05 at 11.20.58 PM

1 Like

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.

FWIW the most common way I’ve seen to represent strikethrough that is with two ~~s (See https://daringfireball.net/linked/2015/11/05/markdown-strikethrough-slack and https://github.github.com/gfm/#strikethrough-extension-).

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.

:radio:

1 Like

lol ya that’s the same reason I didn’t include it,

updated that strikethrough syntax to only work with ~~, thx

Screen Shot 2021-01-06 at 10.32.11 AM

shipped :canoe:

1 Like

I’m not seeing bold get styled for some reason. I tried Vivaldi (browser) and also the todesktop app:

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?

1 Like

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)

should look like this,

It kinda bothers me the width is different, but I’ll stick with it for a while and see how it plays :wink:

bold

ya i dont like it either, i reverted the font change for a little bit. Do the cards now look completely unbolded for you?

1 Like

Yeah, no change whatsoever.

Also, a bug with underscore:

one_two_three the "two" should not be italicized ;)

Gets rendered as:

image

out of curiosity, do you have the same issue on safari?

1 Like

arg regex life. just released a fix for this,

Screen Shot 2021-01-06 at 8.29.41 PM

I aimed to replicate the discourse behaiviour:

  • one*two*three shows italic,
  • one_two_three does not show italic

Good point. I can’t check atm but mobile safari does render bold.

Yeah, on Safari Technology Preview, it looks better:

image

Although it still messes with the width, which I assume is because it’s faux bold?

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
Screen Shot 2021-01-06 at 11.41.34 PM

thoughts?

1 Like

I’m ambivalent on that, especially since I know the spaces aren’t strictly the same :slight_smile: 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 :+1:t2:

1 Like

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:

2 Likes

Sure I can add code block support

1 Like