Форматировщик HTML

Большая часть HTML спокойно допускает, чтобы форматировщик свободно перестраивал пробелы, — лишние отступы между блочными элементами вроде `<div>` и `<p>` никак не сказываются на отображении, потому что браузеры схлопывают последовательности пробелов между такими элементами при рендеринге. Три конкретных случая полностью нарушают это допущение: содержимое внутри `<pre>` отображает каждый пробел и перенос строки буквально, ровно как написано; `<textarea>` относится к своему содержимому так же, поскольку призван точно воспроизводить редактируемый пользователем текст; а любой элемент с `white-space: pre` в CSS наследует такое же буквальное отображение. Форматировщик, перестраивающий пробелы внутри любого из этих блоков, меняет то, что страница реально показывает, а не только то, как выглядит исходный код, — поэтому этот форматировщик оставляет их полностью нетронутыми, вместо того чтобы применять обычные правила расстановки отступов.

Инлайновые элементы, стоящие прямо рядом с текстом, — более тонкий случай: пробел между двумя инлайновыми элементами иногда визуально значим, например промежуток между двумя словами, разнесёнными по отдельным тегам `<span>`, — поэтому форматировщик намеренно осторожен с инлайновым содержимым, предпочитая оставлять неоднозначные пробелы как есть, а не рисковать схлопнуть пробел, который выполнял реальную визуальную роль.

Страница, собранная как единый HTML-файл, часто встраивает собственный CSS внутрь блока `<style>` и собственный JavaScript внутрь блока `<script>`, и форматировщик, понимающий только HTML-теги, либо оставил бы этот встроенный код неотформатированным сплошным блоком, либо, что хуже, испортил бы его, трактуя фигурные скобки и точки с запятой как HTML-синтаксис. Передача содержимого этих блоков настоящему парсеру CSS и настоящему парсеру JavaScript соответственно означает, что весь файл — разметка, стили и поведение вместе — возвращается последовательно отформатированным, а не только внешняя HTML-структура.

Браузеры построены на модели восстановления после ошибок, специально спроектированной так, чтобы отрендерить что-то разумное даже из сильно повреждённой разметки — незакрытый тег, отсутствующая кавычка, элементы, вложенные в неверном порядке, — потому что в вебе десятилетиями накапливался несовершенный HTML в продакшене, который всё равно нужно отображать. Форматировщик не может позволить себе такую же снисходительность: чтобы переформатировать документ, ему нужно построить точное структурное понимание того, что во что вложено, а у документа с действительно несбалансированными тегами нет единственно верной структуры, которую можно было бы восстановить. Именно поэтому страница, которая совершенно нормально отображается в браузере, всё же может быть отклонена этим форматировщиком: браузер незаметно устранил неоднозначность по-своему, а инструменту, пытающемуся корректно переформатировать код, приходится сообщать о неоднозначности, а не догадываться.

Файл, который не удаётся отформатировать, очень часто оказывается вовсе не сломанным HTML, а шаблоном — Handlebars, Jinja, Blade, EJS или похожим, — который смешивает директивы шаблонизатора с разметкой, создавая документ, не являющийся сам по себе валидным самостоятельным HTML, да и не обязанный им быть. Шаблон становится настоящим, корректно сформированным HTML только после того, как его движок обработает его и подставит реальные данные. Форматирование уже отрендеренного результата, полученного после обработки шаблонизатором — например, через «Просмотр кода страницы» в браузере, — полностью решает эту проблему, поскольку такой результат представляет собой настоящий HTML без каких-либо остатков синтаксиса шаблонизатора.