HTML単体ではなぜインクルードできない？ かつて存在した機能の知られざる歴史
引用元：https://news.ycombinator.com/item?id=43878728
HTMLは昔、SGMLっていう規格の一部だったんだよ。SGMLにはインクルード機能があったんだ。新しい”entity”を定義して、”system” entityを作れば、後でそれを参照して置き換えられたんだね。＜!DOCTYPE html example [
＜!ENTITY myheader SYSTEM ”myheader.html”＞
]＞
….
&myheader;
SGMLは複雑だから、HTMLを単純にするためにいろんな努力がされた結果、この機能は途中で削られちゃったんだ。
XHTMLで少しだけXML寄りになったこともあったね。XMLにはXIncludeっていう機能もあるけど、必須じゃなかったんだ。
20年前にXHTMLやsemantic webに進まなかったのは残念だね。XHTMLの失敗は厳しすぎる構文と壊れたWebのせい、ベンダー全体の責任だよ。Googleは後年、ビジネスメリットのあるJSON+LDでsemantic webを実現した。これはschema.orgの標準。結局semantic webは別の形で手に入ったんだ！
面白い情報だね、調べてみるよ。
＜object＞タグって、他のHTMLページをインクルード/埋め込めるみたいだね。
埋め込みの例だよ：＜object data=”snippet.html” width=”500” height=”200”＞＜/object＞
https://www.w3schools.com/tags/tag_object.asp
＜object＞をこう使うのは、標準の中ではもっと不安定な、互換性維持のための劣化版iframeだよ。iframeみたいに、全体をブロック要素として”include”するけど、これは元の記事の人が示唆してるのとはちょっと違うね。
個人的には、厳格なsemantic webにはそんなに興味なかったんだけど、XMLには周りのエコシステム（XPathとかXSLTとか）の利点があったり、namespaceの形で拡張性が組み合わせられたりするんだよね。それが全部HTML5で捨てられたのはすごく不満だったし、その理由（XHTML前のページとの互換性は、XHTMLに変換する仕様を定義するのが一番良いって考え）も全然理解できなかったな。
Google批判は同意だけど、失われたsemantic webへの見方には驚くね。XHTMLの失敗は厳しすぎる構文と壊れたWebのせい、ベンダー全体の責任だよ。Googleは後年、ビジネスメリットのあるJSON+LDでsemantic webを実現した。これはschema.orgの標準。結局semantic webは別の形で手に入ったんだ！
それって、90年代後半から2000年代初頭に固定要素のためにたくさんのサイトがやってたことだよ。
あれは本当にひどかった。ブラウザのナビゲーションが見えなくなるし、ちょっとしたエラーでコンテンツじゃなくて固定フレームの方に飛んで全体が台無しになるし、デザインの柔軟性はなくなるし（一貫したスタイルには余計な手間がかかるのに）、フレームはコンテンツに合わせてサイズが変わらないからクリップされたりスクロールバーだらけになったりするし、デバッグは最悪だし…。
それにリソースも余計に食うんだよ。
理想的じゃないけど、objectタグを使えばピュアなHTMLでもできるよ…筆者は触れてないみたいだけどね。
ちょっとしたバニラのJavaScriptとWebComponentsを使えば数行だよ：
https://gomakethings.com/html-includes-with-web-components/
昔PHP sessionsをXHTMLドキュメントで使ったらパースエラーになったの覚えてるよ。PHPがセッションをリンクのクエリ文字列に足すとき、パラメータ区切りにrawな&文字を&じゃなくて使ってたからXMLパースエラーを引き起こしてたんだよね。
ずさんなHTMLが生む問題（ブラウザ間のレンダリング不一致）を避けるために、ブラウザがシンタックスに緩すぎるのを防ごうって動きもあったんだ。
semantic webなんて90年代とか00年代のばかげた夢だよ。実現可能な技術じゃないし、Googleがまさにその理由を示したろ？
Web上でページを見つけるアルゴリズムが固定されたら、みんな自分のコンテンツを優先させるためにアルゴリズムを悪用し始めるんだ。金をかけてやり方を調べて実行する全てのパブリッシャーのことだよ。
だから、どんな純粋にアルゴリズムに基づいた検索もすぐにほぼゴミしか返さなくなる。実際の検索エンジンが機能するのは、悪用する人たちに対応してアルゴリズムを常に人間が変更してるから。これはsemantic webの考え方にある程度反するし、大衆向けのローカルファーストなWeb検索エンジンなんて考え方には完全に反するね。
XHTML 1.0がそうだったんだよ、それから互換性なく進化しちゃったけど。
semantic webが大衆向けに機能する持続可能な道筋なんて、今までなかったと思うね。
みんな書きたい、公開したいって思ってたんだ。ページに事実情報をタグ付けするリソースや意欲があったのは、ほんの一握りの人や機関だけだったろうね。ほとんどの人はsemanticな分類を無視しただろうし。
小さくて閉鎖的なsemantic webは無いよりマシだと思うけど、実際にWebがこれほど豊かになったシナリオで、かつ厳格に組織化されてたなんて状況は疑わしいな。
それはHTML 4以下で使われてたDTD (Document Type Definition)とかXMLにもあったね。SGMLからも来たんだろうな。
まあ、それはそれ自体がまるごと攻撃対象になりうるね。
https://en.wikipedia.org/wiki/Billion_laughs_attack
うん、それはHTML Frames [1]のただの劣化したバージョンだよ。
1 - https://en.m.wikipedia.org/wiki/Frame_(World_Wide_Web)
＞ピュアなhtmlに存在する［…］JavaScript with WebComponents
君の言う”ピュアなHTML”の定義、かなり独創的みたいだね。
まあ、なんとなく同意するけど、microformatsの”死”はXHTMLの死とは関係ないって言いたいな（schema.orgはまだあるけどね）。例えばhReviewとか今でも使えるけど、誰も使ってないじゃん。結局microformatsの問題は、“自分のコンテンツを自分のWebプロパティの外でも使ってほしい”なんて誰も望んでないってことだよ。検索エンジンがトラフィックを流してくれる以外はね。Fediverseだけがそのコンセプトを復活させる唯一のチャンスかもね。だって、あそこは基本的にアトリビューションがちゃんと残るから。
XHTMLは単にHTMLのより厳格な構文だっただけだよ。それでセマンティックになったわけじゃない。
歴史は全然そんな感じじゃなかったよ。俺が90年代後半（つまりGoogleが支配的になる前）にインターネット会社で働いてた頃は、SGMLなんて一部の人が興味あるだけだった。SGMLベースのイントラネットをクライアントに売り込もうとしたけど、柔軟性とか訴えても全然興味持たれなかったし、当時のWebは雑なマークアップとか間違ったHTMLが普通だったんだ（Chromeとか出る前ね）。
2番目の点は部分的しか正しくないな。Googleは複数のセマンティックWeb標準をサポートしてるよ。RDFa、JSON+LD、それにmicrodataもだと思う。JSON+LDは抽出やパースがずっと簡単だけど、値が埋め込めるRDFaと比べて情報が重複するからサイトのHTMLは大きくなるね。
“semantic web”はいくつかの分野では成功したけど、SQLとかドキュメントデータベースほどじゃないな。RSSフィードとかAdobeツールが使うXMPメタデータみたいに、多くのデータ形式で使われてるよ。
それに、たとえセマンティックタグ付けをうまくやっても、分類法を巡る認識論的な問題がめちゃくちゃ大きいんだよ—誰が作るの？ 用語って実際どういう意味？ どう整理するの？ とかね。俺がwikidataの分類法を使おうとした経験だと、クラウドソースだと完全にカオスになるし、“専門家”が作った分類法だと網羅性とか意味とか民主性とかでいろんな問題がある。2007年頃からsemantic webをちょっとかじってみたけど、残念ながらAIが唯一実行可能なアプローチだって個人的な結論に至ったよ。
俺はブラウザチームで働いてたけど、厳格なパーサーが欲しかったんだ。XHTML推進派だった。でも“競合がパースできるのに俺たちができなきゃ、ユーザーは離れる”って意見に納得させられた。市場が求めるものか、死ぬかの選択だったんだ。厳格さでユーザーを失うのを見た結果、“手抜き”せざるを得なかった。Webは最初から構文に緩いことにコミットしてたし、それがWebが勝った一因だ。ユーザーはエラー吐くブラウザなんていらない。XHTMLはWebの本来の姿やユーザーの要望と離れてただろうね。
俺は“semantic XML processing”に関わってたけど、“semantic”部分は不明確だった。今のLLMの誇大広告と似てるね。デモや実用アプリはできるけど、“semantics”がXMLから生まれるわけじゃないし、LLMは“意識”じゃない。XHTMLがHTML5よりセマンティックだったかは疑わしい。それに、Google以前の検索は構造化しすぎてて使いにくかった。Googleはユーザーが簡単な単語で検索できることを示し、作成時じゃなく検索時に関連性を見つける方が効果的だと証明した。ドキュメントの厳格さも、alt属性とか付けさせるだけじゃ無意味な値が増えるだけかも。ブラウザは雑なソースでもうまく再構築できるようになったし。semantic webが失敗したのは、アイデアが魅力的じゃなかったからだと思う。25年経っても“semantic”の意味すら分かってないのが正直なところだ。
SGMLのXMLサブセットにはエンティティ使用法が残ってるよ。外的な一般エンティティもね。XIncludeは断片も読み込めるけど重複してた。HTMLに残ってるXIncludeは断片を使わず名前空間もナシ。SVGには＜use href=…＞構文があるよ。XIncludeはXML Schemaがあるとマジでうまく動かなかったんだ。
90年代に同じヘッダーとサイドバーでうんざりして、SSIを知ってウキウキした経験があるよ。何度もこの問題を解決してきたね。iframeはダメだし、サーバーサイドはサーバーが要る。単純なクライアントサイド方法がないのは妥当な疑問だよ。今こそ検討する価値あるんじゃない？
HTMLってマークアップ言語であって、プログラミング言語じゃないからね。Markdownになんでインクルード機能がないの？って聞くみたいなもんかな。一部のMarkdownエディターは対応してるけど（HTMLのサーバーサイドツールみたいに）、全部じゃないんだよね。
それがHTMLのHyperな部分で、特別なところなんだよ。PDFみたいな他のドキュメント形式と違って、外部リソースを取り込むように作られてるんだ。スクリプト、スタイルシート、画像、オブジェクト、ファビコンとかね。HTMLってテーマ的に似たようなもんだよ。
俺はこの理由でhttps://htmx.orgのファンになったわ。10KBくらいの小さいライブラリなんだけど、静的なHTMLの動的なインポートみたいな必須の良いものをHTMLに加えてくれるんだ。
もっとコメントを表示（1）
いや、HTMLは根本的に違うよ。（JSでのDOM操作がない静的サイトなら）HTMLは全ての意味論的なコンテンツを持ってるけど、スタイルシート、画像、オブジェクトなんかは見た目のためのものだからね。
最適な解決策は、テンプレートエンジンを使って静的ドキュメントを生成することだと思うな。
これが一番ありそうな答えだね。俺も共通ヘッダーで最初に困った。HTMLの元のコンセプトはスタンドアロン文書で、再利用部品があるサイトじゃなかったんだ。でもフレームセットがなぜ発明されてインクルードじゃなかったのかは理解できないな。帯域幅節約のためとか？
画像はコンテンツだよ。動画もコンテンツ。オブジェクトやiframeもコンテンツ。見た目のためのものはスタイルシートだけだよ。
テンプレートエンジンで静的ドキュメント作るのが最適解って言うけどさ、それって作る側にはいいけど、使う側にはどうなの？ あんたのテンプレートエンジンで作った静的ドキュメント100個見たら、全部同じ内容を100回ダウンロードすんじゃん。
静的なhtmlをちょっとインライン化するだけなのに、framework持ち込むのはやりすぎだと思うな。
それだけなら、scriptタグ自身を置き換えるスクリプトがスマートだよ：
＜script＞
function includeHTML(url) {
const s = document.currentScript
fetch(url).then(r =＞ r.text()).then(h =＞ {
s.insertAdjacentHTML(’beforebegin’, h)
s.remove()
})
}
＜/script＞
…
＜script＞
includeHTML(’/footer.html’)
＜/script＞
このscript要素が/footer.htmlの中身に置き換わるんだ。
ページサイズは親にメッセージできるよ。ドメイン跨ぐ場合は、#location hashに高さを入れて親で同じURLを読み込めば、更新されないで済む。
回避策があるのは分かってるけど、そこがポイントじゃないんだよな。これ、超よくあるケースだから、簡単にできるようにすべき。これ、もはや「牛のスーパーハイウェイ」レベルじゃん。この問題解決するために業界丸ごと作っちゃったんだぜ。もし、簡単なWeb公開なら、複雑なweb frameworkじゃなくて新しいタグ一つで済むとしたらどうよ？
インラインのJavaScriptは、実行されるまでレンダラーを止めちゃうよ。出力結果が確定しないと先に進めないからね。
XHRが発明・普及する前、フレームは動的なインターフェース作るのにかなり悪用されてたんだ。アプリはいくつかのサブフレームに分かれてて、リンクやフォームは全部違うフレームを指してた。サイドバーのリンクで「エディター」フレームにページを開いて、そこでフォーム送信とか。同じフレームで再読み込み。保存ボタンとか、完了して次へ進むボタンとか複数あったり。今のアプリの状態はサーバー側で管理されてて、簡単なクライアント側JSでフォーマットチェックくらい。この設定で、フレーム対応してる一番古いブラウザでもCRUD web apps使えたんだ。WebObjectsみたいな初期のweb frameworkもこのモデルに乗っかってたと思うよ。
1996年のNetscapeならこれできたんだ（今でも使ってるサイトのサーバーやってる）。
＜！DOCTYPE HTML PUBLIC ”-//W3C//DTD HTML 4.01 Frameset//EN” ”http://www.w3.org/TR/html4/frameset.dtd”＞
＜html＞＜frameset cols=”1000, *”＞＜frame src=”FRAMESET_navigation.html” name=”navigation”＞＜frame src=”FRAMESET_home.html” name=”in”＞＜/frameset＞＜/html＞
フレームでいつもムカついたのが、賢すぎること。右クリックで再読み込みしても、フレーム一個しか更新されないとか嫌なんだよ。フレームとキャッシュは違う問題なのに混ぜてどっちもイマイチに。俺的にHTMLのインクルードは一番馬鹿な方法であるべき。インクルードの中身を単純に貼り付けるだけ。キャッシュしたいなら別属性でやるべき。インクルードはシンプルが一番いい。
でもこれJavaScript要るじゃん…
あー、マジだ、完全に忘れてたわ、あれ。あれは酷かったよー。バックボタン押すとフレーム一個だけ戻っちゃって、アプリの状態がおかしくなったり… マジでメチャクチャだった！
細かいことだけどさ、HTML4の仕様が出たのは1997年12月で、HTML4.01は1999年12月なんだ。だから1996年のNetscapeじゃ多分動かなかったんじゃないかな。
＞画像や動画はセマンティックなコンテンツじゃないって言うけど、その考え方、なんか納得できないな。
Webってさ、意図的にどんな形の構成可能性も不可能にするように設計されてるみたいだよね。プラットフォームとしては最悪な点の一つだよ。きっと、どこかの純粋主義的な議論がこうさせたんだろうな。
今ってService Workers APIでこれができるようになってるんじゃないの？本質的にはブラウザ内のプロキシとしてサーバーにアクセスする感じでしょ。
https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor…
昔のSAP WebアプリでフレームとHTMLフォームだけのやつに苦労した思い出。リセットボタンばっか押して「戻る」は厳禁だった。あれはひどい。今のJavaScriptもあれだけど、XHRとかダイナミックHTMLは昔のフレーム乱用よりはマシになったよね。
まあ（知ってると思うけど）、文字通り’content’を持ってるよね
https://developer.mozilla.org/en-US/docs/Web/CSS/content
同じコンテンツを何度もDLすることになっても、消費者側には大した問題じゃないでしょ。共通コンテンツってヘッダーとかフッターとかサイドバーで、本文に比べたら小さいし。重さの主原因は画像とかスクリプト、CSSで、それらは重複させないんだから。共通テキストが大きいならiframeかJSで対処すればいい。実際、重複HTMLでサイトが激重になった例あったら教えてほしいな。
＞ Iframesがコンテンツに合わせて広がらないって言うけど、実はそれ、元の計画の一部だったんだよ。
https://caniuse.com/iframe-seamless
htmx.org の縮小版は51KBくらい（圧縮すると16KB）だよ。curlでサイズ測った結果がこれ。
＄ curl －－location －－silent ”https://unpkg.com/htmx.org@2.0.4” ｜ wc －c
50917
＄ curl －－location －－silent ”https://unpkg.com/htmx.org@2.0.4” ｜ gzip －－best －－stdout ｜ wc －c
16314
https://www.w3.org/TR/xhtml2/introduction.html＞ XHTML 2 は全然違うアプローチなんだ。すべての画像に長い説明がある前提で、画像とテキストを同等に扱ってる。XHTML 2 ではどんな要素でも ＠src 属性を持てて、そこにリソース（画像とか）を指定するとその要素の代わりに読み込まれるんだって。
この機能提案は HTML Imports って呼ばれてたんだ［1］。Web Components の取り組みの一部として作られたんだよ。HTML Imports は他のHTML文書にHTML文書を含めて再利用する方法なんだ。template タグのサポートとかも計画されてたみたい。
たしか、Google は提案された仕様をBlinkに実装したんだけど、他のベンダーはいろんな理由で尻込みしたんだ。Mozilla は実装の複雑さとかセキュリティの懸念、あとES6 modulesとの重複を心配してたらしい。ベンダーの支持が得られなくて、公式に廃止されちゃったんだって。
［1］ https://www.w3.org/TR/html-imports/
廃止理由の需要不足やベンダー消極的っていうのは納得いかないな。20年も待望されてるのに需要がないわけないし、ベンダーが実装までしたのに拒否した本当の理由を知りたいよ。JSでHTMLをクロスオリジンでインポートできるのに、HTMLタグだとセキュリティ問題になるっていうのも変じゃない？CORSで解決できる気がするけど。
［1］ https://frontendmasters.com/blog/seeking-an-answer-why-cant－…
複雑なのは、HTMLの読み込み順序っていう基本的な前提を壊すのが難しいからだよ。JSなら許されるけど、HTMLタグだとバグだらけになる。プリロードとか複雑なこと考える必要もあるし、iframeもあるしね。簡単なユースケースは数行でできるけど、それ以外の難しいケースを扱うのがめちゃくちゃ大変なんだよ。
この需要の低さに付け加えるかもしれないこととして：
1. ユーザーがJSを使う前提で開発されてるWebページなら、同じ結果を得る方法を簡単に実装できるんだ。
2. JSが動かないユーザーエージェント向けに開発されてるWebページは、おそらく何かしらインタラクションが欲しいから、すでにサーバーランタイムがあってこの機能を提供できるんだ。
2b. そして、もしユーザーインタラクションが全くないなら、それは多分静的なコンテンツサイトで、誰もHTMLでコンテンツを書いてないから、すでにこの機能を提供してるビルドステップがあるんだよ。
HTML Imports はbodyの中にマークアップを含められなかったんだよ。カスタム要素のための template 要素を参照するのにしか使えなかったんだ。
JSファーストな開発者は、クライアント側でもサーバー側でも同じように動くものを求めてるんだよね。それで主流のフロントエンド開発コミュニティは、良いか悪いかは別としてJSファーストにシフトしたんだ。
HTML Imports は似た方向性だったけど、ブログ記事が扱ってることとは違うんだ。HTMLは文書の特定の場所にインポートされて表示されるべきだよね。HTML Imports はJavaScriptなしではこれができなかったんだ。
詳細は https://github.com/whatwg/html/issues/2791#issuecomment－3112… を見てね。
もっとコメントを表示（2）
公平に言うと、それはかなり複雑だったよ。たしか、使うにはインポート後にJavaScriptを使って template をインスタンス化する必要があったんだ。include src=”myinclude.html” みたいなシンプルな感じじゃなかったんだよね。
caniuse.comによると、FFでさえconfig flagとしてこれを持ってたんだって。
正直、HTML Importsはこの記事が求めてるincludesよりずっと複雑だったんだよね。
Framesも基本的にHTMLインポートみたいなことできたんだよ。
Netscape 4にはinflow layersっていう機能があってね、＜ILAYER SRC=included.html＞＜/ILAYER＞って書けたんだ。web.archive.orgのリンクもあるよ。
俺が知ってる限りではね、SRC属性を変えるのは結構クラッシュしやすくて、その機能はすぐに無くなっちゃったんだ。(ベータ版でこれで遊んでたのを覚えてるんだけど、製品版では無くなってたんだよ。)
ずっとILAYERって何で呼ばれてるんだろうって思ってたんだよね。教えてくれてありがとう。
この機能の名前はtransclusionだよ。Wikipediaのリンク。Project Xanaduの一部で、元々ハイパーテキストの重要な機能と考えられてたんだ。特にmediawikiはtransclusionをすごく活用してるよ。wikiがハイパーテキストの最も真の形だと感じることがあるね。
Ward Cunningham（Wikiの発明者）はtransclusionを第一にしたwikiを考案しようとしてた時期があってね、みんなが自分のwikiスペースを持ってtransclusionを社会的に使うみたいな。Federated Wikiのリンクもあるよ。でも、あまり普及しなかったんだ。
俺はね、本当のtransclusionはもっとすごいと思うんだ。Xanaduでは、ある文書から抜粋した部分だけを別の文書に取り込めた。HTMLでこれをやろうとすると、CSSの解決が必要になる。一般的な場合は不明瞭だ。シンプルな＜include …＞タグだと、ゲスト文書はホストのCSS環境内で機能するように設計される。もう1つのシンプルな答えはShadow DOMで、ほとんどの場合、ゲストが文書の他の部分に影響を与えずにスタイルを付けられる。この場合でもホストはゲストを修正するために一部のスタイルを入れられると思う。
これって、ずっと昔（HTML 4？）のちゃんとしたframesets（iframesじゃない方）がやるべきだったことじゃないの？少なくとも、framesetsはちゃんと自動拡張して、サイズも調整できたんだ。framesへの批判は多かったけど、Java API documentationみたいな役立つことにも使われてたよ。俺の意見では、デザイナーにとって柔軟性がなさすぎたのが残らなかった理由だと思う。情報ページには十分だったろうけど、かさばるスクロールバーとかでデザイナーのニーズに応えられなかった。今、framesetsをそのまま復活させるのは遅すぎる。モバイルで動かないだろうから。
frame setの問題はディープリンクができなかったことだよ。ブックマークやGoogleから来た人がナビゲーションのないページに取り残されちゃって、みんなJavaScriptでなんとかしようとしたけど、結局いい体験にはならなかったんだよね。
最近は逆に、ページが全部JavaScriptで動いてて、そもそもいい体験にならないこともあるよね。ちゃんとした”リンク”を取得するのに苦労したことが何度もあるよ。それにブラウザがアドレスバーを隠したがるし、それが本当にまだそんなに重要な機能なのかな？って疑問に思うことも。もちろん”当時は”これが重要な機能で、フレームをなくす理由の一つだったのは確かだけどね。
”Includes”機能はサーバーサイド、つまりウェブブラウザの外側で処理されるものだと考えられてるよ。HTMLはクライアントサイドで、本当にただのマークアップ構文であってプログラミング言語じゃない。記事が言うように、この問題はもう解決済み。HTMLで”includes”といえば、PHPの入門書で誰もが学ぶことだし、ほとんどのCMSでは、”includes”は”template partials”になって、ドキュメントで最初に説明されることの一つだよ。本当にHTML単体でincludesを利用できるようにする必要なんてないんだ。HTMLはCSSとJSがなきゃ何も面白くないしね。
＞”Includes”機能はサーバーサイド、つまりウェブブラウザの外側で処理されるものだと考えられてるよ。っていうのは、クライアントサイドでincludesが起きちゃいけないって主張にはならないでしょ。実際、HTMLにはフレームやiframeっていう、これよりひどいバージョンがすでにあるしね。サーバーサイドincludesのクライアントサイド版は、みんながHTMLでやってることと自然にフィットすると思うな。
なんか変だなって思うのは、HTMLファイルってスクリプトとかフォント、画像、動画、スタイルとか、多分他にも色々含められるのに、HTML自身は含められないところかな。カスタム要素（＜include src=…/＞）を使えばコードで書けそうだし、似たようなGitHubリポジトリがあっても驚かないけどね。
これに似たものを比較的最近作ったよ。もちろん欠点はJavaScriptが必要なことだけどね。
https://github.com/benstigsen/include.js
既存のカスタムコンポーネントも改良したんだ。これだよ： https://amc.melanie-de-la-salette.fr/polyfill.js
その通り！これ多くの学生にとってPHPの入門だよね。でも、なんで ＜include src=header.html/＞ はダメなんだろう？
画像とか、ページのまだ表示されてない部分のコンテンツとか、すでに非同期で読み込まれるものもあるのにさ。
＞HTMLは本当にただのマークアップ構文であって、プログラミング言語じゃない。
これ炎上狙いじゃない？ :) 各ブラウザエンジンがそれぞれ解釈する、宣言型言語だよ。
HTMLのMLって何のことか分かる？ 多分それが議論の核心だよね。HTMLをその名前を超えて進化させるつもりなのかな？
もし「include」ってのがどうもマークアップっぽくないって問題なら、簡単な解決策があると思うんだ。他のタグにsrc属性を使うだけ。＜html src=”/some/page.html”＞とか、＜div src=”/some/div.html”＞とか、＜span src=”/some/span.html”＞とかね。
あるいは fragmentとか page とか、ドキュメントの部品みたいな名詞の新しいタグを作るか。きっと svg, img, script, video, iframe なんかよりマークアップらしくないなんてことはないはずだよ。
