Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 92

К тому же, в консорциуме W3C некоторое время назад создали группу Markdown Community Group, которая и должна координировать усилия по выработке единой версии Markdown. Работа и выпуск «стандартных» спецификаций за их спиной — по меньшей мере, показатель некоторого неуважения к тем, кто потратил время и усилия на этот проект.
За два года эта группа что-нибудь родила? Если нет, то в топку эту группу! Я рад, что кто-то потратил время и предложил что-то дельное в этом отношении!
Всего голосов 55: ↑55 и ↓0 +55
За два года эта группа что-нибудь родила? Если нет, то в топку эту группу!
Боюсь, так весь W3C разогнать придётся :)
Всего голосов 35: ↑33 и ↓2 +31
Давно пора :)
Всего голосов 12: ↑8 и ↓4 +4
Стесняюсь спросить, принимали ли вы когда-нибудь участие в работе W3C.
Всего голосов 14: ↑13 и ↓1 +12
На всякий случай обращу внимание спешащей высказаться относительно W3C публики на посты forgotten'а, который принимает непосредственное участие в ряде обсуждений.
Всего голосов 4: ↑4 и ↓0 +4
Нагляднее всего текущее состояние Маркдаун-экосистемы проиллюстрировано здесь.

Да, это 23 различных библиотеки M↓, которые выдают 15 разных HTML-рендерингов для одной несложной разметки. Да, и некоторые из результатов существенно отличаются по семантике выводимого, а не только по обработке пробелов и отсутпов.
Всего голосов 5: ↑5 и ↓0 +5
НЛО прилетело и опубликовало эту надпись здесь
А вы дюже остроглазы!
Всего голосов 9: ↑8 и ↓1 +7
НЛО прилетело и опубликовало эту надпись здесь
Замечательно. Если к команде подключится еще и Википедия, то успех и взлёт популярности гарантирован.
Всего голосов 8: ↑4 и ↓4 0
Если к команде подключится ещё и Википедия
Википедия не пользуется Markdown, у неё свой стиль вики-разметки MediaWiki. Переход Википедии ни на какой другой язык разметки осуществляться, естественно, не будет из-за общей консервативности редакторов, количества страниц и общей неудобности решений вроде Markdown для Википедии.
Всего голосов 17: ↑17 и ↓0 +17
Ужасный, ужасный для парсинга формат. Ужасный. Ужасно. Ужасно всё это!
Всего голосов 43: ↑12 и ↓31 -19
Чем он ужасен?
Всего голосов 6: ↑6 и ↓0 +6
Вот эти заголовки
==============

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

Inline HTML — никогда не понимал этого. Зачем придумывать язык разметки, если в нем все равно можно использовать HTML? Может лучше использовать HTML?
Блоки кода, как понять когда он кончился?
Списки. Списки мне много крови попили. Но это общая проблема для BB, Textile, Wiki, Markdown. Никак их адекватно и быстро не распарсить. Не могу придумать.
Всего голосов 20: ↑11 и ↓9 +2
html требует усилию по «обезопашиванию».
Комментарий пока не оценивали 0
В том то и дело! И в составе Markdown он опять требует все те же усилия по обезопашиванию, даже больше. Потому что появляется больше хитрых комбинаций разметки, которые надо учесть разработчику транслятора, чтобы не допустить XSS-ов всяких.
Всего голосов 8: ↑4 и ↓4 0
А, извините, я не понял, что вы именно про использование Html внутри markdown.
Всего голосов 1: ↑1 и ↓0 +1
Так в спецификации же прописаны два типа заголовков, включая
# ATX Headers

А насчёт понимания, когда кончился, — кажется, ради этого стандарт и придумывался, чтобы чётко описать.
Всего голосов 2: ↑2 и ↓0 +2
Это пользователь может выбирать. Разработчик транслятора должен предусмотреть все случаи. Я же именно про парсинг написал, не про использование. Как пользователю он мне очень нравится. Сам им пользуюсь, с удовольствием. Ридми файлы очень красивые получаются.
Всего голосов 2: ↑1 и ↓1 0
Зачем придумывать язык разметки, если в нем все равно можно использовать HTML? Может лучше использовать HTML?
Наверное, потому что писать в разметке HTML неудобно? Ради этого всё и затевалось ведь. Возможность использовать HTML внутри разметки покрывает тот ~1% случаев, когда это бывает необходимо.

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

А вы зачем его самостоятельно парсите кстати?
Всего голосов 12: ↑11 и ↓1 +10
Это сайт для ИТ-профессионалов? Нет? Я ошибся? Я, как бы, и есть разработчик.

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

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

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

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

BB и HTML — языки родственные, поэтому у вас всё в архитектуру красиво и вписалось. А это другой язык, совсем. Разумеется, он не всписался.
Всего голосов 12: ↑12 и ↓0 +12
Имею я право, как разработчик, прежде чем начать преодолевать трудности, немного пожаловаться? :)

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

И, поверьте, лучше использовать проверенный и оптимизированный KefirBB, в котором эти проблемы уже решены, чем писать собственный парсер. А я уж, как-нибудь этот Markdown одолею.
Всего голосов 12: ↑7 и ↓5 +2
Если вы разработчик, то ваша задача — превозмогать трудности.


Мне сразу представился герб (или эмблема) некоей организации разработчиков — сверху знак с перечеркнутым жуком, снизу велосипед, все это в терновом венце и обрамлено лозунгом «превозмогая трудности».
Всего голосов 18: ↑18 и ↓0 +18
И всё это ещё на фоне перекрещенных костылей.
Всего голосов 9: ↑9 и ↓0 +9
Тогда уже Велосипед Багоборец поражающий костылем Ужасного Бага.
Всего голосов 1: ↑1 и ↓0 +1
Простите, не удержался.
Всего голосов 27: ↑27 и ↓0 +27
Плюсанул. Но больше на хакерскую смахивает.
«$» и «#» особенно символичны.
И сразу рождают образы «бабки» и «за решетку».
Комментарий пока не оценивали 0
неужели не очевидно что маркдаун сделан для того чтобы было удобно его писать, а не парсить
Всего голосов 17: ↑17 и ↓0 +17
А как писать, не понимая до конца его грамматики? Сколько должно быть символов «=» под заголовком? Почему я должен об этом думать?
Комментарий пока не оценивали 0
Что легче выучить хтмл или мд? Как правильно пишется blockquote и почему ссылка называется (a) а то куда она ведет называется href=? Почему я должен думать о закрывающих тегах?
Всего голосов 8: ↑8 и ↓0 +8
Не хотите — не думайте:
# Header
## Subheader
### Subsubheader
Content.
Всего голосов 5: ↑5 и ↓0 +5
Спецификация Standard Markdown гласит, что символов «=» под заголовком может быть сколько угодно; достаточно и всего одного, например.
Всего голосов 2: ↑2 и ↓0 +2
Например:
^(.+?)[ ]*\n(=+|-+)[ ]*\n+

Вот так и парсить =)
Всего голосов 5: ↑3 и ↓2 +1
Кто ж такие вещи регэкспами парсит?

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

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

З.Ы. Предлагаю открыть исходники любой популярной библиотеки для парсинга маркдауна, вики-разметки, BB-тегов и проч., и увидеть там наличие оных регулярок.
Всего голосов 8: ↑0 и ↓8 -8
Вот docutils, например: pypi.python.org/pypi/docutils

Парсит разметку reStructuredText. Есть адские регулярки, но помимо этого есть и машина состояний и т. п.
Комментарий пока не оценивали 0
Hoedown не использует регекспы, а это одна из наиболее популярных библиотек для Markdown на C.

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

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

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

Имхо, думаю стоит рассчитать количество трудозатарат на количество выгоды от результата и уже потом делать выводы, т.к. любое решение имеет место, я погорячился =)
Всего голосов 2: ↑1 и ↓1 0
1. Чтобы парсить, но регулярные выражения.
2. Сохранять надо при каждом редактировании статьи, например. А ничего особенного, на самом деле, не надо парсить, чтобы достичь таких показателей — средних размеров документ с битой разметкой. Тут или парсер забивает на битую разметку и отдает битый HTML (готовы ли вы принять битый HTML на свою страницу?), либо сложность парсинга резко возрастает. Я бы мог, наверное, статью на хабр написать об особенностях парсинга. :)
3. Ну вот…
Всего голосов 3: ↑3 и ↓0 +3
[xkcd: Is It Worth the Time?]
Всего голосов 6: ↑5 и ↓1 +4
Нервы бесценны %)
Комментарий пока не оценивали 0
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 проще набирать :)
Всего голосов 7: ↑5 и ↓2 +3
Кто если не мы?

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

Если бы все думали так как Вы, то прогресса не было бы никакого.
Всего голосов 4: ↑4 и ↓0 +4
Т. е. markdown должен по идее парсится только одной программой, которая конвертит его в html.

На каком языке, на какой платформе должна быть эта программа, какой интерфейс поддерживать? Как минимум, сейчас для популярных платформ нет единого общего «знаменателя». Это не говоря о личных предпочтениях.
Комментарий пока не оценивали 0
Я имел в виду, что все программы, работающие с markdown, должны делать только одно — конвертить его в html. А самих конвертилок может быть много
Всего голосов 1: ↑1 и ↓0 +1
Ну, строго говоря, для парсинга он действительно не очень удобен. Я сейчас пишу парсер Markdown на Rust и могу это подтвердить.
Всего голосов 2: ↑2 и ↓0 +2
Единственное, что мне не нравится в формате markdown это его нелогичность в оформлении заголовков в простом исполнении (4.2 ATX headers).

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

Что выделяется лучше? Правильно, второй вариант. Хотя в html виде первый вариант — это h1-заголовок, а второй — h6-заголовок.
Всего голосов 8: ↑8 и ↓0 +8
Используйте Setext headers.

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

Foo *bar*
---------
Всего голосов 2: ↑2 и ↓0 +2
Отлично! Тогда все должны это использовать, чтобы читалось и интуитивно интерпретировалось одинаково.
Но, к сожалению, все не будут так делать и, к сожалению, проблема h3-h6 все равно остается.

Единственным решением, на мой взгляд, придумать новый способ указания заголовков (//////// or ;;;;;;;;;;; or :::::::::: or .........), но это уже будет совсем не markdown.
Всего голосов 1: ↑1 и ↓0 +1
Мне всегда хватало трёх уровней: ======, ------, ###. Три типа заголовков, хорошо видно, логичная иерархия. А если вам нужно 4 и более уровня заголовков, то вы пишете что-то шибко сложное. :-)

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

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

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

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

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

# Document Title ##########
###### Sub×6 title ########
Всего голосов 7: ↑5 и ↓2 +3
Все верно, можно и так.
Сейчас в вашем примере эти два заголовка визуально, скорее, имеют одинаковый вес, чем существенно разный.
Сравните h1 и h6 в html представлении (конечно, все зависит от конкретных каскадных стилей) и вы поймете, о чем я.
Комментарий пока не оценивали 0
НЛО прилетело и опубликовало эту надпись здесь
Для того, чтобы разности версій (диффы) у простой вёрстки оставались человѣко-читаемыми.
Всего голосов 22: ↑15 и ↓7 +8
Плюсую. Добавлю, что не только человекочитаемым, но и (давайте назовем это) git-читаемым.

Сейчас переводим Game Design Patterns, сайт автора и книга собирается как раз из маркдауна — отлично отслеживаются изменения, можно разбить абзац на несколько строк (в хтмл их не будет), что позвоялет пользоваться диффилками и не использовать софт-врапы, структура отлично сохраняется/переносится, и т.д.
Всего голосов 1: ↑1 и ↓0 +1
Формат файла и wysiwyg редактор слабо связаны. Редактировать можно чем угодно, весь вопрос в удобочитаемом формате. В какой формат вы предлагаете сохранять в случае использования wysiwyg редактора?
Всего голосов 3: ↑3 и ↓0 +3
html, ибо mdown и wysiwyg решают одну и туже проблему.
Всего голосов 3: ↑0 и ↓3 -3
А нафига сложная вёрстка в readme файлах, например? Или как визвиг встроить в блокнот, что бы писать эти самые ридми? =)

Markdown — это тот же html, но только семантическая часть, а не визуальная. Т.е., мол, «тут» заголовок, «тут» у нас список и проч. Для описания некоторой документации, ридми и прочих мелочей — самое оно.
Всего голосов 3: ↑2 и ↓1 +1
>>Markdown — это тот же html, но только семантическая часть, а не визуальная.
HTML и так семантический. Визуальный — CSS. Поэтому ваше разделение не имеет смысла.
Всего голосов 1: ↑1 и ↓0 +1
Маркдаун приучает писать чистый и структурированный текст, это очень полезно когда даешь поредактировать вебовые документы неспециалистам, которые привыкли в ворде заголовки делать не кнопкой «заголовок» а выпадайкой «размер шрифта» и «цвет текста»

Дай таким визивиг — они будут форматировать в зависимости от настроения, сегодня align: left, завтра justify, двойные пробелы между словами для «красоты», иногда «красная строка» и т.п.
Всего голосов 13: ↑13 и ↓0 +13
Он нужен потому, что сырые исходники читаются почти также легко, как и готовый результат экспорта в HTML. А во вторых, он хорошо отделяет логику форматирования от дизайна.

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

Мне кажется, это личные особенности автора, которые обычно обсуждаются в хабе GTD.
10 лет ничего не делать в этом отношении и возмутиться, когда другие это стали делать за него.
Всего голосов 25: ↑25 и ↓0 +25
Вы не правы. Автор сделал mdown для своего удобства, никого пользоваться им не заставлял. Его возмущение в том, что в названии очередного стандарта присувует слово Standard и только.
Всего голосов 2: ↑1 и ↓1 0
В этой точке зрения есть противоречие.
«Не заставлял пользоваться» не значит «не разрешал стандартизировать».
Если он это сделал и отпустил на самотек, что плохого в том, что пользователи решили прийти к какому-то своему канону?
> «standard markdown» sounds like ownership
Похоже ему просто кажется, что у него «отнимают» право на канонiчность.
Комментарий пока не оценивали 0
> «Не заставлял пользоваться» не значит «не разрешал стандартизировать».

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

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

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

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

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


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

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

Сами бойкотируйте что хотите. Есть хорошая идея, есть человек, который мешает ей развиваться. Все. Эта версия разметки лучше хотя-бы потому что ее делает команда профессионалов а не бородач-истеричка.
Всего голосов 1: ↑1 и ↓0 +1
Ура стандартизации! Хоть какой-нибудь.

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

А формат — офигенный. Позволяет писать красиво оформленные текстовики с возможностью генерации HTML. Гораздо лучше какого-нибудь текстиля́.
Всего голосов 9: ↑9 и ↓0 +9
Блин, как показало пристальное рассмотрение предлагаемого спека, расширения в него не входят. :-(

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

Проблема в том, что он заявил, что вообще не хочет стандарта. Он написал свой глючный парсер на перле, забил на все и периодически гавкает на людей, которые пытаются все это структурировать.
Всего голосов 14: ↑14 и ↓0 +14
Я думал, намного будет… Намного лучше будет это все. И очень плохой синтаксис, просто очень плохой синтаксис! Я думал, намного лучше это все будет. Сколько раз из одного формата данных в другой конвертировал — было намного лучше, но на этот раз как-то не удало-ось. Во-первых, парсеров мало, синтаксис — не очень…
Всего голосов 19: ↑2 и ↓17 -15
Минусую, не надо мемы ютуба на хабр
Всего голосов 9: ↑2 и ↓7 -5
Всё-таки контекстно-зависимые грамматики не отличаются красотой
Комментарий пока не оценивали 0
Все современные нативные языки контекстно-зависимы.
Комментарий пока не оценивали 0
Грубер выглядит какой-то дикой истеричкой. А группе активистов из-за этого предстоит ребрендинг…
Всего голосов 7: ↑7 и ↓0 +7
Обидно, когда такие проекты оказываются заложниками таких бородатых капризных детей (это Грубер, если что). Стоит заметить, что он еще не одобрил нового имени.
Всего голосов 4: ↑4 и ↓0 +4
в рамках проекта Standard Markdown (Standard Markdown).

Сейчас на сайте висит: «This domain was disabled at the request of John Gruber. ». Это так изначально было или все же спецификация там опубликована была?
Комментарий пока не оценивали 0
Спецификация там была. Впрочем не беда, сейчас её всё ещё можно просмотреть по адресу jgm.github.io/stmd/spec.html.
Комментарий пока не оценивали 0
В общем, Грубер наложил вето на любое использование слова Markdown (http://blog.codinghorror.com/standard-markdown-is-now-common-markdown/, последний абзац).

Формат теперь называется CommonMark: commonmark.org/
Всего голосов 5: ↑5 и ↓0 +5
Я всё-таки не понимаю, зачем документу с разметкой притворяться plain text документом с олдскульным форматированием пробелами и таблицами, нарисованными ASCII. Кто его будет читать в таком виде? Когда последний раз вам приходилось читать (не писать, не править) такой документ?
Комментарий пока не оценивали 0
Регулярно читаю ридми.мд всяких библиотек прямо в IDE в совершенно сыром виде. Что я делаю не так?
Всего голосов 3: ↑3 и ↓0 +3
Всё так. Я, правда, для чтения кода библиотек дяже репу не клонирую, так и читаю на github. Подсветка есть и ладно.
Всего голосов 1: ↑1 и ↓0 +1
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Разблокировать темную тему

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr