Snarkdown roadmap ?

[Jonarod]

Hey !

Cool project ! Thanks for sharing this, really.

@developit, after going through the code, I found some irregularities (PR submitted) but I don't know to which extend you will accept PR or what aspects of Markdown are you willing to support Vs the 1kb claim. I know you are by definition a "zero-calories-coder" (yeah it's brand new term, my present :P ) #Preact (3kb) , but where do you want to go with snarkdown ?

In my opinion, I totally buy the 1kb assertion (this one aspect lead me here in the first place), however I would like to be able to freely extend functionalities. My personal goal, for my project would be o basically match with markdown-it. This means support for GFM tables (I see a PR is pending), I recently added strikethrough, I also see there is a slight problem regarding images that do not support the Alt attribute (a PR on that might move stuff around as it implies adding a new catching group to links regex...), I think I can add subscript and superscript, and custom containers (which is out of commonMarks specs but I find it useful to add basic styling) would basically be 200 bytes to implement... Now, in your opinion, when should we include all of this into snarkdown, and when it should be out: how to implement it ?

Indireclty, my question is two fold:

1. is there some roadmap you wish to implement ?
2. to balance lightweight code Vs features : could you guide us toward a kind of plugin implementation that would extend the 1kb if needed ?

Thanks for reading

[developit]

Most of my projects follow a similar pattern: choose a seemingly unreachable size goal, then meets that goal and release the project. Most times I've found it's best to keep that goal (with some rounding if necessary) so that projects remain hyper-focussed. However, I don't think it's always the case - sometimes there are features that are simply worth the bit of extra weight. It's case-by-case though.

I'd be very interested in plugins here, especially if they provided a way to break up that gnarly regex into chunks. Maybe the idea we run with is this: Snarkdown core is 1kb, but it's enough of a base that plugins can extend it with more of the features of other libraries.

For some examples - I'd punt subscript, superscript and strikethrough to plugins (perhaps a single "extended text formatting" plugin), as with tables. Moving those features to plugins might be the way to eek out just enough room to add the plugin architecture to core.

In terms of a roadmap, I mostly use Snarkdown for simple formatting coupled with preact-markup, so I may not be the most typical user. Perhaps it'd be worth coming up with a shared roadmap and allowing anyone to make edits?

[Jonarod]

Totally agree with the focused vision, and keeping core to 1kb. In my opinion, the MAIN problem of snarkdown to be really labeled as "markdown alternative" is lack of <p></p> tags in the core though. This is why I moved on to use the heavy markdown-it (I almost cried as I switch to 40kb gzipped just for <p></p> believe me)...

Regarding crazy regex tokens and stuff, here is the approach I tried at first:

// define rules (need to double all `\`)
let hs = '(?:^(#{1,6})(?=\\s)(.*?)(?: +#*)? *$)';
let blockquotes = '((?:^>.*$)(?:(?:\\n(?!\\n|([_*-]) *\\15(?: *\\15)+ *$|(?:\\d+[.)/]|[-+*]|#{1,6})(?=\\s|$)|`{3,})).*$)*)';
// etc...

Then, we could:

let tokenizer = new RegExp(`${fences}|${hrs}|${hs}|${uls}|${ols}|${blockquotes}|${paragraphs}|${emphasizes}`, 'gm');

But more important, we should try the impact of just naming stuff like:

// destructuring
  let [token
    , fence_open, fence_lang, fence_content_1, fence_content_2
    , hr_1
    , heading_open, heading_content
    , ul_content, ul_start, ul_3
    , ol_content, ol_start, ol_3
    , blockquote_content, blockquote_2
    , paragraph_content, paragraph_2
    , strong_a_open, strong_a_content, strong_a_close, em_a_open, em_a_content, em_a_close, strong_u_open, strong_u_content, strong_u_close, em_u_open, em_u_content, em_u_close
    ] = match;

Of course, this setup will cost a few bytes to balance with maintainability. Personally I am confortable enough with regex, but heck: sometimes it starts to get crazy...

Regarding the ability to EXTEND snarkdown though, I find it rather complicated to let people sneak into the loop and catch the regex rules (the order of the regex has meaning...).

[developit]

Regarding naming, it's possible we could use expansions like that along with a Google Closure Compiler integration to minify to the current implementation.

At the very least, we could do something like:

  /*
  [
    token
    , fence_open, fence_lang, fence_content_1, fence_content_2
    , hr_1
    , heading_open, heading_content
    , ul_content, ul_start, ul_3
    , ol_content, ol_start, ol_3
    , blockquote_content, blockquote_2
    , paragraph_content, paragraph_2
    , strong_a_open, strong_a_content, strong_a_close, em_a_open, em_a_content, em_a_close, strong_u_open, strong_u_content, strong_u_close, em_u_open, em_u_content, em_u_close
    ]
    */

for the nice detailed index explanations.

[RobbieTheWagner]

+1 for paragraph support. Any progress on this?

[mitranim]

Same here. I'm currently using marked, which I believe is the next smallest markdown renderer, at ≈21 KiB minified (non-zipped). Snarkdown at ≈3 KiB seems very promising, but the lack of paragraphs is a show-stopper.

[mitranim]

@Jonarod Try marked for now, much smaller than markdown-it.

[paulovieira]

I'm not sure if I understand the problem related to the lack of paragraphs, but it's easy to add your own postprocessor to handle it:

function postprocessSnarkdown(html) {

  html = html
    .split('<br />')
    .map(function(substr) {

      if (substr.startsWith('<')) { return substr }

      return `<p>${substr}</p>`;
    })
    .join('\n');

  return html;
}