typescript-definitive-guide icon indicating copy to clipboard operation
typescript-definitive-guide copied to clipboard

Правила вёрстки статей

Open inoyakaigor opened this issue 5 years ago • 8 comments

Коли внести изменения может каждый, то необходимо составить хотя бы базовый свод правил вёрстки: Отступы: пробелы или табы, их ширина (1/2/4/8); размер пробела между абзацами (1/2 пустых строки); отступы от заголовков глав, их размер и т.п. и т.д.

inoyakaigor avatar Mar 12 '19 16:03 inoyakaigor

@inoyakaigor вы затронули очень щекотливую для меня тему, однозначный ответ на которую, как уже можно дагодаться, я найти не смог. Если посмотреть на другие ветки, то в каждой из них настроен и commitizen и husky и конечно же prettier. И с самого начала я хотел настроит их и в мастере, но меня остановила мысль, что книга должна быть книгой. То есть, в ветке с книгой должны быть только файлы самой книге. Я даже думал в мастере сделать директорию book и в неё все что связанно с книгой кинуть... Но как видно почему-то не сделал.

Но раз уж это волнует не только меня, то все же стоит настроить автоформатирование.. Время будет сделаю. Делов на несколько десятков минут, просто конфиги перекинуть и prettier для md настроить..

nauchikus avatar Mar 12 '19 16:03 nauchikus

Именно! Книга должна быть книгой с форматированием, отступами и прочими бонусами типографики. Это как минимум добавит уверенности, что к книге относятся со всей серьёзностью, а значит она может быть полезна начинающим и уже более-менее вкатившимся в TS12.03.2019, 19:46, "nauchikus" [email protected]:@inoyakaigor вы затронули очень щекотливую для меня тему, однозначный ответ на которую, как уже можно дагодаться, я найти не смог. Если посмотреть на другие ветки, то в каждой из них настроен и commitizen и husky и конечно же prettier. И с самого начала я хотел настроит их и в мастере, но меня остановила мысль, что книга должна быть книгой. То есть, в ветке с книгой должны быть только файлы самой книге. Я даже думал в мастере сделать директорию book и в неё все что связанно с книгой кинуть... Но как видно почему-то не сделал. Но раз уж это волнует не только меня, то все же стоит настроить автоформатирование.. Время будет сделаю. Делов на несколько десятков минут, просто конфиги перекинуть и prettier для md настроить..

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

inoyakaigor avatar Mar 12 '19 16:03 inoyakaigor

@inoyakaigor не имею ничего против сказанного Вами, просто хочу уточнить, что без установления конвенций форматирования исходного markdown текста, конечная разметка вэбверсии, а уж тем более содержание не пострадает. Честно сказать я уже не помню, как именно, год назад, настраивал отображение стилей в самой книге, которая вэбверсия. А другой, впринципе, и нет. Но я все равно настрою автоформатирование если для md это возможно. Я никогда с этим не сталкивался, но кажется это возможно.

nauchikus avatar Mar 12 '19 18:03 nauchikus

@inoyakaigor я никогда до это момента не сталкивался с markdown, поэтому испытваю легкий дискомфорт из-за того, что не могу найти нужных готовых инструментов. Может быть Вам такие известны?

nauchikus avatar Mar 22 '19 19:03 nauchikus

@inoyakaigor с remark боюсь связываться. Помимо того, что у него для добовления одного правиланужно поставить несколько плагинов, так ещё я его уже использую при компиляции самой книги и мое форматирование, почему-то (уже не помню, но наверняка нато есть причина) отличается от валидного markdown. То есть ,если пропустить перед компиляцией отформатированный md текст через remark,то он выдаст .md, который я боюсь не будет совместим с моим сборщиком, который переписывать жутко долго.

Пробовал ещё prettier настроить. То что онделает, впринципе, с большой натяжкой можно назвать "стандартизацией". Он форматируетпробелы в коде и худо-бедно немного сам текст. Но в большинстве случаев он, пытаясь отформатировать код, ломает его. К тому же, существует код,который его попросту ломает. И если он такой код встречает, то не форматирует и весь другой код из текущего файла.

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

Тем более, что эта неприятность действует на нервы только тем, кто форматирует сам markdown. Остальные все равно видет правила накладываемые с помощью стилей после рендера.

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

nauchikus avatar Mar 22 '19 19:03 nauchikus

@nauchikus Я сам толком не сталкивался с markdown и не могу ничем помочь. Хотя если составить список хотелок которые нужны от рендерера md в html, то можно поискать что-то поконкретнее и там уже по результатам смотреть что делать дальше.

inoyakaigor avatar Mar 22 '19 21:03 inoyakaigor

@inoyakaigor

Хотя если составить список хотелок которые нужны от рендерера md в html, то можно поискать что-то поконкретнее и там уже по результатам смотреть что делать дальше.

Дело в том, что с какой стороныне подступись, малой кровью не отделаться. Лучший вариант для компиляции, это remark. Он сложен тем что на каждую прихоть требует плагин, который требует ещё несколько плагинов по цепочке, в каждый из которых, нужно вникать, хотя, признаюсь, это дело нескольких минут, но все же. Множество существующих плагинов теоретически могут сделать все то, что требуется Но дело омрачается тем, что каждый из них содержит изъян, который в итоге приведет к ручному самостоятельному определению правил. То есть придется отказаться от плагинов и воспользовавшись, предоставляемым самим remark, механизмом, писать свои правила, для применения их при разборе ast. Именно это мне и пришлось делать для некоторых случаев при рендере книги из .md в .html

Страшно даже не то что это долго, а то что как и в случаи с плагинами, собственные правила будут сталкиваться с ситуациями, которые невозможно предвидить сразу и которые будут являться причиной возникновения багов, на отладку которого и уйдет куча времени. А чтобы выявлять из при создании правил, нужно создать юнит тесты, которые будут проверять на соответствее правилам заданам в виде эталона для того же ast. Это реально долго.

Ну и как я уже сказал, ближе всего к решению prettier, он реально хоть как-то форматирует и текст и код. Но он, для форматирования markdown, также использует лучшее сцществующее решение, то есть remark, что в свою очередь означает наличие тех жепроблем.

Поэтому я даже не знаю что можно придумать. Время будет я обязательно ещё поэкспериментирую и с тем и другим, так как сам понимаю важность единого форматирования.

nauchikus avatar Mar 23 '19 07:03 nauchikus

@nauchikus CONVENTIONS.md есть, автоформатирование попозже подвезут. Мне кажется можно закрыть топик =),

lapkoshka avatar Dec 18 '19 19:12 lapkoshka