Комментарии 32
Почему не 2yaml?
И почему не 2tree?
На мой взгляд, yaml хуже поддается минимизации, из-за этого я и отбросил его. Но, на самом деле, это не особо принципиально, если есть желание уйти от html
Как обычно мы храним в базе данных что-то, что нужно показать пользователю и обладает некоторыми свойствами разметки? Кто хотя бы раз делал свой блог, хабр или похожее сразу скажет — html.
Тот, кто попробовал это сделать и поддерживать, скажет "никакого html". Потому что задолбаешься дырки в безопасности закрывать.
Я вот по умолчанию беру markdown, а в рабочем проекте какой-то собственный вики-язык.
Полностью согласен, об этом я и попытался рассказать в статье.
А формат тут при чём? Те же дырки в безопасности у вас будут и с любым другим форматом данных.
А ровно при том, что при моем собственном "формате форматирования" в нем есть только те возможности, которые я туда принес. Не надо думать, как выпилить скрипты или не дать пользователю сломать мою верстку.
html вас тоже никто не заставляет вставлять на станицу как есть через innerHTML. Можете точно так же парсить и формировать дом вручную как с любым другим форматом.
Можете точно так же парсить и формировать дом вручную как с любым другим форматом.
Вот только парсинг html — это веселое развлечение само по себе, я предпочитаю с ним дела не иметь, если могу.
Учитывая поражение xhtml задача парсинга гипертекста осложняется.
Не читайте жёлтых газет перед сном.
https://html.spec.whatwg.org/#html-vs-xhtml
9.2% и падает. https://w3techs.com/technologies/details/ml-xhtml
Потому что задолбаешься дырки в безопасности закрывать.
А можно полюбопытствовать, что там в безопасности ещё нужно закрывать, помимо заведения белого списка тегов, атрибутов и значений атрибутов?
Да как бы необходимость следить за белым списком и тем, что никто не придумал, как его обойти — это уже достаточно заводно, чтобы этого не делать.
необходимость следить за белым списком
Но ведь такой необходимости нет — на то он и белый, а не чёрный
и тем, что никто не придумал, как его обойти
Звучит нереалистично, можно примеры обхода белого списка? (Очевидные косяки настройки вроде разрешения всех доменов в iframe не в счёт)
Но ведь такой необходимости нет — на то он и белый, а не чёрный
Есть-есть. Вам надо его завести, добавить в редактор, а потом отбиваться от пользователей и партнеров, которые говорят "ну чувааак, ну добавь <img>, у тебя же html, тебе ничегооо не стооооит".
Звучит нереалистично, можно примеры обхода белого списка?
Сейчас сходу не помню, но у нас как только санитайзер не ломался.
ну чувааак, ну добавь
Ну это уже не технические проблемы)
А примеры всё-таки было бы интересно глянуть. Просто так «ломать» я и сам всех по-всякому ломал (таки хороший повод отказаться от html), но так, чтобы вышло что-то похожее на уязвимость, у меня никогда не получалось
Вам надо его завести, добавить в редактор, а потом отбиваться от пользователей и партнеров, которые говорят «ну чувааак, ну добавь , у тебя же html, тебе ничегооо не стооооит».Так и в «собственный вики-язык» могут попросить что-нибудь добавить.
Давным-давно есть такая вещь как XML, а для преобразования его — XSLT.
Я так и не понял, чем плох стандартный вариант, когда хранится "голый" html, а потом уже навешиваются стили, которые в любой момент можно поменять.
Зачем хранить срендеренный html в БД? Это же очень неудобно.
Отказ от редакторов, использующих html
Есть симпатичный с виду Editor.js сохраняющий результат ввода как раз в JSON
Есть же редакторы типа https://prosemirror.net/ которые дают документ в JSON, а генерация HTML по JSON может быть любая + можно обновлять генерацию не меняя уже созданные документы.
На основе https://prosemirror.net/ есть еще https://tiptap.dev/ для тех, кто использует VueJS.
html2json