Por que o HTML sozinho não consegue oferecer um recurso de `include`?

• Só com HTML não existe um recurso de include para incluir o mesmo elemento em várias páginas*
• CSS consegue carregar CSS, e JavaScript consegue carregar JS, mas é estranho que HTML não consiga trazer HTML
• Para resolver isso, vêm sendo usados vários JavaScript, linguagens de template e geradores de sites estáticos
• Problemas complexos de performance, segurança, atraso de renderização e includes circulares atuam como barreiras para a adoção
• Muitos desenvolvedores querem um recurso de include declarativo e puro no HTML, mas isso ainda não foi incorporado ao padrão da web

---

A dúvida sobre por que não existe um recurso de Include no HTML

A questão

• Há o incômodo de repetir o mesmo cabeçalho comum em várias páginas, como index.html, about.html e contact.html
• Os desenvolvedores querem reutilizar um cabeçalho definido uma vez só, sem duplicação

Métodos alternativos que já existem

• A forma de carregar HTML externo com a fetch API do JavaScript e inseri-lo no DOM
• Server Side Includes (SSI), include do PHP, geradores de sites estáticos e linguagens de template já existem como solução
• Elementos HTML como <iframe> e <object> também podem ser usados, mas são inadequados por causa de acessibilidade, performance e isolamento de estilos
• No fim das contas, o próprio HTML não tem uma sintaxe simples de include

Por que o HTML não tem esse recurso?

• CSS e JS têm suas próprias sintaxes @import e import, mas o HTML não
• Os padrões da web em geral incorporaram recursos muito usados pelos desenvolvedores, mas o include em HTML não seguiu esse caminho
• Motivos levantados na discussão:
  • Possível interferência no funcionamento do preload scanner
  • Problemas de layout shift/piscadas durante carregamento assíncrono
  • Complexidade no tratamento de includes aninhados ou circulares
  • Resistência ao aumento de tráfego em hospedagens web
  • Questões de segurança (CORS, CSP etc.) e conflitos de timing nos eventos de carregamento do documento
  • Ou simplesmente porque a prioridade era baixa e não havia uma proposta clara

Discussões relacionadas

• O assunto está sendo discutido ativamente na issue #2791 do WHATWG no GitHub
• No passado, o Chrome chegou a ter HTML Imports, mas o recurso foi descontinuado por causa da falta de suporte dos outros navegadores
• Estão sendo compartilhadas abordagens alternativas como HTMX, Web Components, XSLT e SSI

Resumo da reação da comunidade

• Como a evolução do HTML continua centrada em markup estático, a filosofia de excluir recursos de lógica ainda segue forte
• Muita gente quer esse recurso, mas a maioria são desenvolvedores individuais que têm dificuldade de fazer sua voz chegar ao processo de padronização
• Também há análises de que a adoção seria difícil sem resolver problemas complexos de performance, segurança, processamento de renderização e prevenção de ciclos
• Alguns desenvolvedores acham simplesmente que o recurso ficou de fora por causa da ideia de que o HTML deveria cuidar apenas do “resultado”

Conclusão

• O HTML ainda não tem um recurso puro de include, e é preciso recorrer a várias ferramentas e linguagens externas para substituir isso
• Ainda assim, muitos desenvolvedores continuam esperando uma estrutura simples de reutilização baseada em HTML

[GN⁺]

Comentários do Hacker News

• Historicamente, o HTML era uma aplicação de SGML, e o SGML suportava inclusão. Era possível definir uma nova "entidade" e criar uma entidade de "sistema" para depois referenciá-la e substituí-la
  • Devido à complexidade do SGML, houve vários esforços para simplificar o HTML, e esse recurso acabou sendo removido no processo
• No fim dos anos 90, houve tentativas de resolver esse problema. Como webmaster do site da Analog Science Fiction, eu estava criando muitas páginas estáticas com o mesmo cabeçalho e a mesma barra lateral. Foi assim que descobri os includes do lado do servidor do Apache. Era a forma de manter isso antes mesmo de eu conhecer o princípio DRY
  • Esse problema vem sendo resolvido repetidamente de várias maneiras. Para quem diz que iframe já basta, iframe não se expande para se ajustar ao conteúdo. Soluções do lado do servidor exigem um servidor. Por que não existe uma forma simples do lado do cliente? Acho que essa é uma pergunta válida
• Houve uma proposta de recurso chamada HTML Imports. Ela foi criada como parte dos Web Components
  • HTML Imports é uma forma de incluir e reutilizar um documento HTML dentro de outro documento HTML
  • O Google implementou a especificação proposta no Blink, mas outras empresas se opuseram por vários motivos. A Mozilla se preocupava com a complexidade da implementação, com questões de segurança e com a sobreposição com módulos ES6. Sem apoio dos fornecedores, a proposta foi oficialmente descontinuada
• O Netscape 4 tinha um recurso chamado inflow layers
  • O nome desse recurso é transclusion. Era parte do Project Xanadu e foi originalmente considerado um recurso importante do hipertexto
  • O MediaWiki usa transclusion extensivamente. Às vezes, parece que wikis são a verdadeira forma do hipertexto
• Um frameset adequado, e não iframe, foi pensado há muito tempo para fazer esse tipo de coisa. Pelo menos o redimensionamento automático funcionava bem e o usuário podia ajustar o tamanho
  • Houve muitas críticas aos frames, mas eles foram usados com sucesso em coisas úteis, como a documentação da API Java
  • Acho que os framesets não continuaram porque não ofereciam flexibilidade suficiente para os designers. Hoje, no mobile, eles provavelmente não funcionariam bem
• O recurso de "includes" é considerado do lado do servidor e processado fora do navegador. HTML é do lado do cliente e é apenas uma sintaxe simples de marcação, não uma linguagem de programação
  • Esse é um problema já resolvido. O problema de "includes" é como praticamente todo estudante de web design aprende PHP. Na maioria dos CMS, "includes" vira "partes de template" e é uma das primeiras coisas explicadas na documentação
  • Não há necessidade de usar "includes" apenas com HTML. HTML é um formato de apresentação e não faz nada muito interessante sem CSS e JS
• Há vários problemas com inclusão em HTML
  • Se main.html inclui child/include1.html, e child/include1.html tem um link src="include2.html", para onde o usuário deve ir ao clicar no link? Se for para include2.html, essa página ficará sem todo o resto. Se for para main.html, como indicar que desta vez deve usar include2.html e não include1.html?
  • Por outro lado, article1.html, article2.html, article3.html etc. podem cada um incluir header.html, footer.html e navi.html. Mas, se você quiser adicionar comments.html a todos os artigos, terá de editar todos eles, e aí acaba gerando os artigos a partir de um template, sem que o navegador precise dar suporte a includes
  • Se o cabeçalho precisar saber o título ou o rodapé quiser links de próximo/anterior, será necessário algum jeito de passar essa informação entre os includes, e no fim você acaba gerando a página; inclusão não é a solução
  • Inclusão em HTML provavelmente seria, na prática, inútil para a maioria dos casos de uso
• Há uma issue pública no WHATWG sobre esse tema
  • Includes do lado do cliente em HTML
• O HTML já teve algo parecido com inclusão, mas perdeu popularidade
  • O termo real "include" é um recurso de XML e corresponde ao que o artigo quer. O HTML tinha uma abordagem alternativa que existia antes do XML. Essa abordagem eram os frames. Os frames ofereciam mais recursos do que inclusão em XML, e por isso o HTML não ganhou esse recurso. Os frames perderam popularidade por uso indevido, segurança, acessibilidade e vários outros problemas