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

2013年1月16日

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

Interview with Ian Hickson, HTML editor | HTML5 Doctor

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

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

WebSocketを作ったのは鉄道模型をコントロールしたかったから？

──── ギーク都市伝説によると、あなたがWebSocketを作ったのはブラウザを通じて鉄道模型をコントロールしたかったのにできなかったからだ、と言われています。本当ですか？

間違いなくWebSocketのような仕様にはたくさんの要求があり、鉄道模型をコントロールしたいというのが唯一の理由ではない。けれど、それは私にとってモチベーションのカギとなるものだった。WebSocketなしでは、GET関連の慣れ親しんだ技術を使わざるを得ず、それはミリセカンドレベルのレイテンシがあるから、2台の機関車をそれなりの速度で走らせていたら致命的なことになりかねない。だから私はWebSocketを、私が行ったプロジェクトの大事な1つとして考えていた。

──── あなたはmicrodataは好きではなかったけれど、RDFaは汚くて書きにくいからmicrodataの仕様を作成したと……

microdataが解決すべき問題が興味深いとは思えなかったが、それほどmicrodataが嫌いだったわけではない。もちろん、十分多くの人がその問題を解決すべきと考えたいたわけだし、だから私はほかと同じようにその問題解決に当たった。これはHTML仕様が私の思い通りに行っているわけではないといういい例だ。

──── WHATWGはRDFa関連の機能を狙いましたね。RDFa LiteはFacebookのOpen Graph Protocolと互換性を持ちつつ、microdataができることは全部できると。

RDFa Liteはmicrodataができることを全部できるわけではない。microdataにしかできないことがいくつかあって、それこそ大事なところだ。

RDFとは何の関係もない
prefixingメカニズムをまったくサポートしていない
ドラッグ＆ドロップAPIとの統合ができない

ほかにもたぶんあると思うが、RDFa Liteをそれほど詳しく調べていない。

──── RDFと関係ないことがなぜ大事なのですか？

そこがmicrodataやmicroformatsがRDFベースのテクノロジと比較してもっともシンプルなところだからだ。

──── 分裂を防ぐために、microdataの仕様を取り除いてその代わりにRDFa APIとRDF Liteを代わりに組み入れますか？そうしないのであれば、それはなぜですか？

ポイントはmicrodataはすでに広く使われていて、我々が望んだとしてももう取り除くことはできないからだ。それにRDFaが同じ問題を解決しないのであれば、そうはならないだろう。

RDFa（あるいはRDF）とmicrodataにはデータモデルに根本的な違いがある。RDFはトリプル（本当はクワッド）データベースだ。Microdataは木構造で示される。MicrodataはRDFよりもJSONで使うのが一般的だ。

──── 山括弧（<>）についてはどう思っていますか？

それは問題なの？山括弧について誰かが何か考えているなんてことは知らないな。

JSONは気に入っている

──── HTMLはJSONに対してはどうするのですか？（from @pal_nes）

異なる問題には異なるソリューションがある。

JSONにない大事な機能であればいいと私が思うのは、エラーハンドリングの定義だ。いまのところ、変なJSONデータを扱ったときの振る舞いはパーサごとにばらばらだ。

とはいえ私はJSONは気に入っているし、よく使っている。我々は何にでも使えるよいフォーマットを得たと思う。しばしば、もっともよいフォーマットとは単に改行されたプレーンなテキストだったり、JSONのようなネストされたツリー構造だったり、XMLのようにネストされアノテートされたツリーだったりするし、バイナリのビットマップだったりする。

みんな自分のフォーマットを必要以上に考えていないのではないだろうか。パーサを書くのは難しくないし、コンピュータサイエンスではその分野は非常によく研究されているところでもある。JSONのようなものを利用するのは、クロスリファレンスが不要なスタティックなJavaScriptの構造をシリアライズするのにはよいと思う。もし扱うデータ構造がそういうものでないのならば、JSONを使うのは専用フォーマットを使うよりもおすすめできない。

──── もしも<body>タグの中には何も書かず、DOMをスクリプトで生成するとしたら、それは何か問題になるのでしょうか？

スクリプトをオフにしている人にとっては明らかに問題だと思うけれど、それ以上にそれはオーサリングの選択の問題だと思う。

マークアップを静的に記述することには明らかに有利な点がある。例えば、バリデートして文法的なエラーを確認できる（例えば<option^>を使う代わりに<select>を<input>中に書いてしまうとか）。今日のHTMLは、Web appを容易にする機能を備えてもいる。hidden=""や、DOMクローニングなどだ。

しかし、スクリプトによる生成にも同様に利点がある。その1つは、何らかのインスタンスをいくつか作りたいとき、いちばん簡単なのはJavaScriptでデータを呼び出してテンプレートの場所に書き込んで行けばいい。

個人的には、Webアプリを書くときには（たいていゲームだが）変化しない部分では静的なHTMLを部品として書き、JavaScriptで残りの部分を書き込んでいる。例えば、いま取り組んでいるあるゲームでは地図のリストがあり、<ol>はあらかじめ静的に書いてあるが、<li>は動的に生成している。

──── スクリプトについて話しましょう。DARTについてはどう思いますか？

意見を言えるほどちゃんと調べたことがないな。もしWeb言語としてのJavaScriptを置き換えようとするつもりなら、かなり厳しい戦いになると思うけれど。Webの何かを置き換えようとするのは、何にせよとても難しいものだ。

ネイティブ対Webはどうなる？

──── 長期的に見て、デバイスの開発やインタラクションモデルはWeb標準にどんなインパクトを与えると思いますか？(from @wcagtest)

それらが標準の開発に影響することはまったくないと思う。新しいインタラクションモデルとそのほかのインターフェイスに特に違いはない。しかしWebとWeb標準群には明らかにインパクトがあるけれど、それがどんなものかは分からない。

個人的にはGoogle GlassやPebbleのようなものがWebをどう進化させていくのかには注目している。

これまでWebが小さな画面やタッチUIなどをうまく扱えなかったことは残念だったと思う。Webは本来的にはメディア依存していないから、いずれうまく扱えるようになると希望を持っている。

本音を言えば、小さな画面への対応は、そもそも大きな画面を想定し、柔軟性を失っていたWebデザイナーを責めたい気持ちだが、それも変わりつつある。タッチUIに関しては、Webの一般的なUIのイベントにもっとうまくマッピングできていたらと思っている。タッチはクリックに簡単に割り当てられるが、ドラッグ＆ドロップはタッチでは割り当てられないし、ピンチもホイールイベントに割り当てられていないなどだ。

私は、本当に成功した最初のタッチブラウザが標準を作り上げていくと考えているし、過去にそうしたものの多くは小さくて隠れていたチームが成し遂げた。

──── モバイルデバイスでは、ネイティブアプリがWebアプリを打ち負かすのでしょうか？

ネイティブプラットフォームとWebはそれぞれまったく違った性格を備えている。Webはその設計自体、ベンダーニュートラルでデバイスニュートラルの性格が強く。これは非常に大きなメリットであり、誰かもが単独でWebを亡きものにすることなどできない、ということだ。

例えば、WebページやWebアプリをあなたが作ったとしよう。明日、OSベンダやスマートフォンベンダが倒産したとしても、あなたが作ったものはそのまま見続けられるし、使い続けられる。一方、もしも独自のプラットフォーム、例えばAmigaやOS/2を選んでいたとしたら、サポートは失われてしまい、アプリケーションを使い続けることはできなくなってしまう。

個別のベンダのきまぐれによりシステムが変わってシステムを保有するコストの大半はイノベーションによるものだが、それはマルチベンダーの議論から起こるものではない。もしもあなたが独自のプラットフォームを持っているのなら、そこに機能追加するのは簡単だ。単にそうすればいい。誰かと相談する必要などない。

Webでは、おもな実装者がその機能を追加するべきだろうと合意したときにのみ、機能追加が行われるが、それは普通、ネイティブプラットフォームでそうした機能が有効だと証明されてからのことになる。だからネイティブプラットフォームではイノベーションがより迅速に起きるのだ。

モバイルの世界でネイティブアプリにフォーカスが当たるのはこうした理由による。つねに新しい時代には派手な新機能が登場するものであり、Webはそのあとをついて行くことになる。先端分野はつねにネイティブなのだ。

デスクトップでもそうだ。デスクトップOSのイノベーションのスピードはまったく落ちてしまっていて、そのおかげでそこでのWebは成熟でき、Webアプリが素晴らしいものになれるのだ。イノベーションという面では、すでにモバイルはデスクトップを一世代も二世代も先を行っている。

──── フリーでオープンなWebに対する最大の脅威は何ですか？

特許だ。

──── あなたのToDoリストに、次にすることとして何が書いてあるのですか？

バグリストのトップにあるのは、“document.open()仕様はパーサがscript-createdだったときに実際の動作と合致しない”とある。難しいやつだな。それと、いまのメールの山の中でいちばん上にあるのは、bz（Boris Zbarsky）からのHTMLパーサに関するフィードバックでの面倒なやつで、あるDOM APIのセキュリティ実装に関する振る舞いについてだ。やれやれ、そろそろ昼飯にでもしようか。

著者について

著者のBruce Lawson氏は、OperaでOpen Web標準のエバンジェリストをしている。それ以前は、Solicitors Regulation Authorityサイトのテクニカルリードだった。introducing HTML5の共著者。ブログはbrucelawson.co.uk、ツイートは@brucel。