Github, Reddit и StackExchange предложили стандартный синтаксис Markdown

[bolk]

К тому же, в консорциуме W3C некоторое время назад создали группу Markdown Community Group, которая и должна координировать усилия по выработке единой версии Markdown. Работа и выпуск «стандартных» спецификаций за их спиной — по меньшей мере, показатель некоторого неуважения к тем, кто потратил время и усилия на этот проект.

За два года эта группа что-нибудь родила? Если нет, то в топку эту группу! Я рад, что кто-то потратил время и предложил что-то дельное в этом отношении!

[Goodkat]

За два года эта группа что-нибудь родила? Если нет, то в топку эту группу!

Боюсь, так весь W3C разогнать придётся :)

[bodhisattva]

Давно пора :)

[forgotten]

Стесняюсь спросить, принимали ли вы когда-нибудь участие в работе W3C.

[naum]

На всякий случай обращу внимание спешащей высказаться относительно W3C публики на посты forgotten'а, который принимает непосредственное участие в ряде обсуждений.

[kirushik]

Нагляднее всего текущее состояние Маркдаун-экосистемы проиллюстрировано здесь.

Да, это 23 различных библиотеки M↓, которые выдают 15 разных HTML-рендерингов для одной несложной разметки. Да, и некоторые из результатов существенно отличаются по семантике выводимого, а не только по обработке пробелов и отсутпов.

[Mithgol]

Заметил строку, похожую на несущественную оплошность в реализации. Выслал запрос на слияние.

[Yavanosta]

А вы дюже остроглазы!

[praan]

Замечательно. Если к команде подключится еще и Википедия, то успех и взлёт популярности гарантирован.

[Abcd_Efgh]

Если к команде подключится ещё и Википедия

Википедия не пользуется Markdown, у неё свой стиль вики-разметки MediaWiki. Переход Википедии ни на какой другой язык разметки осуществляться, естественно, не будет из-за общей консервативности редакторов, количества страниц и общей неудобности решений вроде Markdown для Википедии.

[kefirfromperm]

Ужасный, ужасный для парсинга формат. Ужасный. Ужасно. Ужасно всё это!

[rotor]

Чем он ужасен?

[kefirfromperm]

Вот эти заголовки
==============

спать мне не дают. Мучают меня. Как их парсить-то?

Inline HTML — никогда не понимал этого. Зачем придумывать язык разметки, если в нем все равно можно использовать HTML? Может лучше использовать HTML?
Блоки кода, как понять когда он кончился?
Списки. Списки мне много крови попили. Но это общая проблема для BB, Textile, Wiki, Markdown. Никак их адекватно и быстро не распарсить. Не могу придумать.

[lair]

html требует усилию по «обезопашиванию».

[kefirfromperm]

В том то и дело! И в составе Markdown он опять требует все те же усилия по обезопашиванию, даже больше. Потому что появляется больше хитрых комбинаций разметки, которые надо учесть разработчику транслятора, чтобы не допустить XSS-ов всяких.

[lair]

А, извините, я не понял, что вы именно про использование Html внутри markdown.

[Zverik]

Так в спецификации же прописаны два типа заголовков, включая
# ATX Headers

А насчёт понимания, когда кончился, — кажется, ради этого стандарт и придумывался, чтобы чётко описать.

[kefirfromperm]

Это пользователь может выбирать. Разработчик транслятора должен предусмотреть все случаи. Я же именно про парсинг написал, не про использование. Как пользователю он мне очень нравится. Сам им пользуюсь, с удовольствием. Ридми файлы очень красивые получаются.

[iroln]

Зачем придумывать язык разметки, если в нем все равно можно использовать HTML? Может лучше использовать HTML?

Наверное, потому что писать в разметке HTML неудобно? Ради этого всё и затевалось ведь. Возможность использовать HTML внутри разметки покрывает тот ~1% случаев, когда это бывает необходимо.

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

А вы зачем его самостоятельно парсите кстати?

[kefirfromperm]

Это сайт для ИТ-профессионалов? Нет? Я ошибся? Я, как бы, и есть разработчик.

Зачем я его самостоятельно парсю? Да я его не парсю. Он слишком ужасен, чтобы браться за него. Мне пока Textile хватает. Есть у меня опенсорс проект KefirBB (ищущий да отыщет). Изначально я его запилил чтобы преобразовывать BB-коды в HTML на Java. Потому что не было в те годы адекватной библиотеки для этого, да еще и настраиваемой. Сейчас, кстати, ниче лучше тоже нету. И вот особенностью именно моего проекта является его конфигурация, которая не привязана к BB-кодам. Т.е. можно использовать его и для других целей. В последней версии (она же первая, 1.0) я в дистрибутив добавил конфигурацию для обезопашивания HTML, например. И вот решил брать новые высоты. Но каждый новый язык разметки имеет какую-нибудь конструкцию, которая, ну никак, не укладывается в мою идеология.

[Athari]

Я, как бы, и есть разработчик.

Если вы разработчик, то ваша задача — превозмогать трудности. Markdown и прочие языки парсятся один раз при изменении, поэтому вопрос эффективности парсинга практически никогда не встаёт. (А если встаёт, то эта проблема будет последней в списке приоритетов.)

И вот особенностью именно моего проекта является его конфигурация, которая не привязана к BB-кодам.

То есть вы написали библиотеку для парсинга «с запасом на будущее», чтобы парсить всё на свете, а потом оказалось, что парсить всё на свете не получилось? Ну, как бы, привычная история. Каждодневная, можно сказать. Смиритесь и переписывайте. А лучше плюньте на универсальность, потому что она миф.

BB и HTML — языки родственные, поэтому у вас всё в архитектуру красиво и вписалось. А это другой язык, совсем. Разумеется, он не всписался.

[kefirfromperm]

Имею я право, как разработчик, прежде чем начать преодолевать трудности, немного пожаловаться? :)

Вопрос эффективности парсинга встает. Не так-то быстро парсится текст уже на 100Кбайт, особенно, если там много ошибок разметки. Для Википедии — это серьезная проблема. Я сталкивался не то чтобы с серьезной проблемой, но проблема была и было решено потратить пару дней на оптимизацию. А еще есть злобные хакеры, которые закидают вас особым образом сформированными текстами, которые ваш сервер будет молотить по несколько секунд каждый.

И, поверьте, лучше использовать проверенный и оптимизированный KefirBB, в котором эти проблемы уже решены, чем писать собственный парсер. А я уж, как-нибудь этот Markdown одолею.

[macik_spb]

Если вы разработчик, то ваша задача — превозмогать трудности.

Мне сразу представился герб (или эмблема) некоей организации разработчиков — сверху знак с перечеркнутым жуком, снизу велосипед, все это в терновом венце и обрамлено лозунгом «превозмогая трудности».

[Alex_MIPT]

И всё это ещё на фоне перекрещенных костылей.

[bogolt]

Тогда уже Велосипед Багоборец поражающий костылем Ужасного Бага.

[not_ice]

Простите, не удержался.

[macik_spb]

Плюсанул. Но больше на хакерскую смахивает.
«$» и «#» особенно символичны.
И сразу рождают образы «бабки» и «за решетку».

[safinaskar]

Это вы нарисовали? Тут у вас идею взяли: yasdelie.ru

[frst]

неужели не очевидно что маркдаун сделан для того чтобы было удобно его писать, а не парсить

[e_asphyx]

А как писать, не понимая до конца его грамматики? Сколько должно быть символов «=» под заголовком? Почему я должен об этом думать?

[frst]

Что легче выучить хтмл или мд? Как правильно пишется blockquote и почему ссылка называется (a) а то куда она ведет называется href=? Почему я должен думать о закрывающих тегах?

[int19h]

Не хотите — не думайте:

# Header
## Subheader
### Subsubheader
Content.

[Mithgol]

Спецификация Standard Markdown гласит, что символов «=» под заголовком может быть сколько угодно; достаточно и всего одного, например.

[SerafimArts]

Например:

^(.+?)[ ]*\n(=+|-+)[ ]*\n+

Вот так и парсить =)

[kefirfromperm]

Кто ж такие вещи регэкспами парсит?

Во-первых, весь markdown так не распарсить, ибо нерегулярный он. Во-вторых, мееедлеееннннннооооо, очень.

Нет, ну в каких-то случаях, да, но, так-то, нет.

[SerafimArts]

Все такие вещи парсятся регекспами элементарно, ибо 0.1 секунда или 0.2 секунды — разницу не заметишь — это раз, во-вторых, парсится один раз в жизни при сохранении.

З.Ы. Предлагаю открыть исходники любой популярной библиотеки для парсинга маркдауна, вики-разметки, BB-тегов и проч., и увидеть там наличие оных регулярок.

[iroln]

Вот docutils, например: pypi.python.org/pypi/docutils

Парсит разметку reStructuredText. Есть адские регулярки, но помимо этого есть и машина состояний и т. п.

[Googolplex]

Hoedown не использует регекспы, а это одна из наиболее популярных библиотек для Markdown на C.

Мой будущий парсер тоже не будет использовать регулярки, кстати.

[kefirfromperm]

1. Не парсятся принципиально;
2. разница в скорости может достичь 2х порядков (0.1с и 10с — принципиально);
3. xBB не использует, например. KefirBB тоже.

Вот еще интересная статья про MediaWiki habrahabr.ru/post/148756/

В общем, не всё так просто как кажется.

[SerafimArts]

1. В таком случае зачем вообще регулярки нужны, как не для парсинга?
2. Парсинга сохраняемого файла, один раз за всю жизнь этого файла? Всё же, даже такие цифры (это какой объём надо парсить, чтобы их достичь?) не так уж критично для одноразовой операции.
3. Не слышал о таком — не из моей области компетенции, увы…

Имхо, думаю стоит рассчитать количество трудозатарат на количество выгоды от результата и уже потом делать выводы, т.к. любое решение имеет место, я погорячился =)

[kefirfromperm]

1. Чтобы парсить, но регулярные выражения.
2. Сохранять надо при каждом редактировании статьи, например. А ничего особенного, на самом деле, не надо парсить, чтобы достичь таких показателей — средних размеров документ с битой разметкой. Тут или парсер забивает на битую разметку и отдает битый HTML (готовы ли вы принять битый HTML на свою страницу?), либо сложность парсинга резко возрастает. Я бы мог, наверное, статью на хабр написать об особенностях парсинга. :)
3. Ну вот…

[Mithgol]

[Kain_Haart]

Нервы бесценны %)

[safinaskar]

Markdown не предназначен для того, чтобы его парсило большое количество разных программ. Т. е. markdown должен по идее парсится только одной программой, которая конвертит его в html. Лично вы, kefirfromperm, парсить markdown не должны. Если очень надо, сконвертируйте его в html (прожкой, которая должна быть для вас чёрным ящиком), а потом парсите html (благо, для парсинга html есть куча библиотек).

Ещё: markdown предназначен только для его конвертации в html. Конвертация в другие форматы (ps, pdf, TeX, man, txt, всё, что угодно) не предусмотрено. Любое другое использование markdown'а не предусмотренно. It is for design. Если вам нужен формат, умеющий конвертится куда-то ещё — не используйте markdown. Именно по этой причине это OK иметь в markdown inline html.

Может лучше использовать HTML?

Markdown проще набирать :)

[kefirfromperm]

Кто если не мы?

Есть программа на перле, а мне нужна библиотека на Java. Есть, конечно, markdownj, в которой полно replaceAll, а каждый replaceAll будет жрать памяти по размеру строки. Короче говоря, сразу видно что неэффективна она ни по памяти, ни по скорости.

Если бы все думали так как Вы, то прогресса не было бы никакого.

[VolCh]

Т. е. markdown должен по идее парсится только одной программой, которая конвертит его в html.

На каком языке, на какой платформе должна быть эта программа, какой интерфейс поддерживать? Как минимум, сейчас для популярных платформ нет единого общего «знаменателя». Это не говоря о личных предпочтениях.

[safinaskar]

Я имел в виду, что все программы, работающие с markdown, должны делать только одно — конвертить его в html. А самих конвертилок может быть много

[Googolplex]

Ну, строго говоря, для парсинга он действительно не очень удобен. Я сейчас пишу парсер Markdown на Rust и могу это подтвердить.

[safinaskar]

kefirfromperm, e_asphyx, Googolplex, Грубер: «That’s the point. I wanted Markdown to be easy for users to understand, even if hard for devs to implement.» — twitter.com/gruber/status/507582563792064512

[cuhuak]

Единственное, что мне не нравится в формате markdown это его нелогичность в оформлении заголовков в простом исполнении (4.2 ATX headers).

Сравните:
# Document Title
и
###### Sub x 6 title

Что выделяется лучше? Правильно, второй вариант. Хотя в html виде первый вариант — это h1-заголовок, а второй — h6-заголовок.

[limonte]

Используйте Setext headers.

Foo *bar*
=========

Foo *bar*
---------

[cuhuak]

Отлично! Тогда все должны это использовать, чтобы читалось и интуитивно интерпретировалось одинаково.
Но, к сожалению, все не будут так делать и, к сожалению, проблема h3-h6 все равно остается.

Единственным решением, на мой взгляд, придумать новый способ указания заголовков (//////// or ;;;;;;;;;;; or :::::::::: or .........), но это уже будет совсем не markdown.

[Athari]

Мне всегда хватало трёх уровней: ======, ------, ###. Три типа заголовков, хорошо видно, логичная иерархия. А если вам нужно 4 и более уровня заголовков, то вы пишете что-то шибко сложное. :-)

Единственным решением, на мой взгляд, придумать новый способ указания заголовков (//////// or ;;;;;;;;;;; or :::::::::: or .........)

Это ж будет ещё хуже: невозможно понять, какой уровень после какого идёт. Я скорее соглашусь на дополнительный уровень ≡≡≡≡≡≡, он хотя бы будет логичным.

[Kain_Haart]

Третий уровень было бы просто добавить например вот так:

Level1 haeder
=====================

Level2 header
---------------------

Level3 header
.....................

[ZyXI]

В ReST сделали просто: во‐первых, вы можете использовать любой из следующих символов для подчёркивания: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ (большинство символов использовать не рекомендуется). Во‐вторых, первым уровнем будет заголовок, который вы подчеркнули первым, независимо от того, как вы его подчеркнули. В‐третьих, следующий заголовок с другим стилем подчеркивания будет иметь второй уровень. Следующий заголовок с отличным от обоих предыдущих стилей будет иметь третий уровень и так далее. Попытка использовать уровень не в свою очередь (третий после первого или новый стиль подчеркивания где‐то, кроме как после заголовка наибольшего уровня) — ошибка. Недостаточная длина подчёркивания (оно должно быть, как минимум, такой же длины, что и заголовок (про fullwidth символы (= 2 символа подчёркивания) и диакритику (= 0 символов) парсер знает)) — предупреждение и никакого заголовка (предупреждение есть и в созданном HTML, и в stderr).

[Mithgol]

Так как возможно ещё и оканчивать строку решётками, то по сути разница только в отступе от левого края:

# Document Title ##########
###### Sub×6 title ########

[cuhuak]

Все верно, можно и так.
Сейчас в вашем примере эти два заголовка визуально, скорее, имеют одинаковый вес, чем существенно разный.
Сравните h1 и h6 в html представлении (конечно, все зависит от конкретных каскадных стилей) и вы поймете, о чем я.

[Mithgol]

Для того, чтобы разности версій (диффы) у простой вёрстки оставались человѣко-читаемыми.

[marapper]

Плюсую. Добавлю, что не только человекочитаемым, но и (давайте назовем это) git-читаемым.

Сейчас переводим Game Design Patterns, сайт автора и книга собирается как раз из маркдауна — отлично отслеживаются изменения, можно разбить абзац на несколько строк (в хтмл их не будет), что позвоялет пользоваться диффилками и не использовать софт-врапы, структура отлично сохраняется/переносится, и т.д.

[Biga]

Формат файла и wysiwyg редактор слабо связаны. Редактировать можно чем угодно, весь вопрос в удобочитаемом формате. В какой формат вы предлагаете сохранять в случае использования wysiwyg редактора?

[Zelgadis]

html, ибо mdown и wysiwyg решают одну и туже проблему.

[SerafimArts]

А нафига сложная вёрстка в readme файлах, например? Или как визвиг встроить в блокнот, что бы писать эти самые ридми? =)

Markdown — это тот же html, но только семантическая часть, а не визуальная. Т.е., мол, «тут» заголовок, «тут» у нас список и проч. Для описания некоторой документации, ридми и прочих мелочей — самое оно.

[GrigoryPerepechko]

>>Markdown — это тот же html, но только семантическая часть, а не визуальная.
HTML и так семантический. Визуальный — CSS. Поэтому ваше разделение не имеет смысла.

[frst]

Маркдаун приучает писать чистый и структурированный текст, это очень полезно когда даешь поредактировать вебовые документы неспециалистам, которые привыкли в ворде заголовки делать не кнопкой «заголовок» а выпадайкой «размер шрифта» и «цвет текста»

Дай таким визивиг — они будут форматировать в зависимости от настроения, сегодня align: left, завтра justify, двойные пробелы между словами для «красоты», иногда «красная строка» и т.п.

[kelegorm]

Он нужен потому, что сырые исходники читаются почти также легко, как и готовый результат экспорта в HTML. А во вторых, он хорошо отделяет логику форматирования от дизайна.

А еще в нем легко писать. Почти ничего не нужно знать, просто пишешь как есть, а редактор сам сделает все красиво.

[safinaskar]

Во, первых «стандарт де-факто TeX» — это в какой области? В каком мире? Если для набора математических текстов, то да. А если для набора документации к ПО, то напрямую TeX, как я понимаю, импользуется редко.
Markdown нужен, т. к. хочется иметь формат для простой вёрстки, но не wysiwyg.
Вот допустим, нужен формат для документации к ПО. Сложностей не надо, достаточно простоты. Но при этом хочется не wysiwyg, просто потому что, допустим, так разработчикам удобно, ну и плюс хочется исходный текст документации хранить в репозитории в виде текста (а не хранить в репе бинарный doc/rtf/odt). Тогда берём markdown, или pod, или ещё чего-нибудь такое

[lexore]

Однако, сам Джон Грубер несколько возмущён, что посторонние люди называют очередную реализацию синтаксиса «стандартной».

Мне кажется, это личные особенности автора, которые обычно обсуждаются в хабе GTD.
10 лет ничего не делать в этом отношении и возмутиться, когда другие это стали делать за него.

[Zelgadis]

Вы не правы. Автор сделал mdown для своего удобства, никого пользоваться им не заставлял. Его возмущение в том, что в названии очередного стандарта присувует слово Standard и только.

[lexore]

В этой точке зрения есть противоречие.
«Не заставлял пользоваться» не значит «не разрешал стандартизировать».
Если он это сделал и отпустил на самотек, что плохого в том, что пользователи решили прийти к какому-то своему канону?
> «standard markdown» sounds like ownership
Похоже ему просто кажется, что у него «отнимают» право на канонiчность.

[Zelgadis]

> «Не заставлял пользоваться» не значит «не разрешал стандартизировать».

Он же сказал изменить наввание и извиниться.

> Похоже ему просто кажется, что у него «отнимают» право на канонiчность.

Тут помоему любому человеку который знаешь ангельский все понятно. Название действительно не удачное. Когда я увидел первый анонс этого и не увидел этого человека в списке «комитета» я маленько возмутился сам.

[Nordvind]

Он же сказал изменить наввание и извиниться.

Ага, а еще разделегировать домен standardmarkdown.com без редиректа.

Может подскажете, что он вообще сделал в оригинальной имплементации? Каков его вклад вообще? Как человек, который не понимает, зачем нужны стандарты, может считаться хорошим программистом?

[Zelgadis]

Как что? Он ее создал: daringfireball.net/projects/markdown/ Я не понимаю пояему вы считаете, что у человека не может быть своего мнения о том как распоряжаться своим творением. Ну не нравится вам его реакция, ну байкотируйте markdown и требуйте BBCode.

[Nordvind]

Как что? Он ее создал: daringfireball.net/projects/markdown/

Вы credits почитайте (на его-же сайте) прежде чем говорить что он что-то там единолично создал.

Ну не нравится вам его реакция, ну байкотируйте markdown и требуйте BBCode.

Сами бойкотируйте что хотите. Есть хорошая идея, есть человек, который мешает ей развиваться. Все. Эта версия разметки лучше хотя-бы потому что ее делает команда профессионалов а не бородач-истеричка.

[Envek]

Ура стандартизации! Хоть какой-нибудь.

В «оригинальном» markdown'е не хватает кучи вещей (например, таблиц). А в библиотеках такой зоопарк расширений, что даже не знаешь, когда и где какую фичу маркдауна можно использовать, а когда — нельзя.

А формат — офигенный. Позволяет писать красиво оформленные текстовики с возможностью генерации HTML. Гораздо лучше какого-нибудь текстиля́.

[Envek]

Блин, как показало пристальное рассмотрение предлагаемого спека, расширения в него не входят. :-(

Они всего лишь решают проблемы оригинального спека.

[Nordvind]

Ализар,

Однако, сам Джон Грубер несколько возмущён, что посторонние люди называют очередную реализацию синтаксиса «стандартной».

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

[bachin]

Я думал, намного будет… Намного лучше будет это все. И очень плохой синтаксис, просто очень плохой синтаксис! Я думал, намного лучше это все будет. Сколько раз из одного формата данных в другой конвертировал — было намного лучше, но на этот раз как-то не удало-ось. Во-первых, парсеров мало, синтаксис — не очень…

[safinaskar]

Минусую, не надо мемы ютуба на хабр

[e_asphyx]

Всё-таки контекстно-зависимые грамматики не отличаются красотой

[dbanet]

Все современные нативные языки контекстно-зависимы.

[armed]

Грубер сбавил пыл blog.codinghorror.com/standard-markdown-is-now-common-markdown/

[cypok]

Грубер выглядит какой-то дикой истеричкой. А группе активистов из-за этого предстоит ребрендинг…

[Nordvind]

Обидно, когда такие проекты оказываются заложниками таких бородатых капризных детей (это Грубер, если что). Стоит заметить, что он еще не одобрил нового имени.

[alekciy]

в рамках проекта Standard Markdown (Standard Markdown).

Сейчас на сайте висит: «This domain was disabled at the request of John Gruber. ». Это так изначально было или все же спецификация там опубликована была?

[Mingun]

Спецификация там была. Впрочем не беда, сейчас её всё ещё можно просмотреть по адресу jgm.github.io/stmd/spec.html.

[david_mz]

В общем, Грубер наложил вето на любое использование слова Markdown (http://blog.codinghorror.com/standard-markdown-is-now-common-markdown/, последний абзац).

Формат теперь называется CommonMark: commonmark.org/

[e_asphyx]

Я всё-таки не понимаю, зачем документу с разметкой притворяться plain text документом с олдскульным форматированием пробелами и таблицами, нарисованными ASCII. Кто его будет читать в таком виде? Когда последний раз вам приходилось читать (не писать, не править) такой документ?

[Enlightened]

Регулярно читаю ридми.мд всяких библиотек прямо в IDE в совершенно сыром виде. Что я делаю не так?

[e_asphyx]

Всё так. Я, правда, для чтения кода библиотек дяже репу не клонирую, так и читаю на github. Подсветка есть и ладно.