Pull to refresh

Comments 29

Жаль, что пока не написано, как же делать свои расширения…
Я до сих пор не понимаю зачем изобретать велосипед. Есть HTML, со всеми обязанностями справляется.
Хотя бы потому, что чисто визуально MD более понятен. Для сравнения:
<ul>
    <li>Item 1</li>
    <li>Item 2</li>
</ul>

и
* Item 1
* Item 2

Да и писать с MD-метками быстрее чем с тегами (если вы только не в IDE текст набираете)
Мне понятнее <LIst>, нежели *. Я пользовался пару недель марком, если бы понравилось, я бы не писал первый коммент. Привожу доводы.

meta.stackexchange.com/questions/126382/markdown-does-not-allow-for-bold-italic-then-bold-then-bold-italic
Мое любимое занятие, сидеть и считать звездочки…
image
А как часто Вам приходится писать такие конструкции? И как по мне, то такой вариант выглядит не особо лучше:
<strong><em>bold italic</em> bold <em>bold italic</em></strong>
Что понятнее, хорошо видно по тому, что на самом деле <li> — это list item.
Открою секрет. Читать буквы проще, чем спецсимволы. Конечно, LI является элементом списка, по запарке написал list.
Всё просто — markdown безопасный формат, где можно использовать только определённые шаблоном теги, во-вторых нет проблемы с незакрытыми тегами или неправильно вложенными. Это особенно актуально для UGC, когда пользователи сами применяют разметку к своему тексту и если им дать полноценный html, то результат может быть непредсказуем, да и html-парсер выйдет дороже в ресурсах. Раньше особенно на форумах использовали для этого bbcode.

Кстати, в приведённом выше примере нет синхронизации позиции обоих окон, а было бы удобно.
… И я честно говоря не понял, почему нужно было уходить от bbcode и придумывать этот самый Markdown.
В bbcode тоже парные теги, единственный плюс перед html — можно ограничить количество этих тегов
Так парные теги это ж хорошо. Чётко видно где начало, и где конец.
Это повышает уровень ответственности пользователя и риск допустить ошибку. MD же наоборот снижает вероятность ошибки со стороны пользователя.
Ну не знаю. Меня все эти маркдауновские закорючки только сбивают с толку. Риск ошибки гораздо выше для меня.
пользователи сами применяют разметку к своему тексту и если им дать полноценный html

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

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

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

Тогда весь MD является такой штукой, которая может перевести несколько закорючек в обычные HTML теги.
Люди изобретают проблемы.
Ладно, давайте останемся при своих мнениях.
А компилятор переводит несколько закорючек в обычные машинные коды.
HTML очень плохо читается человеком, имеет множество способов выстрелить себе в ногу, чрезвычайно сильно многословен, многозначен и избыточен, плохо подходит для diff и merge.
Мне кажется, в пользу markdown есть только один серьёзный довод — он хорошо воспринимается системами контроля версий, изменения в файле markdown видны гораздо лучше, чем изменения в html. Но писать на нём документацию трудно — стандартов многовато, и Remarkable ничем не помогает, да и непонятно как множество markdown файлов объединять в книгу. Может быть, стоит wiki вспомнить.
Для тех, кто делает документацию при помощи Doxygen, MD не должен вызывать проблем.
Для книг возможно нужны какие то расширения.
В чем проблема-то? Вроде понятно что делается и зачем.
Да больно кода много для такого простого действия.
Посмотрите исходники любого полноценного парсера с качественной поддержкой вложенных тегов. Везде так или еще сложнее. У тех кто патается делать проще, потом пачки репортов в трекере о кривой работе.
Может быть, я в парсерах не копался, но желание делать свой плагин пропало. Хотел добавить аналог хабровского спойлера.
Only those users with full accounts are able to leave comments. Log in, please.