Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
XHTMLが残したもの
Search
Yosuke Furukawa
PRO
September 04, 2026
Programming
990
2
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
AIがコードを書いてくれる時代、我々は何を確かめるのか
yosuke_furukawa
PRO
13
5.4k
AI時代のシニアエンジニアとは
yosuke_furukawa
PRO
14
11k
Webの地図
yosuke_furukawa
PRO
6
5.3k
jsmini JavaScript Engine を作ってみた話
yosuke_furukawa
PRO
0
460
デザインシステムが必須の時代に
yosuke_furukawa
PRO
2
350
Node.js, Deno, Bun 最新動向とその所感について
yosuke_furukawa
PRO
10
5.4k
Welcome JSConf.jp 2024
yosuke_furukawa
PRO
1
4.9k
tc39 x jsconf.jp Panel Discussion 2024
yosuke_furukawa
PRO
0
390
Removing Corepack
yosuke_furukawa
PRO
9
2k
Other Decks in Programming
See All in Programming
AI時代のFlutter品質設計 — アプリ品質を守るQuality Layers
omatty198
0
330
Groovy as a human and AI friendly programming language
paulk
0
160
baseline으로 마이그레이션, 리팩토링 안전하게 맡기기
fornewid
1
800
SFCで実現する病院・医療システムの動的組み立て式UI
koukimiura
1
160
SODA - FACT BOOK(EN)
sodainc
1
200
コーディング自動化の次へ。人の介入をゼロにするファクトリーとサポートAIによる実践
timakin
5
5k
Materialが消えた日 〜真っ白なFlutterキャンバスにRenderObjectで絵を描く〜
umigishiaoi
0
130
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.7k
[DroidKnights 2026] Workflow AX: From Auto-Documented Policies to E2E Testing
raeminkang
0
240
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
3
2.3k
HTML-in-Canvasで作る未来のWeb UI表現
clockmaker
5
6.1k
プロジェクトコードをキレイキレイしよう!暗黙的な参照を読み解く静的解析
ostk0069
0
200
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
96
6.9k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
500
Game over? The fight for quality and originality in the time of robots
wayneb77
1
320
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.9k
The browser strikes back
jonoalderson
0
1.9k
Documentation Writing (for coders)
carmenintech
77
5.6k
Digital Projects Gone Horribly Wrong (And the UX Pros Who Still Save the Day) - Dean Schuster
uxyall
1
3.6k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.8k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
310
Designing for Timeless Needs
cassininazir
1
540
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.7k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
540
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の仕様における進化を止めない事の重要さ