HTML5

HTML5講座 第三講 ~HTMLの歴史とタダで使えるHTML5開発環境~

  • このエントリーをはてなブックマークに追加

by [2013年9月20日]

第二講ではHTML5をめぐるゲーム業界の動向と、HTML5のメリット、そしてHTML5の具体的な変更点などについて扱いました。第三項ではHTMLの歴史と、Webアプリとネイティブアプリの間に存在する相違と諸問題、そして無償で使えるHTML5の統合開発環境などについて扱います。

 第一講「HTML5の変更点とHTML5の意義」
 第二講「ゲーム業界のHTML5対応とHTML5の利点」

HTMLの昨日と今日、そして明日

ところで、HTTL5というからにはHTML 4(※これまでのHTMLのメジャーバージョン表記ではHTML 4とHTMLと数字の間に空白が挿入されていたのですが、5では空白を抜いたHTML5が正式表記となっています)以前にメジャーバージョンとしてHTML 3やHTML2 があった・・・と考えるのが普通でしょう。

しかし、実はHTML 3は諸事情により策定の途中で放棄されたので欠番になっていて、1993年のHTML 1.0からの大改訂は実質的にはこれまで2(1995年)と4(1997年)の2回しかありませんでした。そのため、今回の5が3番目の、そしてこれまでに無いほど大規模な、そして規格の性質すら変えてしまうような重要な改訂となります。

W3C 公式サイト
World Wide Webの生みの親であるティム・バーナーズ・リーによって創設された、各種Web技術の標準化団体。HTMLの最新仕様はこの団体によって勧告という形をとって公開される。

「なります」と言ったのは、実はこのHTML5、現段階では大まかな仕様をまとめた、いわゆるドラフト案の段階(※ただし、仕様策定そのものは昨年末の時点で完了したことが発表されています)で、Web技術の標準化・規格化を行っているW3C(World Wide Web Consortium)から勧告として正式な仕様が公開されるのが来年、つまり2014年となる見通しであるためです。

現行のHTML 4.01がW3Cから勧告されたのは、今を去ること14年前の1999年12月24日のことでしたから、順調に作業が進んで来年に勧告がなされるとすると、前バージョンから実に15年ぶりの新仕様勧告ということになります。

NeXT Computer NeXT Cube
スティーブ・ジョブズ率いるNeXT Computerが1988年に発表した伝説のワークステーション。右上から順にCube本体、17インチ「MegaPixel」モノクロディスプレイ、400dpiモノクロレーザープリンター、マウスおよびキーボードよりなり、特に初代CubeはHDDを搭載せず光磁気ディスクドライブを標準搭載し注目された。統一された印象的なエクステリアデザインはソニーのウォークマンIIなどで著名なフロッグ・デザインが担当している。
OSのNeXTSTEPはAdobeのDisplay POSTSCRIPTを標準グラフィックAPIとして搭載し、ジョブズが理想とした、ディスプレイ表示と印刷結果が一致するWYSIWYG(What You See Is What You Get)環境を実現する。また、当時最新のオブジェクト指向言語であったObjective-Cを開発言語として採用、Interface Builderと名付けられた、初心者でも簡単かつ直感的にアプリケーションを開発できる優れた開発環境を標準で提供していた。なお、このNeXTSTEPは現在のMac OS XおよびiOSの直系の祖先にあたる。

そもそもHTMLの原形となるアイデアがCERN(the European Organization for Nuclear Research:欧州原子核研究機構。ちなみに略称が正式名称の接頭語(この場合はEONR)になっていないのは、これが開設準備段階の組織名(フランス語のConseil Europeen pour la Recherche Nucleaire:欧州原子核研究協議会)に由来するためです)の研究者であったティム・バーナーズ=リーによって発案されたのが1989年、当時Appleを追い出されたスティーブ・ジョブズの創設したNeXT Computer(※後にAppleが買収)が手がけた「教育用」ワークステーション、NeXT Cube(※今のMac OS XやiOSの直系の先祖となるNeXTSTEP(OPENSTEP)という先進的なOSが動作していました)上で最初のHTMLに対応するWebブラウザとWebサーバが稼動したのが1990年ですから、そこから数えてHTML 4.01の発表までは約10年しかかかっていなかったことになります。

ティム・バーナーズ=リーらが作成した世界最初のWebサイト(※復刻版)
本当にテキストだけのプレーンな構成だったことが見て取れる。

その間、HTMLに関連する技術が全く発展しなかったかというとそんなことは当然なく、XMLとHTMLをすり合わせてXML言語の文法でHTMLを再定義したXHTML(Extensible HyperText Markup Language) 1.0が2000年にW3Cから勧告されるなど、HTMLの周辺ではどんどん新しい技術や規格が開発・制定されていったのですが、なまじ完成度が高かったことが祟ってか、また周辺技術に対する影響があまりに大きかったせいか、HTMLそのものを改訂する作業は長期にわたって遅滞状態となっていました。

もっとも、さすがに4.01の勧告から10年も経つ頃にはHTMLを取り巻く状況は一変しており、特にモバイル機器への適用では様々な問題が生じるようになっていました。

そこで時代に即した形で、単純にテキストだけでは無く動画・静止画・音声といったマルチメディアコンテンツを扱えるようにし、モバイル機器での利用に適した新機能の追加を行い、さらに既存の命令やタグなどの整理を行ったHTML5が制定されることになりました。

各社の特許が複雑に絡み合うマルチメディアコンテンツ関連技術については、各社の利害関係が錯綜して議論が紛糾し、事実上の議論放棄に等しい両論併記が見られるなど、幾つかの点で問題を抱えたままとなっているのですが、それでもHTML 4.01勧告から15周年となる2014年にこのHTML5が勧告される予定となっています。

そんな、いささか待ちくたびれ気味のHTML5ですが、ドラフト案の現時点でも、仕様そのものの策定は完了しているため、Internet ExplorerやChrome、Firefoxといった現行各Webブラウザでは最新バージョンでの対応が(現時点ではWebGLが完全に動作しないブラウザが大半を占めるなど、およそ完全とは言いがたい状況ですが)進んでおり、また既にほぼ仕様が確定している部分が大半を占めていることから、今からこれに対応するWebページやWebアプリを作成しても、今後特に大きな手戻りは発生しない(※互換性その他で問題の出た部分だけ修正が行われる)見通しとなっています。

Webアプリとネイティブアプリの違い

さて、今更なような気もするのですが、いわゆるWebアプリとネイティブアプリの本質的な相違点は、どこにあるのでしょうか?

一番大きな相違点は、Webアプリがスタンドアローンでの動作、つまりスマートフォンやパソコンなどのWebブラウザを搭載した各マシン単独での動作を、つまりネットワークに接続されていないオフライン状態での動作を基本的には想定していない、という点です。

一般に各端末側のWebブラウザ上で実行されるJavascriptなどで書かれたプログラムと、Webサーバ側で実行されるプログラムとが常時接続のインターネット回線を介してデータの授受を行いつつ連係して動作する、つまりWebアプリ(およびそれが動作しているWebブラウザ)とWebサーバの間で常に「打てば響く」関係が成立している、という考え方がWebアプリの根底にはあります。

実際、Webアプリの多くでは、ユーザーはWebサーバ上に作成されたユーザーアカウントにログインし、サーバ上に置かれたユーザーデータを操作・処理する、という形態を採っており、その動作にあたって、端末個々に保存されたローカルデータを直接利用することはありません(※これは、従来のHTML 4.01まででは、各マシンのローカルなディスク領域に保存されたデータを直接扱うための適切な手段(API)が提供されていなかったことが一因です)。そのため、サーバとの回線が切断されることの多いモバイル機器でこの種のWebアプリを動作させた場合、ネットワーク回線の切断によるデータ授受の停止でアプリそのものの動作が停止する、あるいは誤動作してしまうケースが少なからずあり、問題となっていました。

ネットワーク回線に依存しないスタンドアローンのネイティブアプリであれば、「インストール」という形でアプリの動作に必要なファイル一式を各端末のローカルストレージに保存するため、仮に回線が切断するとしても、基本的には回線に依存する機能やサービスの一時的な停止だけで片付くのですが、ローカルな環境にアプリを構成するプログラムファイル一式を持たず、随時実際に必要なファイルだけをダウンロードして実行するWebアプリの場合、実行中に回線が切断され、その後でダウンロードしていないファイルが必要となった場合、そのファイルが利用できないためにそこで停止してしまいます。そのため、Webアプリの場合、これまでは回線切断時のアプリの正常動作を保証できませんでした。

そこでHTML5ではこの問題について解決の道筋が用意されました。

WebStrageと呼ばれる、ローカルマシンのストレージにブラウザ上から直接アクセスするための機能が提供されているのです。

このWebStrageは現在の仕様では幾ばくかの問題が残っているのですが、Webアプリを構成するファイル群を一式ダウンロードしてローカルストレージにキャッシングしておくことでオフライン状態でもWebアプリがスタンドアローン動作できるように構成可能となりました。

無論、Webアプリの場合、サーバとの応答に依存する部分が少なくないため、単純に必要なファイルを全部ローカルストレージにキャッシングして蓄積しておけばそれで片が付くかと言えばそんなことはない(※一般的なWebアプリではWebブラウザ側の処理能力に期待せず、サーバに渡して処理させた結果が返ってこないことには先へ進められないようになっている処理が結構あります)のですが、それでも、回線品質が悪くこれまで安定的に動作しなかったような環境でのWebアプリの一定水準以上での安定動作が期待できるようになる、という点でこの技術の導入には大きな価値があります。

無料で使えるものが多い、HTML5対応ツール

ここまでHTML5の特徴についてあれこれ見てきましたが、その本質を知るには、やはり自分でこの規格に準拠したWebページを作成してみるのが一番です。

そこで、HTML5(およびCSS3)に対応する開発ツールをざっと見繕ってみると、無償で利用可能、という条件の下で本格的なアプリ開発のできるもの、という条件では以下の2つが挙げられます。

・Intel XDK
  (http://www.html5dev-software.intel.com/
   Google Chrome上で動作するHTML5アプリケーション開発ツール。要Java 6/7。
・Sencha Touch
  (http://www.sencha.com/products/touch
   HTML5対応ウェブアプリケーション開発用フレームワークSenchaの機能限定版。

なお、Googleも「Google Web Designer」としてHTML5対応の開発ツールを無償提供することを今年6月に予告しているのですが、これは現時点では未発表です。業界の巨人が投入するこの黒船の来航で、HTML5ベースのWebアプリを取り巻く開発事情が今後どのように変化するのか、興味が尽きません。

下心見え見えだがそれゆえに信用できるIntel XDK

Intel XDK公式サイト
Google Chrome上で動作するHTML5対応開発環境。スマートフォン用統合プロセッサ市場で後発ゆえに、IntelはARM系ではない自社製CPUへのアプリの対応が悪いことの対策として、このようなWebアプリ開発環境を無償提供している。これらは元々ppMobiが開発していたソフトで、それを手ごろなHTML5対応開発環境を欲していたIntelが買収したものである。

IntelがHTML5のアプリ開発環境を、それも無償で提供している、と言われて「へ?」と言いそうになった方も少なくないのでは無いでしょうか?

しかし、 このIntel XDKは確かに無償で提供されていて初回起動時には否応なしに巨大なIntelロゴを拝む羽目に陥ります。

CPU業界の巨人、IntelがHTML5開発環境をわざわざ無償で提供しているのは、身もふたもないことを言ってしまうと、現在のAndroid搭載スマートフォンの市場がほぼ完全にARM系プロセッサに独占されていて、アプリ開発(特にAndroid NDKを用いて開発されるネイティブアプリ)のエコシステムがARM系プロセッサ前提になっているため、自社のプロセッサに市場参入の余地がほとんどないためです。

そのため、CPUの種類に依存しないWebアプリの普及を積極的に促進し、CPUの機種に依存するAndroid NDK由来のネイティブアプリ(※Intelとしては大変に都合の悪いことに、主要かつキラーアプリと見なされるようなアプリほど、パフォーマンス向上を目的としてネイティブコードで書かれている率が高くなっています)を駆逐、あるいはWebアプリに転換させないことにはIntel製プロセッサを搭載した端末がスマートフォン市場で成功を収められる可能性はほぼ皆無と言ってよく、Intelはわざわざ他社から開発環境を買収してまでして、このIntel XDKを無償提供しています。

IntelのATOMプロセッサ搭載スマートフォン(イメージ)
IntelはARM系プロセッサと命令セットレベルで互換性のないx86/x64系プロセッサをスマートフォン市場へ押し込んで成功を収めるには、手段を選べない状況となっている。

つまり、自社製プロセッサの普及促進のため、というこれ以上無いほど強烈な下心ありありでの無償提供なのですが、ここまで思惑が露骨かつストレートですと、他に余計な思惑が入り込む余地もないため、むしろ逆に下手な有償開発環境よりも信用できてしまいます。

Intel XDK動作画面
仮想的に表示されているターゲットマシン(この場合はiPad)は右上の「DEVICE EMULATION」で自由に設定可能である。一つの開発環境でUltrabookもiPadもSurfaceも扱えるぞ、というこのターゲットマシン選択機能こそは、HTML5開発環境の最大のメリットを象徴するものであると言える。

特にIntelは自社の主力製品であるx86系プロセッサの成功経験から、開発者を味方につけることの重要性をよく知っており(※実はx86系プロセッサ用で最も高性能な商用C/C++コンパイラの開発元はIntelで、それが同社製プロセッサの普及に大きな役割を果たしてきました)、それ故にこのような開発環境の無償提供をおこなっているのです。

もっともこのIntel XDK、なかなか使いやすくよくできた開発環境なのですが、たった一つだけ欠点というか弱点があります。この環境、ドキュメントもダイアログも全部英語で、日本語化されていないのです。

この点が改善されたら筆者的には本当に一押しの開発環境なんですが・・・。

なお、前述のとおりこのIntel XDK自体がWebアプリとなっており、ユーザーはユーザー登録を行ってWebサーバ上の自分の開発環境にログインして利用する形態となっています。

商用ソフトのサブセットとしてのSencha Touch

Sencha Touchは商用HTML5対応ウェブアプリ開発用フレームワークであるSenchaのサブセットです。

これはグラフィカルなユーザーインターフェイスを構築するためのJavascriptのライブラリ集とフレームワーク本体より構成され、「Touch」とわざわざ銘打たれていることが示すように、このソフトはスマートフォン向けWebアプリ開発に最適化・特化・機能限定した仕様となっています。

なお、これはIntel XDKとは異なりWindowsのネイティブアプリとなっており、利用開始前にはインストール作業を行っておく必要があります。

元々商用ソフトとしての実績のあるソフトのサブセット・無償提供版だけに相応に機能は充実していますが、それだけに高度な機能を備えたフレームワークそのものの独自の階層構造などについて十分な理解が求められる部分があって、無償だからと甘く見ていると手も足も出ない、という結果になる恐れがあります。

そのため、このソフトを用いて初心者でも楽々HTML5対応アプリ作成を、というのはなかなか難しいでしょう。

言い換えれば、そのくらい複雑かつ高度な機能を備えたソフトであればこそ、開発者の教育推進とSencha本体の普及促進を目的として、機能限定版とはいえ高度な機能を保ったままのこのソフトを無償利用可能としている/せねばならないのだ、と解することができます。

つまり、何も知らない開発者に「Senchaはこうやって使うんだ」ということを学習してもらい、商用版の普及を図ることが目的での無償提供、ということになります。

Intel XDKもそうですが、この手の高機能かつプロプライエタリなソフトウェアを営利企業が無償提供するからには、相応の思惑があるものと考えるのが自然です。

Intelが自社製プロセッサの販売拡大を目的としているなら、こちらは自社製商用版開発環境のユーザー数を増やすことが目的なのです。つまり、どちらもタダであることには提供元の方にちゃんとした理由がある訳で、そのため、作成したアプリに胡散臭い広告表示が強制されるようなことはありません。

HTML5がオワコンだなんて誰が言った?

以上、HTML5の変更点やメリット、開発環境などについて見てきましたが、海外での状況をウォッチする限りは、HTML5を終わった技術同然に吹聴するFlash支持者の主張とは裏腹に、HTML5とその応用技術の開発は、急速に進展しています。

W3Cが公開している現時点で最新のHTML5.1 ワーキングドラフト案
HTML5の勧告もまだなのに、いささか気が早いような気もするが既に昨年12月よりドラフト案の議論が始まっている。

実を言うと、HTML5の勧告も行われていない現状にもかかわらず、早くもHTML5.1のドラフト案(第一次草案)も飛び出すような状況(※規格制定の作業パターンとしては正しいのですが、これまでの仕様的な停滞を考えると、W3Cにいったい何があったのか、と疑いたくなるようなハイペースぶりです)で、そのHTML5.1は2016年にW3Cが勧告を出す、という予定になっています。

言い換えれば、今回のHTML5には急いで次バージョンの勧告を用意しなくてはならない程度には意見の分かれる部分があった、ということなのですが、自前でWebページを作成する身としては、おかしな方向性で仕様策定が行われないよう、W3Cの方を向いて五体投地でもして祈るよりほかありません。

もっとも、W3Cが公表しているドラフト案の文書を読む限りは、これはHTML5のマイナーバージョンアップ、つまり大筋ではHTML5で定められたことの枠から外れるものではない、とあるため、仮に今HTML5でWebページやWebアプリなどを作成したとしても、HTML5.1の勧告で致命的な手戻りが発生することはなさそうです。

このような状況ですので、今後Flash技術が再び天下を取ってスマートフォンのWebブラウザに搭載される、というシナリオは考えがたく、今なおFlashマンセーを叫んでいるWebデザイナー諸氏もいいかげんHTML5(およびその関連拡張技術)の勉強に手を付けた方がよろしいような不穏な空気が漂っています。

でないと、折角ガラケー時代に我が世の春を謳歌していたのに、スマートフォンの黎明期に「スマホ? 興味ないね」とうそぶいて開発競争に出遅れ、挙げ句ツートップに選ばれずに惨敗して撤退、などという無様なこと極まりない状況に陥った某N社みたいになってしまいますよ? 多分。

コメントは受け付けていません。

タグ:
PageTopへ