なぜHixieはいつも“ノー”と言い続けるのか？ HTML5仕様のキーパーソン、Hixieへのインタビュー（前編）

HTML5の登場は、Webのあり方を一変させようとしていると言っても過言ではないでしょう。その仕様策定はW3CとWHATWG（Web Hypertext Application Technology Working Group）が共同で行っています。

HTML5において、もっとも影響力のある人と言えばIan Hickson氏、通称Hixie（ヒクシー）がその筆頭にあがります。彼は昨年までW3CのHTMLワーキンググループでHTML5仕様のエディタをつとめ、WHATWGでは現在もエディタとして強力なリーダーシップを発揮しています。

そのHixieに、同じくHTML5界の著名人であるオペラのBruce Lawson氏がインタビューした記事「Interview with Ian Hickson, HTML editor」が、HTML5 Doctorに掲載されています。

HTML5の仕様策定をリードし続けているHixieが何を考えて仕様策定を進めているのか、その裏にある苦労とはどんなものかが、本人の答えを通して赤裸々に綴られている非常に興味深いインタビューです。この記事では著者のBruce Lawson氏に許可を得て、その日本語訳を掲載します。かなり長いインタビューですので、3本に分けて掲載予定です。本記事はその1本目です。

Interview with Ian Hickson, HTML editor

W3CのHTML5エディターであるRobin Berjonへの熱いインタビューに続いて、この週末にIan Hickson氏にインタビューした。彼はWHATWGにおけるHTMLの“生きる標準”であり、ほぼ間違いなく、今日のWebにおいてもっとも影響力のある個人だろう。

Hickson氏は“Hixie”として知られていて、Googleの社員であり、それ以前はOpera（僕の雇い主だ）とNetscapeにいた。

（いくつかの質問は、デベロッパーからTwitter経由でもらったものとして、そのことを示した）

──── もしも既存のWeb標準をどれでも消し去れるとしたら、どれを選びますか？(from @webr3)

HTML、JavaScript、DOM、なんであれ自分が開発してきたもの、SVG、XML、HTML、CSS…基本的には誰もが使っているものさ！ Webテクノロジーのスタックは完全に混乱している。問題は、それを何で置き換えるのか？ ということだ。

Webのテクノロジースタックは、唯一の（たぶん唯一？ ほかの例をなかなか思いつかない）完全にベンダーニュートラルで、しかも中央集権的な開発もされていないプラットフォームだ。誰もが新しい機能を開発できるし、マーケットがそれを受け入れるのなら、プラットフォームのデファクトになれる。XMLHttpRequestはその古典的な例だ。これはもともと特定のベンダが誰からも何の助言もなく製品に組み込んだものだが、いまやWebブラウザがこの機能をサポートしなければまったく競争力を失うことになる。

パブリックに開発され多くの人にレビューされた機能であっても、実際にはそのプロセスが終わる前に実装され使われ始めてしまう。そしていったん使われ始めると、それは変更できなくなってしまう。これが出来の悪いAPIにつながってしまうのだ。例えばpushState()みたいな。引数が要求されているのに無視されてしまう。

難しいのは、仕様の善し悪しは現実世界のWebで実装してみなければ分からないのに、その実装によるテストが適切に行われたあとではもう仕様を変更するには遅すぎる、という点だ。pushState()に起きたのはこういうことだ。

もっと重大な例もある。CSSのカスケードや適用の仕組みだ。これは素晴らしいアイデアだったが、結局うまく動いていない。あるいはXMLと特定のXML名前空間はひどいものだ知られているが、それでもWebのあらゆるレイヤーがこれに依存している。

JavaScriptのようなプラットフォームの中核をなすものがもともとは実験的なものとして始まったり、Offline Application Cache APIのように、開発者によってどう使われるのかが限定的にしか分からずに開発された、ということでもこれは避けられない（AppCache APIは、その設計の意図通りに使われるのであれば素晴らしい機能だが、しかし多くの人はそうでない目的で使おうとしているために、ひどいものだと思われている）。

要するに、Webのもっとも出来の悪いパーツこそもっとも成功したパーツであり、そこへは数多くの人が拡張をするからこそ、長期的な進化のためにそこでのコーディネーションが必要なのだ。と同時に、これがひどいものができてしまう経緯でもある。

どの要素なら10年後も安心して使えるのか？

──── HTML5と“Living Standard”（改訂され続ける標準）について。どの要素が10年後も安心して使えるものでしょう。クライアントで問題なく動作するものを作ることはできますか？(from @szafranek)

どの要素が10年後も安心して使える動作なのかを見つけるには、2つ以上のブラウザで実装されているかどうかをチェックすればいい。現時点で2つ以上のブラウザで実装されている要素ならば、ほぼ間違いなく10年後も利用できると約束できるだろう。そうでないならば、使わない方がいい。

ただこれは、改訂され続ける標準とバージョン番号を持つ標準の問題ではない。例えばHTML4であっても、 <object declare>タグや<a coords>のように実装されていない要素はある。

──── ユーザーエージェントの分野で十分なイノベーションが起きていると思いますか？ どのブラウザも似たり寄ったりではないでしょうか（From @webr3）

質問の前提には同意しかねる。ブラウザはいろんな面で大きく異なっているからだ。どれも似たり寄ったりに見えるかもしれないし、あるブラウザが新機能を入れると別のブラウザもそうするといったことがよくある。それがWebをよりよくするものだとはいえ、ブラウザを似たようなものに見せているのかもしれない。

一方で私が得意分野としているブラウザの開発面では、Webテクノロジースタックにおいて多くのイノベーションが進んでいて、私はブラウザベンダから新しいスペックに関するメールを山のように受け取っている。

ブラウザの領域においては非常に活発な競争が起きている、特にデスクトップの分野においては過去に類を見ないほどだ。ユーザーにとっては素晴らしい時期であろう。

なぜあなたはいつも“ノー”と言い続けるのか？

──── なぜあなたはいつも“ノー”と言い続けるのですか？ 例えば<picture>要素や<main>要素について(from @helloanselm)。なぜそれほどいつも苛立っているのでしょう？(from @steve_fenton)

手短に答えるなら、それが僕の仕事だからさ！

ここには2つの問いがあると思う。1つ目は、なぜ全体的に見て“ノー”という返答が多いのか。そして2つ目は、なぜ私がそんなに何度も“ノー”と言い続けているのか、だ。

1つ目の問いは、優先度と設計上の問題が組み合わされている。まず優先度について見てみよう。Webに機能を追加するためのリソースは限られている。機能追加には次のようなコストがかかるのだ。

• 実装：誰かがブラウザごとにコードを書かなくてはならない
• テスト：機能がちゃんと働いているか、テストを誰かが書かなくてはならない
• QA：機能が動作し続けてデグレードしていないか、誰かが品質管理をし続けなければならない
• コードメンテナンス：ブラウザベンダがリファクタリングをするなら、機能が増えるたびにコードをリファクタリングし続けなければならない
• チュートリアル：チュートリアル担当は、機能が増えるたびにチュートリアルにそれを追加しなければならない。あるいはそうした方がいいかどうか、リクエストをまとめなければならない
• 認識の負担：Webサイトの開発者が学ぶべきドキュメントがどんどん増えていく。たとえその機能に興味がなくてもだ。
• ページメンテナンス：Webサイトの開発者は、ほかの人がメンテナンス担当になったとき、その機能をどう維持していくのかを知っていなければならない
• 仕様作成：その機能の仕様書を誰かが書かなければならず、かつメンテナンスし続けなければならない
• バグフィックス：仕様や実装にバグが見つかった場合にはそれを修正し、メンテナンスしなければならない
• コードサイズ：機能追加はブラウザのコードを増やしていく（ディスク上のサイズも、メモリ上のサイズも）

（このリストはFAQからできたものだ）

我々は本当に大量の機能追加要求を、Webデベロッパー、ユーザー、ブラウザベンダーらから受け取っている。ゆえに、これらを優先付けしなければならない。

• その機能は複数のブラウザで実装されそうかどうか？ もし1つだけ、あるいはまったくどのブラウザも実装しそうにないのなら、その機能は覚え書き（page of notes）行きとなる。
• その機能がゲームチェンジャー（革新的なもの）か、それとも単なる改善なのか？ もしその機能がこれまでよりWebページで数行節約できる程度の改善なら、追加のためのコストをかけるほどのものではないだろう。
• その機能はWebの理念に合致するか？ もしその機能が、Webページの著者が指定するような参照方法を読者に強要するようなものだとすれば、成功の見込みはないだろう。一方で、それがもし、読者により多くのコントロールを与えるようなものであれば、成功しやすいだろう。
• その機能はほかの何よりも重要なのか？ これは大量の機能追加要求をフィルターする優れた方法だ。そのアイデアは、Webをよりよくするために実現できることとしてどれだけ重要なのか？ そこにあるのは直接的なトレードオフだけではないが、いつでも機会コストというものはある。ある機能を追加するということは、それ以外の機能を追加するリソースや時間を失うとことなのだ。

というわけで、質問に対する答えの前半として、我々がいつも“ノー”と答えるのは、すべての機能追加をすることなどできないからだ。<main>はその代表例で、私の考えでは、これによって得られる価値はそのコストに対してとても小さい。

次に設計上の問題についても見ていこう。機能追加のアイデアに対して我々がとるいつものアプローチは、まず問題を定義し、それに対するいくつかの解決策を考えて、それらを比較することだ。これが、ある機能追加に“イエス”と答える代わりに、そのほかのすべての選択肢に“ノー”と言い続けなければならないことへの大きな理由でもある。

<picture>はこうした例の1つだ。我々は問題を示し（このやりとりにも数カ月かかったが）、その問題がはっきりした時点で複数の解決方法が提案され、これまでの経験から設計上の落とし穴などにはまらないようにしつつ適切な解決策を編みだしていく。<picture>では、<video>や<source>などの経験から、複数の要素をリソース選択に使うのは設計上の大きな落とし穴だと学んでいる。だから、この問題を解決するうえで私はその落とし穴を回避したのだ。

というわけで、答えの後半は、あるソリューションを採用するために、私たちはそれ以外のものに“ノー”と言っているのだ、ということだ。

さて、2つ目の質問は、私がなぜほかの人に比べて頻繁に“ノー”と言っているのか、ということだ。これは基本的に政治的なものだ。“ノー”というのは簡単なことではない。感情的にも自然なことではないし、議論を呼びやすいからだ。どのブラウザベンダも、議論している時間的余裕があるわけではない。でも私はそうする、それが仕事だからであり、これまで何年も“ノー”と言ってきたことで少しやり方が上手くなった。

多くのベテランのブラウザエンジニアは人々の意見を私の方へ向けようとしていて、私が彼らに“ノー”というように期待もしている。これによって彼らはブラウザの開発により多くの時間を割けるようになっている。彼らもWHATWGのメーリングリストは見ていて、“こいつはまいったな”と思っているかもしれないけれど黙っていて、“Hixieがうまくやってくれるだろう”と思っているのだろう。

現実には、私は本当の意味で“イエス”も“ノー”も言うことはできない。私が言っていることに意味があるわけではない、ブラウザを開発していないのだから。けれどブラウザベンダーは、私が仕様にしたものを実装しないことで実質的に“ノー”と言うことができる。ちょうど先週、私は仕様書の一部を改訂したところだが、それはどのブラウザも実装しなかったものがあったからだ。

私の人生で数年を費やした仕様であるXBL2は、いまはどこにも存在しない。ブラウザベンダがそれを実装したくなかったためだ（XBLでの私の最大のミスは、一度にすべての問題を解決しようとしたことだ。むしろ、段階的に実装できるようにすればもう少し扱いやすかっただろう）。

似たようなものとして、私がノーと言って仕様にならなくても、ブラウザベンダが実装してしまうものがある。コンテキストメニューの例では、Geckoが<menuitem>と呼ばれる要素を実装したが、それは悪い設計だと言わざるを得なかった。しかし彼らは私の意見に賛成せずそれを実装してしまい、結局、私は仕様書を<menuitem>を含むものへと改訂したのだ（これはMozillaを非難しているのではなく、ものごとがどう進行するのかの例を示しただけだ。彼らが間違ったことをしたということではない）。

≫続きは「Webプラットフォームは複雑になりすぎていないか？ HTML5仕様のキーパーソン、Hixieへのインタビュー（中編）」へ。