Formatador de HTML

A maior parte do HTML tolera que um formatador reorganize seus espaços em branco livremente — indentação extra entre elementos de bloco como `<div>` e `<p>` não tem nenhum efeito visível, porque navegadores colapsam sequências de espaços em branco entre esses elementos ao renderizar. Três casos específicos quebram essa suposição completamente: o conteúdo dentro de `<pre>` renderiza cada espaço e quebra de linha literalmente, exatamente como escrito; `<textarea>` trata seu conteúdo da mesma forma já que é destinado a reproduzir texto exato editável pelo usuário; e qualquer elemento carregando `white-space: pre` em CSS herda o mesmo tratamento literal. Um formatador que reorganiza espaços em branco dentro de qualquer um desses blocos muda o que a página realmente exibe, não apenas como o código-fonte parece — por isso este formatador os deixa completamente intactos em vez de aplicar suas regras habituais de indentação.

Elementos inline situados diretamente ao lado de texto são um caso mais sutil: um espaço entre dois elementos inline às vezes é visualmente significativo — o espaço entre duas palavras que abrangem tags `<span>` separadas, por exemplo — então o formatador é deliberadamente conservador com conteúdo inline, preferindo deixar espaços em branco ambíguos como estão em vez de arriscar colapsar um espaço que estava fazendo um trabalho visual real.

Uma página montada como um único arquivo HTML comumente incorpora seu próprio CSS dentro de um bloco `<style>` e seu próprio JavaScript dentro de um bloco `<script>`, e um formatador que só entende tags HTML deixaria esse código incorporado como um bloco não formatado ou, pior, o estragaria tratando chaves e pontos e vírgulas como sintaxe HTML. Entregar o conteúdo desses blocos para um analisador CSS real e um analisador JavaScript real, respectivamente, significa que o arquivo inteiro — marcação, estilos e comportamento juntos — volta formatado de forma consistente, em vez de apenas a estrutura HTML externa.

Navegadores são construídos com um modelo de recuperação de erros projetado especificamente para renderizar algo razoável mesmo a partir de marcação gravemente malformada — uma tag não fechada, uma aspa faltando, elementos aninhados em ordem inválida — porque a web tem décadas de HTML imperfeito em produção que ainda precisa ser exibido. Um formatador não pode adotar essa mesma indulgência: para reformatar um documento, ele precisa construir um entendimento estrutural preciso do que está aninhado dentro do quê, e um documento com tags genuinamente desbalanceadas não tem uma única estrutura correta a recuperar. Por isso uma página que aparece completamente normal em um navegador ainda pode ser rejeitada por este formatador — o navegador reparou silenciosamente a ambiguidade à sua maneira, enquanto uma ferramenta tentando reformatar corretamente precisa sinalizar a ambiguidade em vez de adivinhar.

Um arquivo que falha ao formatar muitas vezes não é HTML quebrado de jeito nenhum, mas um template — Handlebars, Jinja, Blade, EJS ou similar — que mistura diretivas de template com marcação, produzindo um documento que não é HTML autônomo válido por si só e nunca precisa ser. O template só se torna HTML real e bem-formado depois que seu motor de template roda e substitui os dados reais. Formatar a saída renderizada, capturada depois que o motor de template a processa — a partir do "Ver código-fonte" de um navegador, por exemplo — evita isso completamente, já que essa saída é HTML real sem nenhuma sintaxe de template restante.