developit / developit/snarkdown

Snarkdown roadmap ?

オープン
#34 コメント 7 件 リアクション 6 件 担当者 0 名 GitHub で見る
主要言語
JavaScript
スター
2.4k
フォーク
116
PR マージ指標
30日以内にマージされた PR はありません

説明

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)](https://github.com/developit/preact/) , 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](https://markdown-it.github.io/).
This means support for GFM tables (I see a [PR](https://github.com/developit/snarkdown/pull/18) is pending), I recently [added strikethrough](https://github.com/developit/snarkdown/pull/32), 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

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

調査の方向性

まず既存の議論と参照されているPR #18および#32を確認し、次に要求されたスコープをmarkdown-itおよびSnarkdownの1kbという目標と比較します。完了の条件は、プロジェクトの方向性が明確になっていることです。つまり、サポートするMarkdown機能、追加に対する受け入れ基準、そして拡張性にpluginアプローチを使用すべきかどうかが明確になっていることです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
javascript
領域
tooling
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。