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

2013年1月15日

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

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

fig Interview with Ian Hickson, HTML editor | HTML5 Doctor

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

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

Interview with Ian Hickson, HTML editor

fig Ian Hickson氏

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に機能を追加するためのリソースは限られている。機能追加には次のようなコストがかかるのだ。

(このリストはFAQからできたものだ)

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

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

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

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

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

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

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

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

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

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

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

このエントリーをはてなブックマークに追加
Bookmark this on Delicious

タグ : HTML5 , W3C , Web標準

≫次の記事
Webプラットフォームは複雑になりすぎていないか? HTML5仕様のキーパーソン、Hixieへのインタビュー(中編)
≪前の記事
2012年12月の人気記事「ブログでメシが食えるか」「Facebookアプリを、HTMLでどうしてサクサク」「Amazonは1時間に最大1000回もデプロイ」

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


新サイト「Publickey Topics」始めました!


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
RSSリーダーで : Feed





アクセスランキング - 過去7日間

  1. アップルの新言語「Swift」がバージョン1.0到達。Swift製アプリがApp Storeへ提出可能に
  2. リアクティブプログラミングの「Meteor 0.9.2」登場、iOS/AndroidアプリもPhoneGapで可能に。ブラウザから簡単にコードを試せる「MeteorPad」も公開
  3. ビジネスが変わればソフトウェアの品質も変わる。ソフトウェアがビジネスの鍵を握る時代の新しい品質とは。ソフトウェア品質シンポジウム 2014
  4. MINIX 3.3がリリース。1万2700行ほどのマイクロカーネル、ARMサポートとクロスコンパイラなど対応
  5. Google Cloud SQLがリードレプリカに対応、プレビュー公開
  6. ヒューレット・パッカード、AWS互換のクラウド基盤ソフトEucalyptusを買収。同社のOpenStack路線をAWS互換で強化か
  7. Rackspace、身売り交渉を打ち切り、単独でクラウド市場を戦うと表明
  8. IT系企業の平均給与を業種別にみてみた 2014年版 ~ ネットベンチャー、ソーシャル、ゲーム編
  9. 日本IBM、国内向けにクラウドマーケットプレイスを開始。IaaS、PaaS、SaaSを1カ所から調達
  10. ITまんが 2014年版 ~ ITが楽しく分かるマンガを集めてみました
  11. Chef 12がリリース。商用版とオープンソース版の一本化で25ノードまで無償に。Docker対応、VMware vSphere、Microsoft Azureにも対応
  12. 2014年8月の人気記事「ITまんが 2014年版」「ソニー銀行は金融機関としてAmazonクラウドをどう評価したのか?」「VMware、Dockerのような独自の新技術発表」ほか
  13. タネンバウム教授、MINIXの失敗とLinux普及の理由を語る
  14. Publickey Smar
  15. ソニー銀行は金融機関としてAmazonクラウドをどう評価し導入したのか? AWS Summit Tokyo 2014

Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus