▲

HTML은 왜 단독으로 'include' 기능을 지원하지 못할까?

 (frontendmasters.com)
2P by GN⁺ 9일전 | ★ favorite | 댓글 1개
  • HTML만으로는 동일한 요소를 여러 페이지에 포함시킬 수 있는 include 기능이 없음*
  • CSS는 CSS를, JavaScript는 JS를 불러올 수 있지만, HTML은 HTML을 가져올 수 없다는 점이 의문
  • 이 문제를 해결하려 다양한 JavaScript, 템플릿 언어, 정적 사이트 생성기 등이 사용되고 있음
  • 퍼포먼스, 보안, 렌더링 지연, 순환 포함 등 복잡한 문제들이 도입의 걸림돌로 작용
  • 많은 개발자들이 HTML에 순수한 declarative include 기능을 원하지만, 아직 웹 표준에는 반영되지 않음

HTML에서 Include 기능이 없는 이유에 대한 의문

문제 제기

  • index.html, about.html, contact.html 등 여러 페이지에서 공통 헤더를 반복적으로 삽입하는 불편함이 있음
  • 개발자들은 중복 없이 한 번 정의한 헤더를 재사용하고 싶어함

이미 존재하는 대체 방법들

  • JavaScript의 fetch API로 외부 HTML을 불러와 DOM에 삽입하는 방법
  • 서버 사이드 인클루드(SSI), PHP의 include, 정적 사이트 생성기, 템플릿 언어 등이 해결책으로 존재함
  • <iframe>과 <object> 같은 HTML 요소도 가능하나 접근성, 퍼포먼스, 스타일 격리 문제로 부적절함
  • 결국 HTML 자체에는 단순한 인클루드 문법이 없음

왜 HTML에는 이 기능이 없는가?

  • CSS와 JS는 각자 @import나 import 문법이 존재하지만 HTML은 그렇지 않음
  • 웹 표준은 일반적으로 개발자들이 많이 사용하는 기능을 수용해왔는데, HTML 인클루드는 그렇지 못했음
  • 의문으로 제기된 이유들:
    • 프리로드 스캐너의 작동 방해 가능성
    • 비동기 로딩 시 레이아웃 이동/깜빡임 문제
    • 중첩 또는 순환 인클루드 처리 복잡성
    • 웹호스팅 트래픽 증가에 대한 반발
    • 보안 이슈(CORS, CSP 등) 와 문서 로딩 이벤트의 타이밍 충돌
    • 또는 단순히 우선순위가 낮고 명확한 제안이 없었기 때문일 수도 있음

관련 논의

  • GitHub의 WHATWG 이슈 스레드 #2791에서 활발히 논의 중
  • 과거 크롬에서는 HTML Imports가 한때 존재했으나, 다른 브라우저들의 미지원과 함께 폐기됨
  • HTMX, Web Components, XSLT, SSI 등 대안적 접근법이 공유되고 있음

커뮤니티 반응 요약

  • HTML의 발전이 정적 마크업 중심으로 유지되면서 로직적 기능을 배제한 철학이 여전히 강함
  • 많은 사람들이 이 기능을 원하지만 표준화 과정에 목소리를 내기 어려운 개인 개발자가 대부분임
  • 퍼포먼스, 보안, 렌더링 처리, 순환 방지 등 복잡한 설계 문제를 해결하지 않으면 도입이 어렵다는 분석도 있음
  • 어떤 개발자는 단순히 HTML이 “결과”만 담당해야 한다는 개념 때문에 포함 기능이 빠졌다고 봄

결론

  • HTML에는 아직까지도 순수한 include 기능이 존재하지 않으며, 다양한 외부 툴과 언어로 이를 대체해야 함
  • 하지만 많은 개발자들은 여전히 간단한 HTML 기반의 재사용 구조를 기대하고 있음
▲
GN⁺ 9일전  [-]
Hacker News 의견
  • HTML은 역사적으로 SGML의 응용으로, SGML은 포함 기능을 지원했음. 새로운 "엔티티"를 정의하고 "시스템" 엔티티를 생성하면 나중에 참조하여 대체할 수 있었음
    • SGML의 복잡성 때문에 HTML을 단순화하려는 다양한 노력이 있었고, 그 과정에서 이러한 기능이 제거되었음
  • 90년대 후반에 이 문제를 해결하려고 노력했음. Analog Science Fiction 웹사이트의 웹마스터로서 동일한 헤더와 사이드바를 가진 많은 정적 페이지를 만들고 있었음. 그래서 Apache 서버 사이드 포함 기능을 발견했음. 이는 DRY 원칙을 알기 전에 이를 유지하는 방법이었음
    • 이 문제는 여러 방식으로 반복해서 해결되고 있음. iframe이 충분하다고 말하는 사람들에게는 iframe이 콘텐츠에 맞게 확장되지 않음. 서버 사이드 솔루션은 서버가 필요함. 왜 간단한 클라이언트 사이드 방법이 없을까? 이는 유효한 질문이라고 생각함
  • HTML Imports라는 기능 제안이 있었음. 이는 Web Components의 일환으로 만들어졌음
    • HTML Imports는 다른 HTML 문서에 HTML 문서를 포함하고 재사용하는 방법임
    • Google이 Blink에서 제안된 사양을 구현했지만, 다른 회사들은 다양한 이유로 반대했음. Mozilla는 구현의 복잡성과 보안 문제, ES6 모듈과의 중복성에 대해 우려했음. 공급업체의 지원이 없어서 제안은 공식적으로 중단되었음
  • Netscape 4는 inflow layers라는 기능을 가지고 있었음
    • 이 기능의 이름은 transclusion임. Project Xanadu의 일부였으며, 원래 하이퍼텍스트의 중요한 기능으로 간주되었음
    • 미디어위키는 transclusion을 광범위하게 사용하고 있음. 때로는 위키가 하이퍼텍스트의 진정한 형태처럼 느껴짐
  • 적절한 프레임셋(iframe이 아님)이 오래전에 이러한 기능을 수행하도록 되어 있었음. 최소한 자동 확장은 잘 되었고 사용자가 크기를 조정할 수 있었음
    • 프레임에 대한 많은 비판이 있었지만, Java API 문서와 같은 유용한 것들에 성공적으로 배포되었음
    • 프레임셋이 디자이너에게 충분한 유연성을 제공하지 못했기 때문에 유지되지 않았다고 생각함. 오늘날 모바일에서는 프레임셋이 잘 작동하지 않을 것임
  • "Includes" 기능은 서버 사이드로 간주되며, 웹 브라우저 외부에서 처리됨. HTML은 클라이언트 사이드이며, 단순한 마크업 구문일 뿐 프로그래밍 언어가 아님
    • 이 문제는 해결된 문제임. "Includes" 문제는 모든 웹 디자인 학생들이 PHP를 배우는 방법임. 대부분의 CMS에서 "Includes"는 "템플릿 부분"이 되며, 문서에서 처음 설명되는 것 중 하나임
    • HTML만으로 "Includes"를 사용할 필요는 없음. HTML은 프레젠테이션 형식이며 CSS와 JS 없이는 흥미로운 일을 하지 않음
  • HTML 포함 기능에는 여러 가지 문제가 있음
    • main.html이 child/include1.html을 포함하고, child/include1.html이 링크 src="include2.html"을 가지고 있다면 사용자가 링크를 클릭할 때 어디로 가야 하는가? "include2.html"로 가면 그 페이지는 다른 모든 것이 빠져 있을 것임. main.html로 가면 이번에는 include2.html을 사용하고 include1.html을 사용하지 않는다고 어떻게 지정할 것인가?
    • 반대로 article1.html, article2.html, article3.html 등이 각각 header.html, footer.html, navi.html을 포함할 수 있음. 하지만 모든 기사에 comments.html을 추가하려면 모든 기사를 편집해야 하며, 결국 템플릿을 기반으로 기사를 생성하고 브라우저가 포함을 지원할 필요가 없게 됨
    • 헤더가 제목을 알고 싶어 하거나 푸터가 다음/이전 링크를 원할 경우 포함 간에 이 정보를 전달할 방법이 필요하며, 결국 페이지를 생성하고 포함이 해결책이 아님
    • HTML 포함은 대부분의 사용 사례에 대해 실질적으로 쓸모없을 것임
  • WHATWG에 이 문제에 대한 공개 이슈가 있음
    • HTML의 클라이언트 사이드 포함 기능
  • HTML은 포함 기능을 가지고 있었지만 인기를 잃었음
    • 실제 "include"라는 용어는 XML 기능이며, 기사가 원하는 기능임. HTML은 XML 이전에 존재했던 대체 접근 방식을 가지고 있었음. 그 접근 방식은 프레임이었음. 프레임은 XML 포함보다 더 많은 기능을 제공했으며, 그래서 HTML은 그 기능을 얻지 못했음. 프레임은 오용, 보안, 접근성 및 다양한 다른 문제로 인해 인기를 잃었음
답변달기