Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
XHTMLが残したもの
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Yosuke Furukawa
PRO
September 04, 2026
Programming
160
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
XHTMLが残したもの
W3C LT 2026/09/04
Yosuke Furukawa
PRO
September 04, 2026
More Decks by Yosuke Furukawa
See All by Yosuke Furukawa
jsmini JavaScript Engine を作ってみた話
yosuke_furukawa
PRO
0
350
デザインシステムが必須の時代に
yosuke_furukawa
PRO
2
260
Node.js, Deno, Bun 最新動向とその所感について
yosuke_furukawa
PRO
10
5.3k
Welcome JSConf.jp 2024
yosuke_furukawa
PRO
1
4.8k
tc39 x jsconf.jp Panel Discussion 2024
yosuke_furukawa
PRO
0
360
Removing Corepack
yosuke_furukawa
PRO
9
2k
JavaScript Runtime とはなにか
yosuke_furukawa
PRO
15
3.2k
Strip Types と Storage
yosuke_furukawa
PRO
4
530
Module Harmony について
yosuke_furukawa
PRO
4
2k
Other Decks in Programming
See All in Programming
不幸な GC
chencmd
0
850
高専キャリア LT 発表内容
crysta1221
6
5.3k
Gmail/Google DriveをトリガーにAIエージェントを動かそう! / Run AI agents with Gmail/Google Drive as triggers!
har1101
3
460
My Marp Sample
sinoue0108
0
140
自分的「カンファレンスの楽しみ方」
syumai
0
160
in-process GraphQL のすすめ #ginzajs
izumin5210
4
1.5k
Oxlintはいいぞ(続)
yug1224
1
510
PHPプロジェクトの結合バランスを可視化する #php_night
kajitack
0
180
AIの中の人になってみる
htkym
0
150
関東Kaggler会_NVIDIA_Nemotron_コンペ_振り返り
rick_ds
0
770
[DroidKaigi 26] How We Moved from Android Studio to Slack
thisaay
0
140
信頼性の目標を誰も求めてない
shubox
0
460
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
6.3k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.6k
What does AI have to do with Human Rights?
axbom
PRO
1
2.3k
How to build a perfect <img>
jonoalderson
1
5.9k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
2.6k
Abbi's Birthday
coloredviolet
3
9.6k
30 Presentation Tips
portentint
PRO
1
380
The untapped power of vector embeddings
frankvandijk
2
1.9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Deep Space Network (abreviated)
tonyrice
0
280
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Typedesign – Prime Four
hannesfritz
42
3.2k
Transcript
XHTMLが残したもの W3C LT yosuke_furukawa / 2026/09/04
X: @yosuke_furukawa GitHub: yosuke-furukawa
XHTMLとは • HTML は 1991 年に Tim Berners-Lee がSGMLの応用として規定した •
SGML自体は許容度の広い文法だった • 文脈上分かるなら推論したうえで省略可能というもの • 当然HTMLもそれにならったことで規則はおおらかなものだった • 閉じタグ省略可能だったり、属性のショートハンドな書き方が認められるのもここから来る • HTMLのパーサーが複雑なのもここから来る 「title要素の時は〜〜」「head要素は書かなくても良 い」など • 結果としてレンダリングエンジンがHTMLを解析する際に例外ケースがいくつも生まれてしまった • レンダリングエンジンごとの差異も生まれてしまった
XHTMLとは • HTML 4.01 までの語彙に加えてSGMLベースからXMLベースに変更した仕様を 策定を開始 => XHTML(2000年) • 全タグを閉じる、属性は引用符で囲む、大文字と小文字は区別ありで、要素
と属性は小文字で書く、 <br /> や <hr /> のように空要素は `<要素名 />`で終 わる等 • おおらかだったために逆に複雑になってしまったHTML仕様を丸ごと厳格な仕 様にするという意欲的なプロジェクト
XHTMLとは • しかし、既存HTMLの置き換えには至らず、仕様上もHTML Living Standard と して一本化。計画としては頓挫した。10年以上も仕様化に時間がかかった。 HTMLとXHTMLの簡単年表 (powered by
AI)
なぜダメだったか? • 今やWeb仕様では鉄則になった「後方互換性の重要性」を無視してた • 全く意識してなかったわけではない、特に text/html と application/xhtml+xml などのMIME Type
による区分けとそれに伴うHTML/XHTMLのモード変更などの意識はされていた • 一定互換性を無視しても良いだろうという背景もあった • 当時のモバイル端末に複雑なパースルールは搭載できないのでは?と思われてたり、ガラケーで は実際に導入されてたり。 • これから増えるであろうウェブページは新規に作られるから新しいルールが適用されるだろうと 思われてたり。 • XMLブームに後押しされていた(全てのデータフォーマットがXMLになるべきだと思われてた)
なぜダメだったか? • しかし上手く行かなかった。厳格な仕様は間違えると表示不備になった。 • XHTMLで正しい文法を書くこと自体はコンテンツ作成者に支持はされていた。実際 大量に本などは出ていて、見られてはいたが。。。 • ブラウザ実装側が2つのモードを同時にメンテナンスするメンテナンスコストの増 大や後方互換性が崩れることを問題視 •
仕様化までにXHTML提案の2000年から2009年まで9年かかっていることもある。 • 主だったブラウザ実装側が互換性を維持するように決議を持ちかけ、理想的な整合 性のある世界よりも互換性維持の方が投票により選択されてしまった。
仕様を統合、HTML5へ • 許容度が広い仕様はHTML5でパースルールを全て定義し直した(SGMLベースではなく、HTML として仕様が完結するようになった) • 閉じタグ省略可能を明示 • 省略可能なタグも明示 • xx
タグの場合はこのアルゴリズム、 yy タグの場合はあのアルゴリズムなどタグごとにパース アルゴリズムを明示 • 細かい例外についても仕様で記述 • https://html.spec.whatwg.org/multipage/parsing.html • パースの仕様は複雑になったが、整理されたことで混乱は生みにくくなった
仕様を統合、HTML5へ • パースルールの明確化までの道のりはエグい、7年かかってる。仕様として全体 を定義し直すのにWHATWG発足から10年かかった • 仕様に未定義だったパースルールで曖昧だった所を主要エンジンをリバースエ ンジニアリングすることで仕様を再定義 • 実際のコンテンツの統計を取り、どう記述されているかを精査 •
未定義の仕様の中で様々なパターンを用意し、どう壊れるかを確認 • 一番マシな挙動にあわせて仕様を作り直すという力業 HTML5が残した巨大な資産といえる
XHTMLが残したものは何か 残したもの その1 • HTMLを記述する時の慣例 • 小文字で基本記述 • 閉じタグは省略しない •
属性値は二重引用符 `"` で囲む • などなど、必ずしも守らなくてもHTMLとしては正当だが、慣例的に統一さ れた
XHTMLが残したものは何か 残したもの その2 • HTML の中に別の文法を埋め込めるようになった • SVG / MathML
などの XMLフォーマットで記述されたコンテンツを導入し やすくなった(`.svg`で記述されたものはXMLパーサーで処理される) • HTMLにインラインでSVGを書いた時はHTMLパーサー側が頑張って解釈す る(誤りがあってもなんとかDOMにして、SVGエンジンで処理) • (一方でXSLTなどの負債も残ってしまった。XSLTはXMLベースのDocument 変換処理だが、セキュリティ上の問題もあり、削除を予定中)
XHTMLが残したものは何か 残したもの その3 • 後方互換性より何より、Web仕様の進化が止まってしまうことが最も問題 だった • XHTMLで最も問題だったのは停滞とその後のビッグバンだった • 世の中にある程度受け入れられたものは小さく進化し続けないと失敗する
XHTMLが残したものは何か 残したもの その3 • これ自体は HTML 仕様に限らない • CSS はモジュラーになり、細かくWGごとに仕様提案されるようになった。
• JavaScript は proposal ごとに細かく議論され、年ごとのスナップショットを 取ることになった。 • HTTP はセマンティクスと通信方式に分かれて HTTP/2, HTTP/3 と分離された 仕様になった。 • 進化を止めない仕様づくりこそが Web に必要だという教訓を教えてくれた
まとめ • HTML => XHTML への進化は頓挫した • しかし、新しい形で進化した。特にHTML5で曖昧だった仕様が修正されたのは 大きい •
他にもいくつか残してくれたものはある • HTMLの書き方の慣例 • HTML / XML 併用設計 • Webの仕様における進化を止めない事の重要さ