markdown-it — парсер markdown / CommonMark на стероидах

[Envek]

Жаль, что пока не написано, как же делать свои расширения…

[drakmail]

Обещают скоро задокументировать

[akamajoris]

Я до сих пор не понимаю зачем изобретать велосипед. Есть HTML, со всеми обязанностями справляется.

[SazereS]

Хотя бы потому, что чисто визуально MD более понятен. Для сравнения:

<ul>
    <li>Item 1</li>
    <li>Item 2</li>
</ul>

и

* Item 1
* Item 2

Да и писать с MD-метками быстрее чем с тегами (если вы только не в IDE текст набираете)

[akamajoris]

Мне понятнее <LIst>, нежели *. Я пользовался пару недель марком, если бы понравилось, я бы не писал первый коммент. Привожу доводы.

meta.stackexchange.com/questions/126382/markdown-does-not-allow-for-bold-italic-then-bold-then-bold-italic
Мое любимое занятие, сидеть и считать звездочки…

[SazereS]

А как часто Вам приходится писать такие конструкции? И как по мне, то такой вариант выглядит не особо лучше:

<strong><em>bold italic</em> bold <em>bold italic</em></strong>

[ingspree]

Что понятнее, хорошо видно по тому, что на самом деле <li> — это list item.

[akamajoris]

Открою секрет. Читать буквы проще, чем спецсимволы. Конечно, LI является элементом списка, по запарке написал list.

[ingspree]

Как насчëт < и >?

[akamajoris]

Надеюсь это сарказм, иначе плохо.

[dshster]

Всё просто — markdown безопасный формат, где можно использовать только определённые шаблоном теги, во-вторых нет проблемы с незакрытыми тегами или неправильно вложенными. Это особенно актуально для UGC, когда пользователи сами применяют разметку к своему тексту и если им дать полноценный html, то результат может быть непредсказуем, да и html-парсер выйдет дороже в ресурсах. Раньше особенно на форумах использовали для этого bbcode.

Кстати, в приведённом выше примере нет синхронизации позиции обоих окон, а было бы удобно.

[Evengard]

… И я честно говоря не понял, почему нужно было уходить от bbcode и придумывать этот самый Markdown.

[dshster]

В bbcode тоже парные теги, единственный плюс перед html — можно ограничить количество этих тегов

[Evengard]

Так парные теги это ж хорошо. Чётко видно где начало, и где конец.

[dshster]

Это повышает уровень ответственности пользователя и риск допустить ошибку. MD же наоборот снижает вероятность ошибки со стороны пользователя.

[Evengard]

Ну не знаю. Меня все эти маркдауновские закорючки только сбивают с толку. Риск ошибки гораздо выше для меня.

[akamajoris]

пользователи сами применяют разметку к своему тексту и если им дать полноценный html

Я вставил цитату, на хабре, через HTML, полноценный. Или вы думаете, что не будет XSS под MD? Будут. Просто пока искать способы обмана парсера мало кому нужно.

да и html-парсер выйдет дороже в ресурсах

Может сразу сделаем рендеринг MD в браузерах? Хотел бы услышать про разницу в парсинге html и md. За счет чего уменьшается потребление ресурсов?

Более того, во что парсится MD? Правильно, в HTML, так что же за парадокс такой получается, HTML в HTML превратить тяжелее, чем MD в HTML?

[dshster]

На Хабре не полноценный html, а ограниченное количество тегов и проблема неправильно вложенных тегов не решена (попробуйте перепутать открывающие и закрывающие теги). MD же создавался как легкочитаемый текстовый формат без преобразования, посмотрите выше комментарий SazereS (http://habrahabr.ru/post/241766/#comment_8096248). Не представляю о чём спор — область применения и целесообразность есть у каждого формата, холивар ради холивара? Обманывать же парсер нет смысла, если он пропускает только предустановленные форматы.

[akamajoris]

На Хабре не полноценный html, а ограниченное количество тегов

Тогда весь MD является такой штукой, которая может перевести несколько закорючек в обычные HTML теги.
Люди изобретают проблемы.
Ладно, давайте останемся при своих мнениях.

[Bonart]

А компилятор переводит несколько закорючек в обычные машинные коды.

[Bonart]

HTML очень плохо читается человеком, имеет множество способов выстрелить себе в ногу, чрезвычайно сильно многословен, многозначен и избыточен, плохо подходит для diff и merge.

[Pilat]

Мне кажется, в пользу markdown есть только один серьёзный довод — он хорошо воспринимается системами контроля версий, изменения в файле markdown видны гораздо лучше, чем изменения в html. Но писать на нём документацию трудно — стандартов многовато, и Remarkable ничем не помогает, да и непонятно как множество markdown файлов объединять в книгу. Может быть, стоит wiki вспомнить.

[Wedmer]

Для тех, кто делает документацию при помощи Doxygen, MD не должен вызывать проблем.
Для книг возможно нужны какие то расширения.

[zag2art]

Звучит конечно здорово, но вы посмотрите на их плагины. Вот, например, github.com/jonschlinkert/remarkable/blob/dev/lib/rules_inline/del.js и все это для того, чтобы ~~text~~ в text

Как вам?

[Varnak]

В чем проблема-то? Вроде понятно что делается и зачем.

[zag2art]

Да больно кода много для такого простого действия.

[Varnak]

Посмотрите исходники любого полноценного парсера с качественной поддержкой вложенных тегов. Везде так или еще сложнее. У тех кто патается делать проще, потом пачки репортов в трекере о кривой работе.

[zag2art]

Может быть, я в парсерах не копался, но желание делать свой плагин пропало. Хотел добавить аналог хабровского спойлера.

[Varnak]

В другие парсеры без костылей подобные вещи плагинами вообще не реально добавить. Про спойлеры лучше тут почитать talk.commonmark.org/t/what-could-a-spoiler-tag-extension-look-like/767. Все там и так будет, как только спецификацию утрясут.