¿Por qué HTML no puede admitir por sí solo una función de `include`?

• Solo con HTML no existe una función de include para incluir el mismo elemento en varias páginas
• CSS puede cargar CSS y JavaScript puede cargar JS, pero resulta curioso que HTML no pueda traer HTML
• Para resolver este problema se usan diversas herramientas de JavaScript, lenguajes de plantillas y generadores de sitios estáticos
• Problemas complejos como rendimiento, seguridad, retrasos de renderizado e inclusiones circulares actúan como obstáculos para su adopción
• Muchos desarrolladores quieren una función declarativa pura de include en HTML, pero todavía no se ha incorporado al estándar web

---

La duda sobre por qué no existe una función de include en HTML

Planteamiento del problema

• Existe la incomodidad de insertar repetidamente un encabezado común en varias páginas como index.html, about.html y contact.html
• Los desarrolladores quieren reutilizar un encabezado definido una sola vez sin duplicación

Métodos alternativos que ya existen

• Un método es usar la fetch API de JavaScript para cargar HTML externo e insertarlo en el DOM
• También existen soluciones como Server Side Includes (SSI), include de PHP, generadores de sitios estáticos y lenguajes de plantillas
• Elementos HTML como <iframe> y <object> también podrían usarse, pero no son adecuados por problemas de accesibilidad, rendimiento y aislamiento de estilos
• Al final, HTML en sí no tiene una sintaxis simple de include

¿Por qué HTML no tiene esta función?

• CSS y JS tienen respectivamente sintaxis como @import o import, pero HTML no
• Los estándares web normalmente han incorporado funciones muy utilizadas por los desarrolladores, pero los includes en HTML no han corrido con esa suerte
• Razones planteadas en la discusión:
  • Posible interferencia con el funcionamiento del preload scanner
  • Problemas de layout shift/parpadeo durante la carga asíncrona
  • Complejidad para manejar includes anidados o circulares
  • Resistencia por el aumento del tráfico en el web hosting
  • Problemas de seguridad (CORS, CSP, etc.) y conflictos de timing con los eventos de carga del documento
  • O quizá simplemente porque tenía baja prioridad y no hubo una propuesta clara

Discusión relacionada

• Se está debatiendo activamente en el hilo de issues de WHATWG en GitHub #2791
• En el pasado, Chrome llegó a tener HTML Imports, pero terminó siendo eliminado por la falta de soporte en otros navegadores
• Se comparten enfoques alternativos como HTMX, Web Components, XSLT y SSI

Resumen de la reacción de la comunidad

• Como la evolución de HTML ha seguido centrada en el markup estático, sigue siendo fuerte la filosofía de excluir capacidades lógicas
• Muchas personas quieren esta función, pero la mayoría son desarrolladores individuales a quienes les cuesta hacer oír su voz en el proceso de estandarización
• También hay análisis de que sería difícil adoptarla si no se resuelven problemas complejos de rendimiento, seguridad, procesamiento de renderizado y prevención de ciclos
• Algunos desarrolladores consideran que la función de include quedó fuera simplemente por la idea de que HTML debe encargarse solo del “resultado”

Conclusión

• HTML todavía no cuenta con una función pura de include, y hay que reemplazarla con diversas herramientas y lenguajes externos
• Sin embargo, muchos desarrolladores todavía esperan una estructura de reutilización simple basada en HTML

[GN⁺]

Opiniones de Hacker News

• Históricamente, HTML era una aplicación de SGML, y SGML sí soportaba funciones de inclusión. Se podía definir una nueva "entidad" y crear una entidad de "sistema" para luego referenciarla y reemplazarla
  • Debido a la complejidad de SGML, hubo varios esfuerzos por simplificar HTML, y en ese proceso se eliminó esta clase de funcionalidad
• A finales de los 90 se intentó resolver este problema. Como webmaster del sitio web de Analog Science Fiction, estaba creando muchas páginas estáticas con el mismo encabezado y barra lateral. Así fue como descubrí las inclusiones del lado del servidor de Apache. Era una forma de mantener eso antes de conocer el principio DRY
  • Este problema se ha resuelto una y otra vez de distintas maneras. A quienes dicen que iframe es suficiente, el problema es que iframe no se expande para ajustarse al contenido. Las soluciones del lado del servidor requieren un servidor. ¿Por qué no existe una forma simple del lado del cliente? Me parece una pregunta válida
• Hubo una propuesta de funcionalidad llamada HTML Imports. Se creó como parte de Web Components
  • HTML Imports es una forma de incluir y reutilizar un documento HTML dentro de otro documento HTML
  • Google implementó la especificación propuesta en Blink, pero otras compañías se opusieron por varias razones. Mozilla expresó preocupaciones sobre la complejidad de la implementación, problemas de seguridad y la superposición con los módulos ES6. Sin apoyo de los proveedores, la propuesta fue oficialmente descontinuada
• Netscape 4 tenía una función llamada inflow layers
  • El nombre de esta funcionalidad es transclusión. Formaba parte de Project Xanadu y originalmente se consideraba una característica importante del hipertexto
  • MediaWiki usa la transclusión extensamente. A veces se siente como si los wikis fueran la forma auténtica del hipertexto
• Un frameset adecuado (no iframe) estaba pensado para cumplir esta función hace mucho tiempo. Al menos el autoajuste funcionaba bien y el usuario podía redimensionarlo
  • Hubo muchas críticas hacia los frames, pero se usaron con éxito en cosas útiles como la documentación de la API de Java
  • Creo que los framesets no sobrevivieron porque no ofrecían suficiente flexibilidad a los diseñadores. Hoy en día, en móviles, probablemente no funcionarían bien
• La funcionalidad de "Includes" se considera del lado del servidor y se procesa fuera del navegador web. HTML es del lado del cliente y no es más que una sintaxis de marcado simple, no un lenguaje de programación
  • Este es un problema resuelto. El problema de los "Includes" es una de las formas en que todos los estudiantes de diseño web aprenden PHP. En la mayoría de los CMS, los "Includes" se convierten en "partes de plantilla" y es una de las primeras cosas que se explican en la documentación
  • No hace falta usar "Includes" solo con HTML. HTML es un formato de presentación y no hace nada interesante sin CSS ni JS
• La inclusión en HTML tiene varios problemas
  • Si main.html incluye child/include1.html, y child/include1.html tiene un enlace src="include2.html", ¿a dónde debería ir el usuario al hacer clic en el enlace? Si va a include2.html, esa página carecerá de todo lo demás. Si va a main.html, ¿cómo se especifica entonces que esta vez se use include2.html y no include1.html?
  • Por otro lado, article1.html, article2.html, article3.html, etc., podrían incluir cada uno header.html, footer.html y navi.html. Pero si quieres agregar comments.html a todos los artículos, tendrías que editar todos los artículos, y al final terminarías generándolos a partir de una plantilla, con lo que el navegador ya no necesitaría soportar inclusiones
  • Si el encabezado necesita conocer el título o el pie de página quiere enlaces de siguiente/anterior, hace falta una forma de pasar esa información entre inclusiones, y al final terminas generando la página, así que las inclusiones no son la solución
  • La inclusión en HTML sería, en la práctica, inútil para la mayoría de los casos de uso
• Hay un issue abierto en WHATWG sobre este tema
  • Inclusiones del lado del cliente en HTML
• HTML sí tuvo una función de inclusión, pero perdió popularidad
  • El término real "include" pertenece a una función de XML y es lo que el artículo está pidiendo. HTML tenía un enfoque alternativo anterior a XML. Ese enfoque eran los frames. Los frames ofrecían más funciones que las inclusiones de XML, y por eso HTML no obtuvo esa característica. Los frames perdieron popularidad debido al mal uso, problemas de seguridad, accesibilidad y varios otros inconvenientes