Текст-картинка не проиндексируется должным образом поисковиками и статью не будут находить по ключевым словам из этой таблицы. И в поиске самого хабра по словам из таблицы статья тоже не будет попадать в выборку.
А подготовка такой картинки (сделать таблицу в другом редакторе, потом скриншотить её, затем в фотошопе уменьшать/увеличивать эту картинку по ширине с потерей качества изображения, вставлять картинку в текст с правильным обтеканием если таблица небольшая и т.п.) запросто может оказаться более геморройным делом, чем оформить таблицу в тексте с помощью html-тегов.
Я говорил скорее о том, что в некоторых таблицах столбцы превращаются в кашу, которую довольно сложно контролировать (а есть же еще мобильная версия сайта). Таким болеют и HTML, и markdown. Всё зависит от типа таблицы, и надо пробовать, прежде чем понять, выбрать для таблицы текст или картинку.
Я бы скорее дополнил совет тем, что рядом с таблицей-картинкой желательно поместить спойлер (в котором таблица текстом будет — и копировать читатель сможет, и робот с индексированием справится).
У markdown имеются проблемы с расстановкой строк: если использовать спойлер или список, то элементы располагаются сильно удаленно. Также, как и на github, хотя markdown и можно с обычным html смешивать, но он может ломаться в самый неподходящий момент.
В итоге приходится использовать обычный html.
Всё так, но они работают сильно специфически и как-то каждый раз по-разному.
В какой-то момент мы даже делали ненумерованные списки простым текстом с буллетами-тире, чтобы всё не расползалось.
Когда готовил свою статью — изначально писал в маркдауне, но при попытке опубликовать хабр обрезал чуть ли не половину. Однако методом тыка обнаружилось, что ровно то же количества текста в виде html отлично проходит. В итоге еще один лишний вечер на переверстку, и статью все-таки опубликовал, но осадок остался.
Такое бывает, если случайно прилепить абзац текста к концу списка или неаккуратно вставить разметку кода.
Заголовок смещается правее, а остаток текста пропадает вовсе, пока не разведешь их пустой строкой.
Мне кажется, это допустимый компромисс и дело привычки — как, например, запомнить, где в маркдауне картинка ![](), а где просто ссылка [](). Ну или как перекрасить заголовок в HTML-разметке — надо только чуть наловчиться.
А у вас — ус отклеился двойной дефис в тире не конвертируется.
Когда расскажете о продуктивной совместной работе? Или за это сойдет упоминание Гуглодокс и «беру текст из второго конвертера, а картинки перезаливаю»?
Доставка статей от авторов редакторам устроена довольно демократично. В Яндекс.Диск, например, встроен Word Online — если коллегам нравится пользоваться им, а не standalone-версией, никто не запрещает.
Вики — один из самых популярных внутренних инструментов для документов и статей. Лично я предпочитаю писать там, но свободу выбора инструмента никто не отменяет :-)
Ну и вообще, редакторов — десятки, если не сотни, под все платформы и на любой вкус.
На правах личного мнения, есть неплохой редактор MarkDown — Typora.
В принципе, функционал только и состоит из редактора и более ничего, умеет импотировать (конвертировать) из различных форматов в MarkDown но делает это через PanDoc и соответственно не всё там очень хорошо :)
Ещё один лайфхак. В gitlab есть встроенная web-IDE. Она умеет работать с md. Там же можно делать ревью, там же просматривать, там же редактировать, там же история правки в понятном любому разработчику виде. При этом ещё и редактировать можно в любимом редакторе. Там же можно временно хранить картинки. Ветки git, наверное, никому в такой задаче не приводятся, но они есть.
С маркдауном у Хабра проблема в том, что он не склеивает строки. Поэтому приходится проходиться по статье, написанной в маркдаун ещё одним конвертером, который конвертит маркдаун в хабровский маркдаун.
Это каким? Специально для этой цели разработал MarkConv. Помимо склеивания, он конвертит спойлеры, адреса картинок с локальных на habrastorage, относительные ссылки (удобно для содержания) и делает другие полезные вещи.
Когда-то давно я сделал свой форк pandoc и добавил туда хабросовместимый html. Потом на хабре появился маркдаун и я стал склеивать строки вместо хабра каким-то ключиком в pandoc. Последние статьи у меня написаны в org-mode.
Но есть один нюанс — если ты работаешь над статьёй не один, а есть какой-то редактор или кто-то в этом духе, то никакого маркдауна и тем более оргмода нельзя. Надо выкладывать у гуглдоки, чтобы там все делали правки.
Но есть один нюанс — если ты работаешь над статьёй не один, а есть какой-то редактор или кто-то в этом духе, то никакого маркдауна и тем более оргмода нельзя.
Можно конечно, для чего Git с GitHub существуют? Я бы даже сказал нужно. Одно из достоинств Markdown — простые дифы. К тому же разрывы строк как раз и существуют, чтобы вместо одной огромной измененной строки размером в абзац отображалась строка размером 80-120 символов.
Всё вы правильно говорите, только редакторы не знают что такое Git и работать с ним, конечно, не умеют. Редакторы исправляют косноязычность, ошибки всякие и так дале, с их точки зрения инструмент для совместной работы над текстом это именно гуглдок. Да и, к сожалению, не только с их точки зрения, а с точки зрения вообще всех, кто не программист в широком смысле этого слова.
Я начинал делать IDE для написания текстов на Хабр, но из-за нагрузки прекратил, и сейчас оно существует в виде набора полезных скриптов (которые очень заточены на мой ноутбук, и для отчуждения и превращения в удобный софт нужна значительная работа). В комментариях к этому комменту можно пожелать, какие фичи вы бы хотели видеть в такой IDE.
Бывали периоды, когда выпускал по одной хабростатье в день. А может и по нескольку, если считать помощь в вычитке другим авторам. Когда дрожащими руками делаешь перевод статьи на тридцать страниц, пытаясь успеть к концу дня, параллельно координируясь с автором, дизайнером, корректором и остальными — возникают совершенно специфические требования к удобству. Или например, если тебе нужно сделать статью по докладу, в котором 200 слайдов, которых у нас в блоге JUG.ru Group предостаточно. Это как хороший автомобиль, один раз в день в булочную можно съездить и на Оке, а вот целыми днями жить в Оке крайне не рекомендуется :-) В общем, это сложно объяснить словами, и это надо показывать пачку скриптов, написанных за последний год. Возможно, однажды я соберу их во что-то, что смогут использовать другие люди.
По запросу «convert html to markdown» нашлось несколько конвертеров, но все они не прошли быстрый тест и посыпались на тексте с несколькими тегами <code/>. Дальше копать не стал.
Предполагаю, что быстрее всего переразметить готовый HTML руками, но был бы рад ошибаться.
Я юзаю эти кривые реверсеры, и потом допиливаю руками. Не видел ещё ни одного реверсера, который работал бы хоть сколько-то осмысленно хорошо. В последний раз юзал Reverse Markdown, в принципе жить можно.
Я пишу статью на гитхабе в собственном репозитории Articles причем в GitHub формате Markdown (да, да, он существенно отличается от хабровского). С помощью своей утилиты MarkConv перегоняю их в формат хабра. Как уже писал ранее, он склеивает строки, конвертит спойлеры, меняет адреса картинок с локальных на habrastorage, преобразует относительные ссылки (удобно для содержания) и делает другие полезные вещи.
В связи с тем, что не так давно приватные репозитории стали бесплатными, можно создать приватный репозиторий для черновиков и паблик — для финальных опубликованных топиков. Пушить и туда и туда очень просто, т.к. это Git. Как следствие, получаем механизмы Issues, Pull Request, историю изменений, возможность бекапа локально или на другие сервисы.
Кстати, тоже планирую написать статью о том как писать статьи, но используя Git и GitHub (GitLab) и внешние IDE. Правда надо доделать до конца что запланировал.
Писать в гугл-доке маркдаун неудобно, конечно. Поэтому пишется как обычно, заголовки размечаются встроенными стилями, а потом, когда все правки от всех заинтересованных внесены, документ конвертируется в маркдаун.
Ёпрст, научите меня уже делать всплывающие подсказки на хабре (слово подчеркнуто пунктиром, при наведении мышой всплывает разъяснение) — а то перечитал стопицот документаций, а найти всё не могу и не могу!
Да, я заметил. Поэтому хотел бы обратить внимание хаброавторов на заложенную в этот прекрасный тэг дискриминацию по признаку наличия мышки. Просто не используйте его для того, чтобы спрятать что-то важное.
Для того чтобы напИсать «идиот» следует вставить двойные апострофы (тогда они не отображаются) затем тире-пробле-тире (тоже не видно) затем альт+255+альт+255 и букву " И" (пробел — обязательно).
Примерно — так.
На iPhone, iPad и MacBook использую Bear. Поддерживает и MD и HTML. Экспортирует так же в MD, HTML, TXT, DOCX, PDF и прочее. Моментально синхронизируется, что очень удобно, так как часто переключаюсь между девайсами.
Для предосмотра просто копирую в хабраэдитор.
Крайне сомнительный совет.
Текст-картинка не проиндексируется должным образом поисковиками и статью не будут находить по ключевым словам из этой таблицы. И в поиске самого хабра по словам из таблицы статья тоже не будет попадать в выборку.
А подготовка такой картинки (сделать таблицу в другом редакторе, потом скриншотить её, затем в фотошопе уменьшать/увеличивать эту картинку по ширине с потерей качества изображения, вставлять картинку в текст с правильным обтеканием если таблица небольшая и т.п.) запросто может оказаться более геморройным делом, чем оформить таблицу в тексте с помощью html-тегов.
Я говорил скорее о том, что в некоторых таблицах столбцы превращаются в кашу, которую довольно сложно контролировать (а есть же еще мобильная версия сайта). Таким болеют и HTML, и markdown. Всё зависит от типа таблицы, и надо пробовать, прежде чем понять, выбрать для таблицы текст или картинку.
<th width="100">Cool</th>.В итоге приходится использовать обычный html.
Всё так, но они работают сильно специфически и как-то каждый раз по-разному.
В какой-то момент мы даже делали ненумерованные списки простым текстом с буллетами-тире, чтобы всё не расползалось.
Такое бывает, если случайно прилепить абзац текста к концу списка или неаккуратно вставить разметку кода.
Заголовок смещается правее, а остаток текста пропадает вовсе, пока не разведешь их пустой строкой.
Мне кажется, это допустимый компромисс и дело привычки — как, например, запомнить, где в маркдауне картинка ![](), а где просто ссылка [](). Ну или как перекрасить заголовок в HTML-разметке — надо только чуть наловчиться.
Именно такого точно не было, возможно какой-то ещё кейс, но текст резало прямо в середине абзаца.
ус отклеилсядвойной дефис в тире не конвертируется.Когда расскажете о продуктивной совместной работе? Или за это сойдет упоминание Гуглодокс и «беру текст из второго конвертера, а картинки перезаливаю»?
Это делает Типограф.
И правда. Странно, что в справке Хабра не упомянуто.
На правах личного мнения, есть неплохой редактор MarkDown — Typora.
В принципе, функционал только и состоит из редактора и более ничего, умеет импотировать (конвертировать) из различных форматов в MarkDown но делает это через PanDoc и соответственно не всё там очень хорошо :)
Ещё один лайфхак. В gitlab есть встроенная web-IDE. Она умеет работать с md. Там же можно делать ревью, там же просматривать, там же редактировать, там же история правки в понятном любому разработчику виде. При этом ещё и редактировать можно в любимом редакторе. Там же можно временно хранить картинки. Ветки git, наверное, никому в такой задаче не приводятся, но они есть.
С маркдауном у Хабра проблема в том, что он не склеивает строки. Поэтому приходится проходиться по статье, написанной в маркдаун ещё одним конвертером, который конвертит маркдаун в хабровский маркдаун.
Это каким? Специально для этой цели разработал MarkConv. Помимо склеивания, он конвертит спойлеры, адреса картинок с локальных на habrastorage, относительные ссылки (удобно для содержания) и делает другие полезные вещи.
Когда-то давно я сделал свой форк pandoc и добавил туда хабросовместимый html. Потом на хабре появился маркдаун и я стал склеивать строки вместо хабра каким-то ключиком в pandoc. Последние статьи у меня написаны в org-mode.
Но есть один нюанс — если ты работаешь над статьёй не один, а есть какой-то редактор или кто-то в этом духе, то никакого маркдауна и тем более оргмода нельзя. Надо выкладывать у гуглдоки, чтобы там все делали правки.
Можно конечно, для чего Git с GitHub существуют? Я бы даже сказал нужно. Одно из достоинств Markdown — простые дифы. К тому же разрывы строк как раз и существуют, чтобы вместо одной огромной измененной строки размером в абзац отображалась строка размером 80-120 символов.
Всё вы правильно говорите, только редакторы не знают что такое Git и работать с ним, конечно, не умеют. Редакторы исправляют косноязычность, ошибки всякие и так дале, с их точки зрения инструмент для совместной работы над текстом это именно гуглдок. Да и, к сожалению, не только с их точки зрения, а с точки зрения вообще всех, кто не программист в широком смысле этого слова.
Достаточно было бы WISIWIG, который отображает именно так, как отобразит хабр.
Бывали периоды, когда выпускал по одной хабростатье в день. А может и по нескольку, если считать помощь в вычитке другим авторам. Когда дрожащими руками делаешь перевод статьи на тридцать страниц, пытаясь успеть к концу дня, параллельно координируясь с автором, дизайнером, корректором и остальными — возникают совершенно специфические требования к удобству. Или например, если тебе нужно сделать статью по докладу, в котором 200 слайдов, которых у нас в блоге JUG.ru Group предостаточно. Это как хороший автомобиль, один раз в день в булочную можно съездить и на Оке, а вот целыми днями жить в Оке крайне не рекомендуется :-) В общем, это сложно объяснить словами, и это надо показывать пачку скриптов, написанных за последний год. Возможно, однажды я соберу их во что-то, что смогут использовать другие люди.
Предполагаю, что быстрее всего переразметить готовый HTML руками, но был бы рад ошибаться.
Я юзаю эти кривые реверсеры, и потом допиливаю руками. Не видел ещё ни одного реверсера, который работал бы хоть сколько-то осмысленно хорошо. В последний раз юзал Reverse Markdown, в принципе жить можно.
Pandoc тоже не смог?
Я пишу статью на гитхабе в собственном репозитории Articles причем в GitHub формате Markdown (да, да, он существенно отличается от хабровского). С помощью своей утилиты MarkConv перегоняю их в формат хабра. Как уже писал ранее, он склеивает строки, конвертит спойлеры, меняет адреса картинок с локальных на habrastorage, преобразует относительные ссылки (удобно для содержания) и делает другие полезные вещи.
В связи с тем, что не так давно приватные репозитории стали бесплатными, можно создать приватный репозиторий для черновиков и паблик — для финальных опубликованных топиков. Пушить и туда и туда очень просто, т.к. это Git. Как следствие, получаем механизмы Issues, Pull Request, историю изменений, возможность бекапа локально или на другие сервисы.
Кстати, тоже планирую написать статью о том как писать статьи, но используя Git и GitHub (GitLab) и внешние IDE. Правда надо доделать до конца что запланировал.
А использовать Google Docs для Markdown… Ну, если честно, не очень.
Писать в гугл-доке маркдаун неудобно, конечно. Поэтому пишется как обычно, заголовки размечаются встроенными стилями, а потом, когда все правки от всех заинтересованных внесены, документ конвертируется в маркдаун.
Древние подсказывают, что это делается через ABBR.
О величайший и мудрейший, а
в какой священной книге это написаносам-то как узнал? :)Ссылка на это чудо чудное была прямо в статье :)
https://habr.com/ru/info/topics/madskillz/
Что-то на мобиле оно никак не смотрится… Или я просто не умею интуитивный интерфейс?
Примерно — так.
Чё?
На iPhone, iPad и MacBook использую Bear. Поддерживает и MD и HTML. Экспортирует так же в MD, HTML, TXT, DOCX, PDF и прочее. Моментально синхронизируется, что очень удобно, так как часто переключаюсь между девайсами.
Для предосмотра просто копирую в хабраэдитор.
Полный список:
TXT, MD, PDF, HTML, RTF, DOCX, JPG.