HTML5
次世代のWeb標準技術
第1部 HTML5とは
狭義のHTML5
W3Cの以下の仕様で定義されているものを指す。
HTML5 A vocabulary and associated APIs for HTML and XHTML http://www.w3.org/TR/html5/
- この仕様には主に以下が規定されている。
- HTML5のすべての要素
- HTML5におけるHTML
- HTML5におけるXHTML
- Drag and Drop APやApplication cacheなどAPI など。
広義のHTML5
HTML5と関連APIの複数の仕様の総称。
HTML5にいたるまで(その1)
- 1989 Tim Berners-Lee、World Wide Webの元となる構想を提案。
- 1990 Tim Berners-LeeによってHTML、HTTPサーバ、ブラウザが開発される。
- 1993 HTML1.0 IETF Internet Draft
- 1994 W3C成立
- 1997 HTML4.0 W3C勧告
- 1998 XML1.0 W3C勧告
- 1999 HTML4.01 W3C勧告
→W3CはHTMLの開発は一旦終了。 XMLを指向する。
HTML5にいたるまで(その2)
HTML5の仕様とWHATWGの仕様
WHATWGの仕様と重なる部分が多い
HTML4→XHTML→HTML5
- 〜HTML4 Web of Document
ドキュメントの共有。基本的に人間が読むもの。 - XHTML Web of Data
機械処理が可能なXML+人間にとっての可読性のあるHTML - XHTMLはver1.1が普及せず。にも関わらず、ver.2.0はこれまでのHTML/XHTMLの互換性を持たない、全くの別物として検討が開始。
- HTML5 Web as Application、そして、Web as Platform
HTML5 要点
- Web as Application、そして、Web as Platform
- 理想の追求より現実と向き合う。
- ブラウザ間の相互互換性の確保。
- 後方互換性の確保
- よりセマンティックに、よりアクセシブルに
- これまで各ブラウザが独自に実装していたAPIなどの標準化。
HTMLとXHTML in HTML5
- HTML5はHTML形式だけではなく、XML形式でも仕様できる。
- 要素や属性はDOMによって定義→DOM5 HTML。
- HTMLの文法でシリアライズ→HTML5
"8 The HTML syntax" (HTML5仕様) - XHTMLの文法でシリアライズ→XHTML5
"9 The XHTML syntax" (HTML5仕様)
- HTMLの文法でシリアライズ→HTML5
HTML5 in HTML5
- 文書型宣言
<!DOCTYPE html>
- MIMEタイプ
「text/html」 - 文字エンコーディング
<meta charset="UTF-8">
以下のような従来の指定方法も可。
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- 文法
HTMLの記述方式。XMLの記述方式も可。 - "8 The HTML syntax"(HTML5仕様)
XHTML5 in HTML5
- 文書型宣言
<!DOCTYPE html>
- MIMEタイプ
「application/xhtml+xml」 - 文字エンコーディング
<xml version="1.0" encoding="UTF-8"?>
- 名前空間
<html xmlns="http://www.w3.org/1999/xhtml">
- 文法
XMLの記述方式に準じる - "9 The XHTML syntax"(HTML5仕様)
ではいつ使えるのかという話。
HTML5のすべての仕様を実装したブラウザはまだ存在しません。
Why?
- 狭義のHTML5の仕様がようやく最終草案。他の仕様もまだまだ草案段階の仕様が多い。
- 「HTML5」でくくられる仕様が増えて増えて膨大な数に・・・。
参考 W3C勧告までのプロセス
- 草案(Working Draft)
- 最終草案(Last Call Working Draft)
- 勧告候補(Candidate Recommendation)
- 勧告案(Proposed Recommendation)
- W3C勧告(Recommendation)
前述の仕様(2011/12/10時点)
- 草案(Working Draft)
- Indexed Database API
- Server-Sent Events
一度最終草案として公開されたが、2011年10月に草案に差し戻し
- 最終草案(Last Call Working Draft)
- 勧告候補(Candidate Recommendation)
- 勧告案(Proposed Recommendation)
- W3C勧告(Recommendation)
つまり・・・・
フルスペックHTML5を実装したブラウザはしばらく登場しない。
とはいえ・・・
もう使えます。というか、すでに使ってます。
W3Cの仕様
- フォーラム標準。法的拘束力はなし。採用・実装をブラウザベンダに強制できない。
- 実装主義。ブラウザベンダに実装されたものが最終的に仕様として採用される。
- 仕様によっては草案の段階からブラウザに実装されてきている。
It already works!
- 最新の主要ブラウザである程度実装が進んでいる
- ただし、ブラウザによって実装の進行が異なる。
- スマホのブラウザはレンダリングエンジンがWebkitにほぼ限定されているため※、PC版のブラウザよりも差異が少ない。
- Flashが使えないということもあり、スマートフォン向けサイトはHTML5に対応させたサイトが非常に多い。
※Windows Phoneはよくわかりません。でもしてそう。
ブラウザの実装状況
第2部 マークアップ よりセマンティックに-
セクション要素
セクション要素
こんな構造のサイトがあった場合・・
ヘッダー | ||
ナビゲーション | ||
メニュー | コンテンツ | メニュー |
広告 | ||
フッター |
セクション要素
従来はこんな感じで
div id ="header" | ||
div id ="navgation" | ||
div id ="menu_left" | div id ="contents" | div id ="menu_right" |
div id ="ad" | ||
div id ="footer" |
セクション要素
HTML5ではこんな感じになります。
header | ||
nav id ="top" | ||
nav id="left" | article | nav id="right" |
aside id="ad" | ||
footer |
はてなブログ
11月に公開されたはてなブログがHTML5対応
セクション要素解説(1)
ブロックに意味をもたせることができるようになった。
- header/footer
- それぞれページ単位、セクション単位のヘッダーとフッターを意味する。
- nav
- ナビゲーションを意味する。位置は問題ではないので、サイドにナビゲーションをもつものがあってもasideではなく、navを使用する。
- aside
- メインコンテンツと関連の薄いブロックを意味する。広告やリンクなど。位置は問題ではないのでサイドにあるから使うというものではない。
セクション要素解説(2)
- article
- 独立したコンテンツを表す。
- section
- 章節単位をあらわす。見出しと本文をくくる要素。つまり、h要素の見出しが必要。
- div
- 表す意味を持たない。スタイルのためだけに使うならこの要素を使う。
テキストの意味付け
テキストに対する意味付けをする要素が整理された。
- em要素(変更なし)
- 強調を表す。重要性は表さない。
- strong要素(変更)
- 強調を表す要素から重要性を表す要素に変更された。
- i要素(変更)
- 印刷物で慣例的にイタリック体で表現されるものに使用する。
- b要素(変更)
- 他のテキストと区別させたいときに使用する。強調や重要性を表さない。
- small要素(変更)
- side comments()を表す。フォントを小さくするために使用しない。
- mark要素(新要素)
- 特定の範囲をハイライト。他の箇所で明示的もしくは暗黙的に言及されることを期待される箇所。
メタデータ
メタデータの埋め込み
- HTMLの要素だけでは文書構造に意味を持たせることができても、個々のテキストに意味をもたせることができない。
- 個々のテキストに意味を持たせるためにHTML文書内にメタデータを埋め込む仕様がいくつか存在する。
Microdata、RDFa、Microformatsなど。 - 現在は検索エンジンのリッチスニペットなどに活用されている。
Microdata
HTML5で導入されたHTML内にメタデータを記述するメタデータフォーマット。以下のような感じでhtmlタグの中にitemscope、itemtype、itempropという属性を埋め込んでメタデータを記述する。
<section itemscope itemtype="http://data-vocabulary.org/Person"> Hello, my name is <span itemprop="name">John Doe</span>, I am a <span itemprop="title">graduate research assistant</span> at the <span itemprop="affiliation">University of Dreams</span>. My friends call me <span itemprop="nickname">Johnny</span>. You can visit my homepage at <a href="http://www.JohnnyD.com" itemprop="url">www.JohnnyD.com</a>. <section itemprop="address" itemscope itemtype="http://data-vocabulary.org/Address"> I live at <span itemprop="street-address">1234 Peach Drive</span> <span itemprop="locality">Warner Robins</span> , <span itemprop="region">Georgia</span>. </section> </section>
RDFa
RDFをHTML内に記述するメタデータフォーマット。RDFaでは記述が複雑すぎる?という意見からRDFa1.1 liteなるものも出た。
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:biblio="http://example.org/" xmlns:dc="http://purl.org/dc/elements/1.1/" > <head> <title>Books by Marco Pierre White</title> </head> <body> I think White's book '<span about="urn:ISBN:0091808189" typeof="biblio:book" property="dc:title"> Canteen Cuisine </span>' is well worth getting since although it's quite advanced stuff, he makes it pretty easy to follow. You might also like <span about="urn:ISBN:1596913614" typeof="biblio:book" property="dc:description"> White's autobiography </span>. </body> </html>
Schema.org
Schema.org
http://schema.org/ (非公式日本語訳)
- Google、Yahoo!、Microsoftの3社によるメタデータの記述を共通化する試み。
- Microdataによる語彙集。
- 現在はW3C(Semantic Web Interest Group)に検討の場が移った。RDFaの対応も視野。
その他
form機能の強化
- input要素のtypeコンテンツ属性の追加。
<input type="この部分">
search, tel, datetime, range, colorなど 例 - input要素の共通コンテンツ属性の追加
autocomple, list,required,pattern,autofocusなど - 新要素
keygen, output, progress, meterなど
ルビ表示が可能に
- ruby要素、rt要素、rp要素が追加され、ルビの表示が可能になった。
プログラミング言語研究会
プログラミング<ruby>言語<rp>(</rp><rt>げんご</rt><rp>)</rp>研究会<rp>(</rp><rt>けんきゅうかい</rt><rp>)</rp></ruby>
- アクセシビティの強化。
- 現在、IEとSafari、Chromeが対応。→ブラウザの対応状況
マルチメディア要素
video要素、audio要素、canvas要素の追加。
詳細は第3部で。
その他
- 新要素
time, - 新属性
contextmenu, contenteditable - 意味の変更された要素
HTML5タグリファレンス
あとは・・・
これを読んでください。HTML5で使用できる全要素・全属性の解説が掲載されています。
と書いている時に・・・
新しいのが出ました。
第3部 強化されるマルチメディア機能
video/audioタグ
video要素
- 動画ファイルをvideo要素で参照できる。
<video src="http://cdn-smooth.ms-studiosmedia.com/events/W3C/Day1/Web_Payments.mp4" controls="controls" width="300px" ></video>
>
from W3Conf: Practical Standards for Web Professionals
audio要素
- 音声ファイルをaudio要素で参照できる。
<audio src="http://www.hmix.net/music/n/n46.mp3" controls="controls"></audio>
from MP3フリー音楽素材・効果音
ブラウザのvideoファイル形式の対応
ただし、ブラウザによって対応する動画ファイルがばらばら。主要ブラウザ全てが対応している共通の形式がまだ存在せず。
ブラウザのaudioファイル形式の対応
ただし、ブラウザによって対応する音声ファイルがばらばら。主要ブラウザ全てが対応している共通の形式がまだ存在せず。
対策
複数の形式のデータを用意する。そして、source要素を使用する。
<video controls="controls" width="300px"> <source src="http://cdn-smooth.ms-studiosmedia.com/events/W3C/Day1/Web_Payments.mp4" type="video" /> <source src="http://cdn-smooth.ms-studiosmedia.com/events/W3C/Day1/Web_Payments_1200k.webm" type="video" /> </video>
source要素は複数のメディアファイルを指定できる。上から順番にチェックされ、最初に再生可能な形式が再生される。
Canvas
Canvas(2D)
- JavaScriptでcanvas要素内に描画する。
- ビットマップ形式。
- 動的に描画できるので、Flashの代替になる(かもしれない)。
- 後で述べるSVGと比べると描画が高速。
- ほとんどのブラウザが対応している。
※ただし、IEはIE9以降。
Canvas(2D)
<canvas id="myCanvas" width="600" height="400"></canvas> <script> var canvasObj = document.getElementById("myCanvas"); var my_canvas=canvasObj.getContext("2d"); my_canvas.fillStyle="red"; my_canvas.beginPath(); my_canvas.moveTo(10,10); my_canvas.lineTo(300,10); my_canvas.lineTo(150,400); my_canvas.closePath(); my_canvas.fill(); my_canvas.fillStyle="green"; my_canvas.beginPath(); my_canvas.moveTo(10,10); my_canvas.lineTo(10,300); my_canvas.lineTo(100,50); my_canvas.closePath(); my_canvas.fill(); my_canvas.moveTo(100,100); my_canvas.fillStyle="blue"; my_canvas.arc(200,100,100,0,Math.PI*2,false); my_canvas.fill(); my_canvas.stroke(); </script>
Canvas
Canvas(2D) -Use Cases
WebGL - Canvas 3D
- 3Dのグラフィックスをcanvas要素に描く標準仕様。
- 仕様は非営利団体のKhronos Groupが管理。
- PS3や任天堂の3DSなどで採用されているオープンな仕様であるOpenGL ESがベースとなっている。
- 仕様 → WebGL - 3D Canvas graphics
- Firefox、Chromeで実装が進んでいる。
- JavaScriptのライブラリでCanvas 2DとWebGLに対応したThree.jsというものもある。
WebGL -Use Cases
SVG(Scalable Vector Graphics)
SVG(Scalable Vector Graphics)
- XMLで記述するベクター形式の2Dグラフィックスの記述言語。画像形式も意味する(拡張子はsvg)
- ベクター形式なので拡大しても画像が劣化しない。画像内テキストの処理やコピペも可能。
- DOMを構成するので描画後にJavaScriptからオブジェクトとして認識することが可能。
- svgはバイナリファイルではなく、テキストファイル。
- SVGはCanvasに比べると描画がかなり重いが再現性は高いということのようです。
SVG -ブラウザの対応状況
SVG -img要素による表示
- 以下のようにimg要素によってHTML内に表示するだけなら可能。最新のブラウザなら対応している。
<img width="700" height="450" src="http://people.opera.com/danield/svg/inbox-attack.svg"/>
- 上のsvgファイルを単独でブラウザで表示させると・・・ http://people.opera.com/danield/svg/inbox-attack.svg
SVG Use Cases - SVG少女
- IE9のプロモーションとして作られたSVGアニメーション。
- 1秒間に10コマのSVGを描画させている。
SVG少女
http://jsdo.it/event/svggirl
参考: SVG女子を90%軽くしたSVG軽量化テク+α | KAYAC DESIGNER'S BLOG
SVG Use Cases-電子コミック
- テキストデータとしてデータを保持するのでテキストを他の言語に置き換えることができる。一つのファイルで多言語版を展開できる。
- マルチデバイス対応。様々なスクリーンサイズのデバイスに1つのファイルで対応できる。
- SVGに対応したEPUB3での利用されるかもしれない。 デモ from EPUB 第3回 成果報告会
第4部 JavaScriptでマルチスレッド処理-Web Workers
Web Workers
Web Workersとは
- JavaScriptをバックグランドで動作させるAPI。
- UIと切り離した処理が可能になるため、長時間の処理が必要なプログラムをUIに影響を与えずに実行することができる。
Web Workersの特徴 (1)
- ワーカースレッドはDOMにアクセスできない。
WebWorkersの特徴
- 複数のワーカースレッドをつくることができる。
ワーカーのワーカー
- ワーカーの中でワーカーを使用することができる。
共有ワーカー(Shared worker)
- 複数のワーカーオブジェクト間で同じワーカーを共有することができる。(shared workder)。
ちなみに・・
専用ワーカーと共有ワーカーでコントラクタが異なる。
- 専用ワーカー(dedicated worker)
var worker = new Worker('sample.js')
- 共有ワーカー(shared worker)
var worker_shared = new SharedWorker('sample_shared.js')
Use Cases
現在、以下のAPIをWorkerスレッド内で使用することができる。
- WebSocket API
- Web SQL DB API
- XMLHttpRequest 遠からず他のAPIでも。
第5部 リアルタイム双方向通信 - WebSocket
WebSocket
WebSocketとは
- Web上で双方向のリアルタイム通信を実現するしくみ。
- リアルタイム通信が求められるものに活用が期待できる。
- チャット
- オンラインゲーム
- 共同作業
- 「ソーシャル〜」がつくいろいろ。
- 「ライブ〜」がつくいろいろ。
Web上での双方向リアルタイム通信い?
Web上のやり取りはサーバーを介して行います。チャットの場合はこんな感じ。
- クライアントA「Bさん、おはよー」
- サーバー「Bさん、AさんがBさんに「Bさん、おはよー」っていってます。」
- クライアントB「Aさん、もう出勤?早いね。」
- サーバー「「Aさん、BさんがAさんに「Aさん、もう出勤?早いね」っていってます。」
WebSocketはこのハイライトされた部分を実現するしくみ。
Webサーバー(HTTPサーバー)
- リクエスト&レスポンス型。
- クライント側のリクエストがあって初めてサーバー側から情報が送信されるPULL型通信。
- リクエスト及びレスポンスの度にHTTPヘッダがクライアント.サーバーの双方から送信される。
Webサーバー(HTTPサーバー)
- 基本的にクライアント側の要求ありきなので、サーバー側からクライアント側に任意のタイミングで自動的に情報を送ることができない。つまり、PUSH型通信ができない。
- リアルタイムな双方向通信を実現するためには一工夫が必要。
双方向通信を行うために
- クライアント側から定期的にリクエストを送信する。
- Comet(long-polling)
定期的なリクエストの送信
クライアント側から定期的にリクエストを送信するとこんな感じです。
- クライアントA「Bさんから新しいのきた?」
- サーバー「きてません。」
(一分後) - クライアントA「Bさんから新しいのきた?」
- サーバー「きてません。」
- クライアントB「おはよー。」
(一分後) - クライアントA「Bさんから新しいのきた?」
- サーバー「Bさんから「おはよー」っていうメッセージが届いています。」
定期的なリクエストの送信の問題点
- タイムラグの発生(リアルタイムではない)。
- 不要なコネクションの生成。
- リクエストとレスポンスの度に送信されるHTTPヘッダの量も無視できない。
Comet(Long-polling)
クライアントからリクエストがあってもサーバー側はすぐにレスポンスを返さず、コネクションを維持する。なんらかのイベントが発生したタイミングでサーバーはレスポンスを返す。
Comet(Long Polling)の問題点
- コネクションを長時間占有するため、同じサーバーに接続する他のアプリケーションの挙動に影響を与える可能性がある。
- 一度コネクションが切断されたら、再度クライアント側からリクエストを送信しなければならない問題は変わらない。
- チャットのようなリアルタイム双方向の通信であれば、頻繁にコネクションの確立と切断が発生する問題は変わらない。
- HTTPヘッダの量も無視できない。
そこで、WebSocket
WebSocket
- ブラウザとサーバー間で双方向のリアルタイム通信を可能とする仕組み。
- 送信と受信を同時に行うことができる。
- コネクションをHTTPプロトコルでつなぎ、WebSocket専用のプロトコルに切り替えてコネクションを維持。
- HTTPプロトコルでコネクションを維持するよりもWebSocketプロトコルのほうがオーバーヘッドが少ない。
- サーバー側の実装も必要。
- クライアント側のAPIの仕様をW3Cで、サーバー側で実装するプロトコルの仕様をIETFで検討。
PUSH型通信が可能です。
双方向通信なので
チャットならばこういうほうがあり得る。
ライブ配信
もちろんAからBへサーバーを経由して一方的に送信し続けることも可能。
複数同時送信
HTTPのようにRequestとResponseを1対1でやり取りする必要はない。同時に複数送信、複数受信することによって効率よくデータをサーバーから受け取ることができる。
余談
今回はリアルタイム双方向通信に主眼をおいたため、主にWebSocketを紹介しましたが、HTML5関連のAPIではそれ以外にも次のようなAPIが検討されています
その他のコミュニケーション系API
- Web Messaging
- XML HTTP Request Level2
- Server-Sent Events
第6部 Web as Application -オフライン系API
Web Storage
Web Storageとは
- クライアントサイドでデータを持つことができるストレージ
- シンプルなkey-value型データベース
- 対応するブラウザが多い。
- 以下の2つに分けられる。
- localStorage
originごとに保有できる永続性のあるストレージ。 - sessionStorage
セッションごとに保有されるストレージ。ブラウザを閉じると削除される。
- localStorage
Cookieとの違い
- サーバーに送信されない。
→トラフィックの軽減。セキュリティの向上。 - Cookieより大きいサイズのデータを保有できる。
- web Storage : 仕様上、上限はとくに定められていないが、originごとに5 MBの任意リミットを推奨。ブラウザの実装では5MB〜10MBぐらいらしい。
- Cookie: 1クッキー4KBまで。
Web SQL Database
Web SQL Databaseとは
- クライアントサイドで動作するリレーショナルデータベース。
- SQLを用いた柔軟なデータアクセスが可能。
- SQlite
しかし・・・・
Web SQL Databaseの仕様の検討は中止
現時点ではまだ対応しているブラウザがいくつかあるので使えることは使えます。
Indexed Database
Indexed Database
- key-value型NoSQLデータベース
- 検索機能の強化・トランザクション機能
- データの格納はテーブルの代わりに「オブジェクトストア」と呼ばれるオブジェクトで行う。
- オブジェクトストアに格納されたオブジェクトのプロパティのインデックスを生成することができる。
- スキーマをあらかじめ定義する必要がないため、柔軟なデータ操作が可能。
- 最初に仕様の草案が公開されて(2010年1月)あまり日が経っていないため、ChromeやSafari以外のブラウザはまだサポートしていない。
Appllication Cahce
Appllication Cahceとは
- Webサイトをローカルに保存することでオフライン時にWebサイトを見ることができる仕組み。
- マニフェストファイル(拡張子はappcahce)というファイルにオフライン時に必要なファイルを記述して指定する。
- マニフェストファイルに記述されたファイルは自動的にローカルにダウンロードされる。
- ネットワーク環境が充分でない環境下で利用されるモバイルサイトなどに有用。
File API
File APIとは
- 外部ファイルをJavaScriptで扱うためのAPI。
- サーバーを経由せずローカルでWebアプリケーションがファイルを扱うことができる。
- 以下の仕様が検討されている。
- File API
外部ファイルをWebアプリケーションからアクセスすることができるようにするAPI。 - File API: Directories and System
仮想のファイルシステムを構築し、ディレクトリを扱う事ができるようにするAPI。 - File API: Writer
Webアプリケーションから外部ファイルにデータを書き込むことができるようにするAPI。
- File API
- Drag & Drop APIとの連携。
Use cases
- Gmail
- Kindle Cloud Reader などなど。
スマホ向けのサイトならすでにたくさんある。
Kindle Cloud Reader
- 利用するには?
Amazon.comのアカウントを取得して対応するブラウザで以下のURLにアクセスするだけ。
https://read.amazon.com - コンテンツをローカルダウンロードすることができる(50MBまで)のでオフライン環境でも電子書籍が読める。
Kindle Cloud Reader
一覧画面
Kindle Cloud Reader
コンテンツの本文表示画面
Kindle Cloud Reader
ブックマークしたり・・・
Kindle Cloud Reader
ブックマークやノートつけたところを確認したりできる。
大事なことなので繰り返しますが・・・・
Kindle Cloud Reader利用するには?
- Amazon.comのアカウントを取得して対応するブラウザで以下のURLにアクセスするだけ。
https://read.amazon.com - こんなアプリケーションライクなサイトが今後どんどん出てくる。Twitterとかfacebookとか・・
Kindle Cloud Reader対応ブラウザ
- Google Chrome 11 and higher on Linux, MacOS X, and Windows.
- Mozilla Firefox 6 and higher on Linux, MacOS X, and Windows.
- Safari 5 and higher on MacOS X and Windows.
- Safari on iPad with iOS 4.2 and Higher
第7部 さらなるWeb as Application-Web app.とNative app.
Native app. vs Web app.
Native app.
長所
- ハードウェアの機能をフルに使用することができる。
- 処理速度
- カメラ、センサーなどハードウェア特有の機能
- 扱えるファイルの制約が少ない。
- App Storeなどのプラットフォームに載せることができるので有料化も可能。
Native app.
短所
- プラットフォームごとの開発が求められる。
- Objective-C(iOS)
- Java(Android)
- C#/VB.NET(Windows Phone)
- プラットフォーム運営者の意向、方針に左右される。
Web app.
長所
- クロスデバイス、クロスプラットフォームなアプリケーションの開発が可能。
- オープンな仕様(HTML+CSS+JavaScrip)で開発することが可能。
- HTML+CSS+JavaScripなので開発も比較的容易ですね。
Web app.
短所
- ハードウェアのネィティブ機能を操作できない。
- 処理速度
- 現時点では扱えるファイル形式やファイルサイズに制限がある。
Web app.のNaitive app.化
PhoneGap
- HTML+CSS+JavaScriptで開発したアプリケーションをネイティブアプリケーション化するフレームワーク。
- 様々なプラットフォームに対応。
- App Storeなどのプラットフォームでの販売が可能。
- ちなみにPhoneGapの開発会社(Nitobi)を2011年10月にAdobeが買収。
- と同時にPhoneGapがApacheソフトウェア財団に寄贈とのニュース。
PhoneGap http://phonegap.com/
PhoneGapの特徴
- 基本的にHTML+CSS+JavaScriptで開発したWebアプリケーションをパッケージ化したもの。
- 処理速度もWebアプリケーションと変わらない。
- ネィティブ機能へアクセスする様々なAPIを提供する。
- Webアプリケーションではアクセスできなかったカメラなどのハードウェア特有の機能にアクセスすることが可能。
少しHTML5の文脈から外れるかも知れませんが・・・
ObjC/Javaを使わなくてクロスプラットフォームはアプリを作れるものが結構あります。
クロスプラットフォームなアプリを作れる開発環境
Titanium Mobile
- UIを含めてJavaScriptで作成する。
- JSインタプリタで動作
- オープンソース。
- マルチプラットフォーム対応が容易。
- アプリ数 30,000+
- Aptanaという企業を最近、買収して、Titamium Studioという開発環境を提供。
Titanium Mobileの特徴
- だいたいのことはできる。様々なAPI。写真撮影、コンパス、SQLite・・・
- ただし、画像処理系のAPIが標準で備わっていない。
- リアルタイム性を要求されるものも苦手
- ただし、ObJC/Javaで機能を拡張できるModuleがある。
Use Cases
閑話休題
Webアプリはハードウェア特有の機能にアクセスできないと申しましたが・・・
Device系API
Geolocation API
- GPSやWiFi、携帯電話の基地局などから置情報を取得することができるAPI。
- 現在地の経度や緯度、高度を取得することができる。
- すでにW3C勧告候補。仕様として安定している。
- ちなみにGPS以外はブラウザが採用しているWiFiや携帯電話基地局のデータベースから情報を取得する。使用されるデータベースはブラウザによって異なる。
さらに・・・・・
検討中のハードウェアの機能を操作するAPI
Geolocation API以外にもハードウェアの機能を操作するAPIの仕様が検討されている。
- Battery Status Events(Last Call)
- Contacts API(reading from addressbook)(Last Call)
- WebRTC 1.0(Public Working draft)
- HTML Media Capture(Public Working draft)
- The Messaging API(SMS, MMS, emails)(Public Working draft)
- The Network Information API(Public Working draft)
- Sensor API(Editor’s Draft)
- Vibration API(Public Working draft)
- Calendar API(Public Working draft)
- Feature Permissions(Editor’s Draft)
- Media Capture API(Public Working draft)
- Permissions for Device API Access(Public Working draft) など
前述の・・・・・
オフライン系のAPI
あわせてオフライン系のAPIを併用すれば、ローカルだけで簡潔するアプリケーションを作ることも遠からず可能になる。
- File API
- Indexed Database
- Draog & Drop API など
第8部 CSS3
CSS3とは
- 現行?のCSS2.1(CSS Level 2 Revision 1)の次のバージョンとして検討されているCSS。
- CSS3では仕様が各機能ごとに分割してモジュール化。
- 分割された仕様はそれぞれで仕様が策定が進められている。
- 現在、50弱の仕様が検討されている。
- モジュール一覧 →CSS current work
CSS3とは
CSS3の特徴
- セレクタの追加
- 角丸
- グラデーション
- トランスフォーム(拡大・回転・ゆがみ)
- アニメーション
- Webフォント
- 縦書き、禁則処理等の日本語組版の表示が可能に。
- これまでFlashやJavaScriptに頼らざるを得なかったデザインをスタイルシートの設定だけでできるようになる。
Use Cases
Use Cases -縦書き表示とか
from EPUB漢詩選
- EPUB3の縦書き表示などに活用されている。
- 横書き(に向いたコンテンツ)に制限されていた日本語Web上に縦書きに向いたコンテンツが増えていくことが今後期待できる
第9部 HTML5の今後
WebサイトとWebアプリ/パッケージ型コンテンツの境界線の曖昧化
- モバイル版のサイトのUIと機能をネィティブアプリに可能な限り近づけたサイトも出てきている。
- facebook(モバイルサイト版とアプリ版)
- twitter(モバイルサイト版とアプリ版)
- iPLAYBOYのようにPC版では通常のWebサイト、iPadでは電子雑誌的UIのようなサイトも。
- インストールを必要としないアプリケーションライクなWebサイトが今後増えてくる。
さらなるPlatform志向?
- Web Payments
巨大なブラットフォームに依存しない形でのWeb上のお金のやり取りのオープンな仕様化が可能かどうか検討され始めている。
用途の拡大
- Web and TV(Webと放送の融合?)
- 電子書籍--HTML5とCSS3を採用
ありがとうございました。
参考文献
主な参考サイト
- HTML5.JP - 次世代HTML標準 HTML5情報サイト
http://www.html5.jp/
主な参考書籍
- 『徹底解説HTML5』シリーズ(秀和システム)
現在、「マークアップガイドブック編」、「APIガイドブック ビジュアル系API編」、「APIガイドブック コミュニケーション系API編」、「APIガイドブック オフライン系API編」が出ている。
日本語でもっとも詳細で網羅的な解説。 - 『HTML5&API入門』(白石俊平著、日経BP社、2010/2)