5分で分かるHTML5

そろそろHTML5の本格普及時代が到来しそうな雰囲気。

HTML5って何が新しくて何が嬉しいのか、自分に関係あるのかないのかよく分からないという人も多いのではないでしょうか。

HTML5とはいったい何なのか、できるだけ簡単な説明をしてみます。

HTML5を一言で言うと

誤解をおそれずに一言で言うと、HTML5とは、JavaScriptライブラリの仕様です。

新しいタグが導入されたとか、タグの属性が大幅に増えたとか、いわゆるマークアップ言語としての進歩も、もちろんあります。

その中には、Web制作者にとって大きな意味を持つものもあります。

が、HTML5がこれだけ騒がれ、画期的だと言われている一番のポイントは、JavaScriptからグラフィックが描画できたり、リアルタイム通信がおこなえるという点です。

これまでFlashが必要だったり、メディアプレイヤーが必要だったり、ブラウザ依存だったりした機能が、全世界レベルでの公式仕様として策定され、JavaScriptのみで操作できるようになるのです。

この仕様群のことをHTML5 APIと呼びます。

これがHTML5の核心です。

ざっくり言うと、JavaScriptだけで次のようなことができるようになります。

ブラウザウィンドウに直接描画したりユーザ操作のイベントを取得できる
プラグインなしで音声や動画が再生できる
ブラウザのウィンドウやタブ間で通信ができる
サーバ側からクライアントにデータを送り込むことができる

つまり、PCのデスクトップと本質的に遜色のないアプリケーションがウェブブラウザ上で開発できるようになる。

ブラウザが真の意味でプラットフォーム化する基盤がHTML5なのです。

HTML5 APIのまとめ

HTML5の重要なAPIは全部で８つ。

キャンバス
メディア情報
位置情報
クロスドキュメントメッセージング
WebSocket
WebForms
WebWorker
WebStorage

キャンバス

ブラウザのウィンドウをキャンバスに見立て、線や矩形や楕円を自由な位置に描画する機能です。

<canvas>タグで囲まれた領域内に、JavaScriptの中から好きなように描画できます。

Canvas自体は非常にプリミティブで、直線や曲線を引く、マルや四角を描く、画像を表示する、くらいの機能しかありません。

ということは、これから各種の描画ライブラリが大量に開発されるはずです。そしてその膨大なライブラリの中から一大整理統合進化発展淘汰が湧き起こり、いずれデファクトスタンダードが生まれるでしょう。

でも今は線が引けるだけ。

<script>
function drawDiagonal(){
    var canvas = document.getElementById('diagonal');
    var context = canvas.getContext('2d');
    context.beginPath();
    context.moveTo(70, 140);
    context.lineTo(140, 70);
    context.stroke();
}
window.addEventListener("load", drawDiagonal, true);
</script>
<canvas id="diagonal" style="border:1px solid black;" width="200" height="200"></canvas>

メディア情報

音声と動画を標準で再生できるようになりました。

これまでは、FlashプラグインやQuickTimeプラグインなどが必要でしたが、それが不要になります。

タグの書き方も簡略化されました。

<audio src="sound01.mp3"></audio>
<video src="video.mp4"></video>

一番カンタンには、↑こんな感じで書けるわけ。

ただし、ブラウザがサポートしないコーデックはもちろん再生できません。

それから、これはけっこう痛いと思うんですが、ストリーミング再生もサポートされません。

そんなわけで、微妙に中途半端なサポートになってる気もしますが、これから整備されていくと信じましょう。

位置情報

ブラウジングといえば、パソコンで机の前に座ってするもの、というのがこれまでの常識でしたが、スマートフォンの登場で状況は一変しました。

あなたのJavaScriptが動作しているのは新幹線の中かもしれないし、エベレストの山頂かもしれない（エベレストなうが可能に）。

その位置情報をJavaScript側から自然に取得できるようにしたのが位置情報APIです。

位置情報は緯度（Latitude）・経度（Longitude）・精度の属性を持っています。

PCのブラウザでIPアドレスベースの位置情報なのか（50～100km程度の精度）、GPSによる位置情報なのか（20～100mの精度）によって挙動を変えたいことがあるからですね。PCベースのブラウザに対して、100km離れた隣の市でやってるスーパーの特売情報を見せてもしょうがないわけ。

navigator.geolocation.getCurrentPosition(updateLocation);
function updateLocation(position){
  var lat = position.coords.latitude;
  var lng = position.coords.longitude;
  var acc = position.coords.accuraty;
  // 位置情報の利用 ...

}

クロスドキュメントメッセージング

これまでのブラウザの制約を根本から解決する画期的な仕組みです。

一言で言うと、JavaScriptから別サイトのコンテンツにアクセスできるようにする仕組みです。

スクリプトから別サイトへのアクセスが厳しく制限されていたのは、セキュリティ上の理由からです。

それを許すと、コンテンツ盗用、なりすまし、改ざんなどのさまざまな悪用が可能になってしまうからです。

でも、別サイトのコンテンツに正当にアクセスしたいケースもあるわけです。

そこで、アクセスする側の「身元情報」を付加し、アクセスされる側が「こいつにアクセスを許してもいいか」を判断できるようにして、OKならばそいつからデータを受け取ることを許す、という仕組みです。

たとえばニュースフィードを表示するページで、ニュースに登場する人名を自動的に拾ってGoogle画像検索に送り込むとか、地名を拾ってGoogleMapに送り込むといったことが可能になるわけです。

次に紹介するWebSocketと併用することで、あらゆるデバイス上のあらゆるブラウザウィンドウ同士でリアルタイムに通信するという、これまでのパラダイムからすると夢のような世界が広がります。

WebSocket

サーバからクライアントに対してデータを一方的に送りつけることができる仕組みです。

「ポーリング」とか「Comet」という単語を聞くとイヤ～な気持ちになる人であれば、たったこれだけのことがどれだけ画期的か分かるでしょう。

HTTPというのは、リクエスト＆レスポンス型と呼ばれるタイプのプロトコルです。クライアントからの「リクエスト」がなければ、サーバからはデータを送れないのです。

WebSocketの最大の利点は、ネットワークトラフィックが激減する点です。

クライアント側からポーリングして擬似的に双方向通信をおこなう場合、毎回HTTP GETリクエストを送る必要があり、毎回バカでかいHTTPヘッダが付加されます。

HTTPヘッダというのは、最小限のものでも平均して1500バイト～2000バイトあります。

本体データが20バイトとかだったりすると、本体データの100倍ものオーバーヘッドが生じるわけ。

このオーバーヘッドが消えてなくなります。

WebSocketを使うと、インターネット上に「サーバとクライアントを直結するパイプライン」を作れるということ。

で、そのパイプラインには、どちらからでも、どんなデータでも、リアルタイムで流すことができるってことです。

どう？非常に非常にエキサイティングな気がしません？

WebForms

新しいフォームAPIでは、要素タイプが大幅に増え、実用的な文字種制限、入力バリデーションなどができるようになりました。

たとえば

tel
email
url
search
といった要素タイプが増えました。

<input type="email" />

とか書けます。

ま、嬉しいっちゃ嬉しいですな。

ただね、これ、10年くらい前だったら世界中が歓喜した仕様でしょう。でも、ここいらへんの動作は、もうすでにCSSとJavaScriptの組み合わせで、あらかたできちゃってるんですよね。

どうしようもないんだけど、「今さら感」がどうしても拭えない。

いちいち入力支援用JavaScriptライブラリをロードしなくても、入力バリデーションができるようになるのは嬉しいですけどね。

WebWorker

スクリプトをマルチスレッドで実行することができるメカニズムです。

スクリプトをバックグラウンドで動作させることができます。

WebWorkerにJavaScriptファイルを渡すと、バックグラウンドでスクリプトが実行されます。

ただ、WebWorkerには一つ大きな制約があって、ブラウザオブジェクトには直接アクセスがいっさいできません。ウィンドウオブジェクトにも、ドキュメントオブジェクトにもいっさいアクセスできません。

ウィンドウを更新したい場合はどうするかっていうと、表側のスクリプトに対してメッセージを送るんです。

重たい演算処理なんかをバックグラウンドで実行し、その結果を適宜表示するような用途に向いています。

WebStorage

ローカルにデータを保存できる仕組みです。

もともと、ローカルにデータを保存する仕組みとしてクッキーというのがありました。

1. 最大4KBしか送れない
2. リクエストのたびにサーバに送信される

という欠点がクッキーにはあって、それはそれは使いにく～いものでした。

この辺の制限を全廃したのがWebStorageです。

WebStorageは、クッキーと同様、キーと値のセットで保存・取り出しをおこないます。

サイズの制限はありません。

JavaScriptのexpandoプロパティを使えば、ほぼノーストレスでWebStorageを利用できます。

window.sessionStorage.myDataKey = 'これがアイテムの値になります';

一応新しいタグの話も

新タグの追加

「ここはヘッド部分」とか「ここはナビゲーションバー」といった構造をあらわすためには、これまで<div>タグでidやクラスを指定するしかありませんでした。

<div id="header"> ... </div>

とか

<div id="nav"> ... </div>

などのように、あらゆる構造をぜんぶ<div>一つでまかなってきたわけです。

そして、CSS側でidを指定して、見た目をコントロールするという手法が主流でした。

HTML5では「構造を表したいんならそういうタグを作っちゃえ」という現実主義的発想から、たくさんの新タグが定義されました。たとえば次のようなタグです。

<header>
<footer>
<nav>
<section>
<article>

言ってみれば、実装者ごとにバラバラだった<div>タグのid指定の方法を、万国共通の仕様として定義したようなものです。

でもあんまり使いたくない

ただ、こういう新しいタグは、僕は個人的にあんまり積極的に使いたくはない。

なぜなら、こういう「自然に広まった」使われ方を後から定義した、いわゆる後追い仕様というやつは、５年経つと誰も使わなくなるって傾向があるからです。

要は流行の後追いですから、どことなく「NHKに取り上げられたら流行はおしまい」みたいな危惧が拭い切れないんです。公式仕様になった途端にだれも使わなくなるような気がしてなりません。

現に、ここ(レトロ印刷 Jam)とかここ（株式会社細尾）のように「ヘッダ」や「フッタ」、「記事」という概念では表せないデザインが流行の兆しを見せています。

今主流のサイトは、１０年経てば間違いなくレトロ感タップリな懐かしいデザインになっているに違いありません。そうした未来的状況において、果たして「ヘッダ」や「セクション」などといった概念が生き残っているのかというと、はなはだ疑問なわけです。

便利なものは使いますが、長期的な展開が不透明なものに依存すると、あとあとなんか大変な気がして、イマイチ積極的になれないんですよね。

誰がどう嬉しいのか

HTML5はどの分野の開発者がどのように嬉しいのでしょう。以下にまとめてみました。

サービス系アプリ開発者

WebSocketにより、サーバとクライアント間で完全な非同期通信が可能になります。

つまり、デスクトップアプリのイベント駆動モデルとアプリケーション間通信モデルを、そのままインターネット越しのグローバルなイベント処理に拡張できるということ。

手元のiPhoneのセンサーで拾った情報（デバイスのイベント情報）を、インターネット越しに誰かのPCのブラウザ上に送る。そういうとんでもなくワクワクする世界が待っています。

今までこういうことをやろうとしたら、最低でも次のような仕組みが必要だったわけです。

スマホからサーバにイベントデータ（時刻付き）を送る
サーバにデータを蓄積する
ブラウザからJavaScriptで定期的にサーバに問い合わせる
受け取ったデータから時系列順にイベントを再構築する

それが、一発で、直接、ブラウザにデータを送り込めるようになったんです。これは楽しい。

このメリットを最大限に活用したWebサービスが遠からず出てくるでしょうね。

ゲーム開発者

これまでFlashとPHPを駆使して書いていたゲームが全部JavaScriptに置き換わります。

各ブラウザメーカの熾烈なJavaScriptエンジン高速化競争のおかげで、JavaScriptは今やマジでネイティブ並みの速度で動作します。

しかし描画に関してはCanvas APIしかなく、今のところグラフィックアクセラレーションは利用できないので、デスクトップゲームを置き換えられるかっていうと、それは無理です。

まだ、Flashゲームの置き換え用途です。ブラウザ上でDOOMが動いたときはホントにビビったけどね、あれは20年前のゲームだから。

業務アプリ開発者

WebForms、WebSocket、WebStorageなどの技術により、異常に便利になります。業務系のWebアプリ開発でこれまで苦しみ抜いてきた問題がすべて雲散霧消します。

「戻る」ボタン問題やセッション管理問題、クライアント側からのポーリング、クッキーを駆使したムリヤリストレージなどなどの諸問題がすべてきれいに消えてなくなります。

もしかするとHTML5で一番恩恵を受けるのは業務アプリ屋かもしれません。

しかし、業務アプリ業界というのは、良くも悪くも「最先端から２周遅れた」世界ですから、HTML5の恩恵を本当に受けられるようになるまではまだ少々かかります。

これから世界中であまたの大失敗例が山積みされるはずです。そうした死屍累々ののち、少数の成功例が生まれます。それがベストプラクティスとなり、ノウハウ化され、フレームワークとして教科書に載るようになり、それでようやく業務アプリエンジニアの世界に降りてきます。

Webデザイナ

HTML5というよりはCSS3ですかね。

JavaScriptが本格的なプラットフォーム言語化します。

Canvasで絵を描くのは、デザインではなく完全にプログラミング。そうすると、デザイナが片手間にJavaScriptを勉強してどうにかするのは、そろそろ手に負えなくなるでしょう。

ですから、CSS3で作れるようになった三角形や角丸矩形を使いまくったデザインが当面流行るんだろーなーと思います。

しかし、おそらく今後JavaScriptとCSS3を組み合わせたフレームワークが一大発展を遂げるはずで、そうなったあかつきには、再び「このコードを１行書けば一発でウィジェットを置ける」というような世界がやってくるでしょう。

そうしたフレームワークが整備されるまで何年かかかるでしょう。でも、きっと今より素晴らしい世界が待っているはずです。

まとめ

いかがでしたか。HTML5は、モバイル端末の今後の発展とあいまって、これまでのWebとは次元の違うユーザ体験を実現するはずです。なんとも楽しみですね。

2012年11月8日