Яндекс.Деньги corporate blog
Web design
Typography
Design
Social networks and communities
Comments 57
+2
>>> Таблицы — картинками

Крайне сомнительный совет.

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

А подготовка такой картинки (сделать таблицу в другом редакторе, потом скриншотить её, затем в фотошопе уменьшать/увеличивать эту картинку по ширине с потерей качества изображения, вставлять картинку в текст с правильным обтеканием если таблица небольшая и т.п.) запросто может оказаться более геморройным делом, чем оформить таблицу в тексте с помощью html-тегов.
+1


Я говорил скорее о том, что в некоторых таблицах столбцы превращаются в кашу, которую довольно сложно контролировать (а есть же еще мобильная версия сайта). Таким болеют и HTML, и markdown. Всё зависит от типа таблицы, и надо пробовать, прежде чем понять, выбрать для таблицы текст или картинку.

+1
Я бы скорее дополнил совет тем, что рядом с таблицей-картинкой желательно поместить спойлер (в котором таблица текстом будет — и копировать читатель сможет, и робот с индексированием справится).
+1
В целом атрибут width для ячеек нормально работает, что можно использовать как для большого так и малого количества текста в ячейках таблицы.

+1
в некоторых таблицах столбцы превращаются в кашу, которую довольно сложно контролировать
Легко: <th width="100">Cool</th>.
+1
Именно так. Кроме того есть альтернативный способ, чтобы ширина ячеек с малым количеством текста не была слишком короткой.

+2
У markdown имеются проблемы с расстановкой строк: если использовать спойлер или список, то элементы располагаются сильно удаленно. Также, как и на github, хотя markdown и можно с обычным html смешивать, но он может ломаться в самый неподходящий момент.
В итоге приходится использовать обычный html.
0

Всё так, но они работают сильно специфически и как-то каждый раз по-разному.
В какой-то момент мы даже делали ненумерованные списки простым текстом с буллетами-тире, чтобы всё не расползалось.


+2
Когда готовил свою статью — изначально писал в маркдауне, но при попытке опубликовать хабр обрезал чуть ли не половину. Однако методом тыка обнаружилось, что ровно то же количества текста в виде html отлично проходит. В итоге еще один лишний вечер на переверстку, и статью все-таки опубликовал, но осадок остался.
+1

Такое бывает, если случайно прилепить абзац текста к концу списка или неаккуратно вставить разметку кода.



Заголовок смещается правее, а остаток текста пропадает вовсе, пока не разведешь их пустой строкой.


Мне кажется, это допустимый компромисс и дело привычки — как, например, запомнить, где в маркдауне картинка ![](), а где просто ссылка [](). Ну или как перекрасить заголовок в HTML-разметке — надо только чуть наловчиться.

0
Заголовок смещается правее, а остаток текста пропадает вовсе, пока не разведешь их пустой строкой.

Именно такого точно не было, возможно какой-то ещё кейс, но текст резало прямо в середине абзаца.

0
А у вас — ус отклеился двойной дефис в тире не конвертируется.
Когда расскажете о продуктивной совместной работе? Или за это сойдет упоминание Гуглодокс и «беру текст из второго конвертера, а картинки перезаливаю»?
+1
Его и Хабр сейчас автоматически конвертирует во время рендера страницы. Но мы, по старинке, и через Типограф прогоняем.
0
А текст вот до сих пор нельзя. Это нужно для подписей под картинками и в таблицах.
+3
А почему Вы у себя в яндексе не используете документы яндекса? :)
0
Доставка статей от авторов редакторам устроена довольно демократично. В Яндекс.Диск, например, встроен Word Online — если коллегам нравится пользоваться им, а не standalone-версией, никто не запрещает.
+3
Вики — один из самых популярных внутренних инструментов для документов и статей. Лично я предпочитаю писать там, но свободу выбора инструмента никто не отменяет :-)
+3
Ну и вообще, редакторов — десятки, если не сотни, под все платформы и на любой вкус.

На правах личного мнения, есть неплохой редактор MarkDown — Typora.
В принципе, функционал только и состоит из редактора и более ничего, умеет импотировать (конвертировать) из различных форматов в MarkDown но делает это через PanDoc и соответственно не всё там очень хорошо :)
+1
Ползуюсь VSCode + markdownlint + отдельный репозиторий на github для синхронизации. И удобно, и есть история, и habr более менее адекватно рендерит.
+1

Ещё один лайфхак. В gitlab есть встроенная web-IDE. Она умеет работать с md. Там же можно делать ревью, там же просматривать, там же редактировать, там же история правки в понятном любому разработчику виде. При этом ещё и редактировать можно в любимом редакторе. Там же можно временно хранить картинки. Ветки git, наверное, никому в такой задаче не приводятся, но они есть.

+2

С маркдауном у Хабра проблема в том, что он не склеивает строки. Поэтому приходится проходиться по статье, написанной в маркдаун ещё одним конвертером, который конвертит маркдаун в хабровский маркдаун.

0

Это каким? Специально для этой цели разработал MarkConv. Помимо склеивания, он конвертит спойлеры, адреса картинок с локальных на habrastorage, относительные ссылки (удобно для содержания) и делает другие полезные вещи.

0

Когда-то давно я сделал свой форк pandoc и добавил туда хабросовместимый html. Потом на хабре появился маркдаун и я стал склеивать строки вместо хабра каким-то ключиком в pandoc. Последние статьи у меня написаны в org-mode.


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

0
Но есть один нюанс — если ты работаешь над статьёй не один, а есть какой-то редактор или кто-то в этом духе, то никакого маркдауна и тем более оргмода нельзя.

Можно конечно, для чего Git с GitHub существуют? Я бы даже сказал нужно. Одно из достоинств Markdown — простые дифы. К тому же разрывы строк как раз и существуют, чтобы вместо одной огромной измененной строки размером в абзац отображалась строка размером 80-120 символов.

0

Всё вы правильно говорите, только редакторы не знают что такое Git и работать с ним, конечно, не умеют. Редакторы исправляют косноязычность, ошибки всякие и так дале, с их точки зрения инструмент для совместной работы над текстом это именно гуглдок. Да и, к сожалению, не только с их точки зрения, а с точки зрения вообще всех, кто не программист в широком смысле этого слова.

+2
Я начинал делать IDE для написания текстов на Хабр, но из-за нагрузки прекратил, и сейчас оно существует в виде набора полезных скриптов (которые очень заточены на мой ноутбук, и для отчуждения и превращения в удобный софт нужна значительная работа). В комментариях к этому комменту можно пожелать, какие фичи вы бы хотели видеть в такой IDE.
0
Прям IDE? o_O
Достаточно было бы WISIWIG, который отображает именно так, как отобразит хабр.
+1

Бывали периоды, когда выпускал по одной хабростатье в день. А может и по нескольку, если считать помощь в вычитке другим авторам. Когда дрожащими руками делаешь перевод статьи на тридцать страниц, пытаясь успеть к концу дня, параллельно координируясь с автором, дизайнером, корректором и остальными — возникают совершенно специфические требования к удобству. Или например, если тебе нужно сделать статью по докладу, в котором 200 слайдов, которых у нас в блоге JUG.ru Group предостаточно. Это как хороший автомобиль, один раз в день в булочную можно съездить и на Оке, а вот целыми днями жить в Оке крайне не рекомендуется :-) В общем, это сложно объяснить словами, и это надо показывать пачку скриптов, написанных за последний год. Возможно, однажды я соберу их во что-то, что смогут использовать другие люди.

0
По запросу «convert html to markdown» нашлось несколько конвертеров, но все они не прошли быстрый тест и посыпались на тексте с несколькими тегами <code/>. Дальше копать не стал.

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

Я юзаю эти кривые реверсеры, и потом допиливаю руками. Не видел ещё ни одного реверсера, который работал бы хоть сколько-то осмысленно хорошо. В последний раз юзал Reverse Markdown, в принципе жить можно.

0

Я пишу статью на гитхабе в собственном репозитории Articles причем в GitHub формате Markdown (да, да, он существенно отличается от хабровского). С помощью своей утилиты MarkConv перегоняю их в формат хабра. Как уже писал ранее, он склеивает строки, конвертит спойлеры, меняет адреса картинок с локальных на habrastorage, преобразует относительные ссылки (удобно для содержания) и делает другие полезные вещи.


В связи с тем, что не так давно приватные репозитории стали бесплатными, можно создать приватный репозиторий для черновиков и паблик — для финальных опубликованных топиков. Пушить и туда и туда очень просто, т.к. это Git. Как следствие, получаем механизмы Issues, Pull Request, историю изменений, возможность бекапа локально или на другие сервисы.


Кстати, тоже планирую написать статью о том как писать статьи, но используя Git и GitHub (GitLab) и внешние IDE. Правда надо доделать до конца что запланировал.

0

А использовать Google Docs для Markdown… Ну, если честно, не очень.

0

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

0
Ёпрст, научите меня уже делать всплывающие подсказки на хабре (слово подчеркнуто пунктиром, при наведении мышой всплывает разъяснение) — а то перечитал стопицот документаций, а найти всё не могу и не могу!
0

Древние подсказывают, что это делается через ABBR.


abbr title="тэг Abbr">ABBR</abbr

0

О величайший и мудрейший, а в какой священной книге это написано сам-то как узнал? :)

0

Что-то на мобиле оно никак не смотрится… Или я просто не умею интуитивный интерфейс?

+2
Да, я заметил. Поэтому хотел бы обратить внимание хаброавторов на заложенную в этот прекрасный тэг дискриминацию по признаку наличия мышки. Просто не используйте его для того, чтобы спрятать что-то важное.
0
Кстати, да. Забыл его упомянуть в посте, неплохая альтернатива gdocs.
-2
Для того чтобы напИсать «идиот» следует вставить двойные апострофы (тогда они не отображаются) затем тире-пробле-тире (тоже не видно) затем альт+255+альт+255 и букву " И" (пробел — обязательно).
Примерно — так.
0
1. Разбивайте текст на абзацы
..., но при этом не превращайте статью в распечатку чата, начиная каждое предложение с новой строки.
0

На iPhone, iPad и MacBook использую Bear. Поддерживает и MD и HTML. Экспортирует так же в MD, HTML, TXT, DOCX, PDF и прочее. Моментально синхронизируется, что очень удобно, так как часто переключаюсь между девайсами.
Для предосмотра просто копирую в хабраэдитор.

Only those users with full accounts are able to leave comments., please.