Snarkdown roadmap ? about snarkdown HOT 7 OPEN

+1 for paragraph support. Any progress on this?

from snarkdown.

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.

from snarkdown.

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

from snarkdown.

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?

from snarkdown.

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

from snarkdown.

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.

from snarkdown.

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;
}

from snarkdown.