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

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

そのHTML5仕様策定のエディタ、Ian Hickson氏、通称Hixie（ヒクシー）に、同じくHTML5界の著名人であるオペラのBruce Lawson氏がインタビューした記事「Interview with Ian Hickson, HTML editor」を許可を得て日本語訳しました。

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

どうして休暇も取らずにHTMLのエディタを続けているのか？

──── あなたは仕様担当エディタとして、Webデベロッパーからのフィードバックがブラウザベンダと比較して十分なものだと感じていますか？（@webr3）

十分というのがどれだけのものかは分からないけれど、これまでに十分なフィードバックがあったかどうか？

我々は多くのフィードバックをWebデベロッパーから得ているが、その多くはreddit、Twitter、Google+、ブログなどのフォーラムやサイトを巡回して集めたものだ。私はHTMLへの不満を示すサイトを見つけるためのGoogle Alertを設定している。つまりフィードバックは十分ではないと言ってほとんど間違いないだろう。

私は、もっと多くの人が仕様のバグ対応の筆者とか、WHATWGメーリングリストに参加してくれればと思っている。みんなはたぶん、どれだけフィードバックがあるのか見たことがないのだと思うし、ブラウザベンダから送られてくるフィードバックも「Webデベロッパーが言っていたのだが……」といった形式のものが多い（彼らはそのことをはっきり言わないことも多いけれど）。

問題を率直に言うと、多くの開発者は自分でもどんな機能を求めているのかよく分かっていないのだ。何年も前、グーグルは私が仕様を書いた（microdataの）いくつかの機能についてユーザービリティテストをしたところ、いかに多様な反応があるかを非常に良く示した。私たちは「これとこれで、どちらがシンプルだと思いますか？」といった質問をしたが、それで分かったのは、そこで反応が良かったものと、実際に使えるものとのあいだには何の関係もなかったということだ。

しばしば送られてくるフィードバックには、「機能Xが必要だ」や「Yのようなやり方の機能Zが必要だ」といった要望があるが、実際に彼らがどんな問題に直面し、どう解決したいのかをよく聞いてみると、（a）実際には問題があったわけではなく、単にいいアイデアだろうと思って提案していた、（b）その提案は問題を解決するわけではなかった、ということがよくある。私たちはしばしば、もっと簡単な解決方法や、既存の対応機能を見つけられた。

──── 2年半前、私は“HTML6のエディタを担当したいですか？”と質問し、あなたは“HTML5が済んだら、少しペースを変えたい”と答えてくれました。どうして休暇も取らずにHTMLのエディタを続けているのですか？

まだ終わってないからさ。まだ238通のメールと163のバグが残っている。

──── 退任についての考え、あるいはHTML仕様のエディタについての見通しはありますか？

私はいつでも辞められるんだ、本当にね。私の興味が続く限り、そして実装をする人たちが私の仕事を参照してくれる限りは続けるよ。辞める？ 良い仕様を書く能力のある仕様担当の書き手の不足は深刻なんだ。

──── フォームコンポーネントをスタイリングするために、XBLを待とうという話をし、いまはWeb Componentsを待っています。Anne van Kesterenは“もう10年待った。私はもうこれをベイパーウェア（当てにならないソフトウェア）と呼んでいいのではないかと思っている”と言っています。あなたの考えは？

誰かがいい提案をしてくれるなら、いつでも歓迎するよ。

グーグルからの影響はないのか？

──── あなたはグーグルの社員で、そしてグーグルはブラウザやモバイル用のOSなど幅広いWeb関連製品を提供しています。あなたは会社から、仕様に関する判断を会社のビジネス戦略に沿うように求められたり、影響力を発揮するように求められたりしないのですか？

いや、まったく逆だ。私が働き始めたとき、グーグルの短期的な利益よりもWebの長期的な利益を優先させるべきだと非常に明示的な指示を受けた。

これはこうもいえる。グーグルで働こうと思った理由の1つは、そこで働くことユニークな視点を持てることと、グーグルが持つデータにアクセスできることだった。私の意思決定において会社からの影響がないことは明白だ。

──── 仕様エディタ以外の業務はあるのですか？

基本的にはHTML仕様についてフルタイムで行っているが、それ以外の業務も社内的にはある。

Webプラットフォームは複雑だが、そこは問題ではない

──── Webプラットフォームは複雑になりすぎていませんか？（Web Components、Shadow domなど）

どれくらい複雑なのかな？

──── プロのデザイナーや開発者よりむしろアマチュアや初学者にとって、とか。the pastry box projectなども参照。

もうずいぶん前から、その全部を理解しようとする誰にとってもこのプラットフォームは複雑になりすぎている。だから私は完全に理解するのを止めた部分もある。例えばWebGL、IndexDBなど。それにJavaScriptのprototypeモデルにおけるsubtlrの振る舞いとか、Unicodeの両方向テキストのアルゴリズムなど、理解しようという努力に対してあまりにも複雑な領域は増え続けている。

多くのWebデベロッパーも、Clearセット時のfloatとdivの領域のマージン展開を理解できていなかったり、inlineボックスモデルを正確に理解できていないだろうと思う。

でもこれは驚くようなことではなく、例えばWindowsでいえばNTカーネルAPIからDirect3D APIなどプラットフォーム全部を理解している人など、あまりに複雑すぎて誰もいないことは間違いないだろう。

だからこれが問題だとは私は思わない。

──── WHATWGができたのは、W3Cがあなたに“HTMLはほとんど終わっている。もしHTML5のようなことをしたいのなら、ほかへ行くべきだ”と告げたからでした。しかしいま、W3Cはその見方を変えるようになりました。とすれば、WHATWGは解散し、W3Cに参加してW3C内部でWebプラットフォームの開発を続けていく時期なのでしょうか？

以前そうしようとした（2007年から20012年）。しかしうまく行かなかった。事実、私たちはW3C外でより多くの仕様を策定している！ WHATWGは8人かそこらのエディタで12の仕様を担当しているのだ。

──── なぜうまく行かないのだろう？

それぞれの優先順位、ビジョン、アプローチが異なっているからだ。たぶん、自分はそのことに答える適切な人間ではないと思う。

アクセシビリティで論争があるのはなぜ？

──── あなたがよく論争しているのは主にアクセシビリティの人たちのように見る。それはなぜ？

分からないな。

──── 以前“障害者（のアクセシビリティ）はそのほかの人たちのそれと同じように大事だ”と私に話してくれた。けれど、彼らはあなたが障害者の求めに対して十分な理解を示していないと考えているようだ（longdesc、table summary、altテキストのre-writingルールなど）。これはつまり、あなたはこうしたものがない方が障害者にとってよいのだと考えているとも思える。どうだろう？

この質問の前提は、世の中に唯一のアクセシビリティコミュニティがあり、意見は1つであり、それが障害者の要望全体を示しているようだ。しかしどれもそうではない。

世の中には複数のWebアクセシビリティコミュニティがあって、その中の人々は、しばしばお互いの合意に至らないときもあるし、障害者にもさまざまな人がいて異なった要望と意見がある。それにアクセシビリティコミュニティがいつも障害者の意見を代表しているわけではないこともある。

あなたが挙げた仕様について説明しておこう。

longdesc=""という解決策は、ほとんど誰も使わず、使われたとしても間違って使われ、それゆえに長い間無視されていた。それが使われないことで、ほかのアクセシビリティ向上策に時間を割くことができるのだ。“Dive Into Accessibility”の著者Mark Pilgrimが、このことについて書いている。

Table summariesについては、HTML spec for <table>を参照してほしい。この最初のパラグラフに、<table>タグは表データのためにある、と書かれている（これはレイアウトにtableタグを使うことを抑制し、それはアクセシビリティにとって良いことだ）。そして二番目のパラグラフには、表データとは（格子状である）、三番目のパラグラフではテーブルモデルの定義にリンクされ、四番目のパラグラフではWebページの作者に向けて、複雑なデータをどうやって複雑な表型で表現するか、などの説明と、セクション全体が、いかにtable summariesを示すかが説明されている。このセクションでは、6つの異なった方法がそこで示されている。

altテキストのre-writingルールは、<img>セクションの最初で言っているのは、<img>タグはイメージを示していると言うことで、かいつまむと、いかにイメージのURLを提供し、3つ目のセンテンスでaltに触れている。そしてここでさまざまな方法でaltテキストを書くべきか多くのユースケースを紹介している。これが最初に書かれたとき、いままで書かれたaltテキストの説明の中で群を抜いて、詳しく説明されたものであっただろう。

ということで、我々は3つのうち2つの機能は削除せず、劇的に拡張している。削除された1つについては、間違った機能であり、それをデータで裏付けている。

HTMLパーサ仕様が、これまでで一番誇れる仕事

──── これまでで最大のミスは何でしたか？ そしてもっとも誇れるものは？

HTMLパーサ仕様がおそらくいちばん誇れるものだろう。数年前、それは非合理な作業のように見えて、私は絶対に手をつけないと言っていたし、大規模なものだったからだ（そして我々はまだ完了しておらず、少なくとも1つの重大なバグがある）。

しかし、これは何よりもHTML仕様で最高の業績だ。我々は4つの、まったく異なるアプローチで作られ、末端までまったく振る舞いの違うブラウザが存在する世界から、それぞれのブラウザがこれまでにないインターオペラビリティを実現し、非常に近しい振る舞いをすることに合意した世界へとやってきたのだ。

これに関してはアカデミックな論文はあったが、パーサ仕様の書き方はこれまでとまったく変わったし、この先何年かで、ほかの仕様についての波及効果も期待している。

これまで仕様書は、仕様に適合するコンテンツをどのようにパースするかについてだけを、宣言的に記述するべきだと考えられてきた。しかしいまはそれが幼稚で時代遅れに見てしまう。

最大のミステイク……どれかを選ぶには多すぎる！ pushState()は、好みのミステイクだ。それは、使えない引数や、あまりにも多くの人にその機能が求められていたために仕様が固まる前から主要なサイトで使われ始めてしまい、その互換性を守るために変更できなくなってしまったというまったくくだらない理由で終わってしまったAPIだからだ。

postMessage()のセキュリティモデルは設計上あまりにも貧弱だ。論文では、いかに私の頭が悪かったかが書ている。これもかなり大きなミステイクだろう（postMessage()を安全に使うことは可能だ。いつも誤解されるが、それを安易に使うと安全ではないだけだ）。

appcache APIはまた別の大きなミステイクだ。問題を理解する前に設計してしまうとこうなる、という好例だろう。とはいえ、引き続きこの問題とは格闘している。

技術レベルではなく政治的なレベルで考えると、WebSocketsをIETFに持って行ったのは大きな間違いだったと思う。それは結局、仕様策定を遅らせ、何の改善もなく文字通り1年が過ぎてしまい、しかも彼らはプロトコルのセキュリティを損なうような多くの変更をしてしまった（もういちど言うが、安全に使う方法はある。IETFが関わる前ほど簡単ではなくなってしまったが。皮肉なことに、彼らは我々がpostMessage()の間違いから学んだ多くのことを破壊してしまった）。

我々は引き続きcompressionやmultiplexingなどの機能を待っているが、おそらくIETFに渡さなければすでにそれらはできあがっていたのではないだろうか。

Web Storage APIを設計したときもまた、スクリプト実行時のAPIの同期や一貫性要求に関して信じられないようなミスをした。要するに、ある場所1つでWebプラットフォーム全体がほかのプロセスのブロックを要求するようになってしまったのだ。どのブラウザもこれを実装せず、我々はその代わりに一貫性が保証されないAPIを手にすることになった、その方がむしろ怖いのだが。

HTML仕様以外で、私のもっとも大きな間違いは、私がCSSワーキンググループにいたときにさかのぼる。CSS2では、David Baronと私が扱ったマージンの展開とインラインボックスモデルについて、あいまいなルールだったのを、かっちりと定義されたものに変えた。いまでもこの仕様は、全体にうまく定義されたままだが、まあ普通ではないほど複雑なものだ。我々はそうする代わりに、もっとシンプルで、理想的にはそのときのブラウザの実装にもっと合致したものにするべきだったのだろう。

この副作用の1つは、いま“Quirks Mode”やDOCTYPEによる切り替えとなっている。もっとブラウザの実装に合っていて、こうしたモード切り替えに悩まされないようにするべきだった。

Acidテストでも私は間違いを犯した。ここで私がテストした仕様は、無視された方がよかったものも含んでおり、それがあとになってスキップした方がよいものまでブラウザに実装させることになってしまった。そのいくつかはなんとかなったが、全部ではなかった。Acid2ではSVGフォントまわりでやるべきではないことまでしてしまったし、Acid3ではSGMLコメント関係のあとになって全部放棄されるようなとんでもないものまで含んでいた。

XBL2の開発でも多くの間違いがあったが、こうした間違いは単に無視され、長期的に見てコストとしては機会コストとソリューションを得るのが遅れたということになった。

たぶんほかにも大きな間違いが思い出せないでいるのだと思う。

＞続きは「ギーク都市伝説「WebSocketは鉄道模型をコントロールするためのものだった？」 HTML5仕様のキーパーソン、Hixieへのインタビュー（後編）」へ