原文： Interview with Ian Hickson, HTML editor
著者： HTML5Doctor
公開日： 2011年頃
アーカイブ日： 2026-02-06
Ian Hickson（通称Hixie）は、WHATWGのHTML Living Standardエディターであり、おそらく現代のWebに最も影響を与えた人物の一人。Google所属（元Opera、Netscape）。このインタビューでは、Web技術スタックの混沌、仕様策定の哲学、最大の成果と失敗について率直に語る。
Q: Webから消し去りたい技術は？
HTML、JavaScript、DOM、SVG、XML、JSON、CSS — 基本的に全部！Webの技術スタックは完全に混沌としている。問題は：何で置き換えるのか？
なぜ混沌か？
最も恐ろしい部分は、最も成功した部分でもある。なぜなら、最も成功した部分が最も多くの人によって拡張され、長期的な調整が最も少なくなるから。
Q: なぜあなたはいつも「No」と言うのか？（<picture>、<main>など）
答え：それが私の仕事だから。
すべての機能にはコストがある：
機能リクエストは洪水のように来る。優先順位付けの基準：
<main>の例： 「追加する価値がコストに見合わないと判断した」
問題を定義 → 解決策を比較評価 → 最良の解決策を選ぶ
<picture>の例： <video>+<source>で学んだ教訓（複数要素はデザインの落とし穴）を活かし、代わりにsrcset=""を提案（CSSのimage-set()ベース）
「No」と言うのは難しい。議論を招くから。ほとんどのブラウザベンダーにはそんな時間はない。私にはある。それが私の仕事であり、長年上手くなった。
重要： Hixieは実際には「Yes」も「No」も言えない。ブラウザを書いていないから。ブラウザベンダーが実装しなければ、仕様は無意味。逆に、Hixieが「No」と言っても、ブラウザベンダーが実装すれば、最終的に仕様に反映される（例：<menuitem>）。
Q: 何を最も誇りに思う？
HTMLパーサー仕様。以前は「絶対にやらない」と言っていたほど困難だった。
何がすごいか？
pushState() — お気に入りの失敗postMessage() — セキュリティモデルの失敗設計したい用途には完璧に動くが、ほとんどの人は違うことをしたがるので、ひどく感じる。まだこの混乱を修正しようとしている。
postMessage()で学んだ教訓を壊した）仕様のルールは不変だと思っていた。実際には、単に制約を破ってもっとシンプルなものにすべきだった。
その結果の一つが「Quirks Mode」とDOCTYPE切り替え。仕様をブラウザに合わせて、こんなモードは作らなければよかった。
仕様が要求していたが、後から見れば無視すべきだったものをテストしてしまった。結果、ブラウザが実装すべきでないものを実装してしまった。
- Acid3: SVGフォント関連（不要だった）
- Acid2: SGMLコメント関連（後に完全に廃止）
全問題を一度に解決しようとした。段階的にすべきだった。結果、ブラウザベンダーは実装しなかった。
（IRCで失敗を列挙した後、Anneが「長いリストだね。なぜ俺たちこいつを信頼してるんだっけ？」と言った。笑）
Q: 仕様エディターにHTML作者（ベンダーではなく）からのフィードバックは十分届いている？
「十分」かどうかわからない。十分なフィードバックなんてあるのか？
問題： ほとんどの作者は、自分が何を望んでいるか知らない
Googleがマイクロデータのユーザビリティテストに資金提供した。「どちらがシンプル？」と聞いた印象と、実際のパフォーマンスには全く関係がなかった。
フィードバックの多くは「機能Xが欲しい」形式。掘り下げて「解決したい問題は？」「ユースケースは？」と聞くと：
多くの場合、もっとシンプルな解決策（または既存の解決策）が見つかる。
Q: Googleはあなたの仕様決定に影響を与えるか？ビジネス目的に沿わせるよう要求されるか？
いいえ、むしろ逆。入社時に非常に明確な指示を受けた：「Webの長期的利益をGoogleの短期的利益より優先せよ」と。
もちろん、Googleで働くことで得られる独自の視点やデータへのアクセスが、私の判断に影響を与えているのは間違いない。
Q: Webプラットフォームは複雑すぎるか？（Web Components、Shadow DOMなど）
複雑すぎる「何に対して」？
答え： プラットフォームが一人で完全に理解できるほど複雑なのは、すでに昔の話。
これは問題ではない。 Windowsプラットフォーム（NTカーネルAPIからDirect3Dまで）を誰も完全に理解していないのと同じ。
Q: W3Cが正気に戻った今、WHATWGは解散すべきか？
試した（2007-2012）。うまくいかなかった。実際、W3Cから更に仕様をスピンアウトした。WHATWGは現在約12の仕様を8人のエディターで管理している。
なぜうまくいかなかったのか？
優先順位、ビジョン、アプローチが異なる。客観的な答えを出すのに私は適切な人間ではないが。
Q: モバイルデバイスでネイティブアプリがWebに勝つか？
Webの特性：
コスト： 複数ベンダーの議論では基本的にイノベーションは起きない。プロプライエタリプラットフォームなら簡単に機能追加できる（議論不要）。Webでは、すべての主要実装者が同意して初めて機能追加される（通常、ネイティブプラットフォームで証明された後）。
結論： ネイティブプラットフォームが急速にイノベーションしている間は、Webは遅れる。
だから今日のモバイルはネイティブアプリに注目が集まる。新世代は急進的な新機能を持ち、Webは常にそれに遅れる。だから最先端はネイティブ。
デスクトップでは、OSのイノベーションが劇的に減速 → Webが成熟 → Webアプリが大成功（ブラウザだけ起動するデスクトopOSが成立するほど）。
モバイルは、イノベーションの観点ではデスクトップの10-20年前の状態。
Q: 自由でオープンなWebへの最大の危険は？
パテント。
このインタビューが示すもの：
Ian Hicksonのような人物がいて、失敗を認め、長期的視点でWebを守り続けているからこそ、今日のWebがある。