Comments 18
Если вы уж решили, что эта тема настолько важна и заслуживает статьи на публичном ресурсе, а также одним из доводов привели скорость парсинга, тогда уж хотя бы эту скорость протестируйте, пожалуйста.
Что меня больше всего удивляет, так это то что люди (и роботы) до сих пор ставят пробел перед />
.
Короче, я так понял, что единственный разумный аргумент против - то что браузеры дружно на это забили.
Как человек, повидавший уже многое и написавший довольно большое количество кода сам, я позволю себе немного переформулировать: большинство браузеров на это, скорее всего, забили, но мы хз что будет делать очередной новый мобильный китайский браузер, так что, на всякий случай, лучше помнить об этом и закрывать эти теги. С пробелом.
Я бы не стал пытаться написать JSON так, чтобы его можно было разобрать парсером YAML
Эм… Плохой пример, ведь YAML является надмножеством JSON, то есть, JSON-документ — это буквально валидный YAML-документ. YAML специально спроектировали таким образом ради совместимости с JSON.
YAML является надмножеством JSON
Вы приводите ссылку на какую-то библиотеку для Perl, автор которой признается что ему не всегда удаётся правильно вывести JSON чтобы он читался YAML-парсером.
Надо отметить что это личная проблема этого автора и пользователей его библиотеки.
Спецификация YAML прямо говорит что YAML v1.2 имела своей прямой целью сделать YAML строгим надмножеством JSON.
Товарищ по моей ссылке приводит примеры конкретных конструкций, допустимых в JSON, но недопустимых в YAML. И о том что говорит спецификация YAML он тоже упоминает.
А как у YAML с отформатированным JSON? Не спотыкается? (Реально интересно, я сам не пробовал)
Интересно. По ссылке автор утверждает, что даже спецификация YAML 1.2 (в которой самой прямым текстом сказано, что её цель была устранить все ранее выявленные несовместимости с JSON прошлых версий спецификации) по-прежнему остаётся несовместимой. Правда, на текущий момент последней является ревизия 1.2.2 от 2021-10-01, а текст по ссылке написан 2020-10-27, может быть, что-то и поменялось с тех пор. К сожалению, без более глубокого погружения в текст спецификации нельзя сказать, действительно ли это её проблема, либо же имеет место бага в приведённой библиотеке.
А как быть с web components и кастомными элементами? Браузер не будет знать, должен этот тэг быть самозакрывающимся всегда или нет, поэтому не определено поведение на случай не закрытого тэга. Поэтому рекомендация "давайте не будем использовать само закрывающийся синтаксис" означает что мы не можем писать <custom-input/>
В шаблоне Vue самозакрывающийся div вполне можно использовать. Особенно с атрибутом v-html. Парсится правильно. Но, на мой взгляд, это плохая практика. Лучше всё-таки поставить закрывающий </div>, чтобы не плодить диалекты.
Доводы против самозакрывающихся тегов в HTML