カテゴリー: W3C

パッケージ化されたHTML5電子書籍 – HTML5電子書籍(1) –

kzakza

　EPUB3の仕様が2011年10月に確定してから3ヶ月ほど経過して、作成ツールやEPUB3リーダーなどがちらほらと現れてきています。ちなみにEPUB3ビューアーについては、以下にすこしまとめた一覧がありますので、参考までに。
・ブラウザ・ビュアー – epubcafé
　
　しかし、あえて今回はEPUB3ではなく、HTML5電子書籍について、2回にわけて書いてみたいと思います。
　と・・・いいつつも、まずはEPUBの話から始めます。　
　　

1. EPUB3でインタラクティブな電子書籍

　EPUB2ではJavaScript自体を「実行するべきではない」とされていましたが、EPUB3になって、JavaScriptの利用が可能になりました。これによって動的でインタラクティブな電子書籍が作成できるようになります。　
　

2.4 Scripted Content Documents
EPUB Content Documents may contain scripting using the facilities defined for this in the respective underlying specifications ([HTML5] and [SVG]). When an EPUB Content Document contains scripting, it is referred to in this specification and its sibling specifications as a Scripted Content Document. This label also applies to XHTML Content Documents when they contain instances of HTML5 forms.
from EPUB Content Documents 3.0

　
　ただし、EPUBは様々なデバイスで読まれることが想定されています。例えば、デスクトップのような、何でもできてしまうデバイスから、iPadのようなタブレット型ＰＣ、サイズの小さいスマートフォン、そして、E Inkのような電子ペーパー端末まであります。特に動画に強い液晶と異なり、動的なコンテンツに弱い電子ペーパー端末はインタラクティブなコンテンツに向いているとはあまり言えません。また、全てのEPUBビュアがJavaScriptに対応しているわけではないのです。
　そもそも・・・
　EPUB3の仕様ではEPUBビュアーのJavaScriptのサポートはオプション。
なのです。
　ですので、仕様の上でもすべてのEPUB3ビュアーがJavaScriptに対応するとは限らないのです。　
　JavaScriptによる動的でインタラクティブなコンテンツの作成する場合でも、JavaScriptに対応していないビュアーでもそのコンテンツが読める範囲内で使用しなくてはなりません。JavaScriptが使用できないとコンテンツが全く読めないとか、コンテンツとして意味をなさないといったものはEPUB3の仕様上認められておりません。
　　
で、ここからが、ようやくこのエントリの本題です。
　
　そういうわけで（かどうかはわかりませんが）、より自由に作りたいという動機からEPUBではなく、HTML5で電子書籍を作ってしまおうという動きがちらほらと米国を中心に見られるようになりました。
　
　この動きを大きく分けると以下の２つの動きに分けられると思います。

  • HTML5で作成したコンテンツをアプリケーションとしてパッケージ化
  • Webサイトの電子書籍化　-Webサイトとの境界線が曖昧化するパッケージメディア-

　このエントリでは1のHTML5で作成したコンテンツのパッケージ化された電子書籍を紹介します。2のWebサイト化の話は次のエントリで紹介しようと思っております。　
　

2. パッケージ化されたHTML5電子書籍

　HTML5コンテンツはHTML5+CSS3+JavaScriptで構成されます。もう少し具体的に言えば、Webサイトなどで公開されているHTMLで作られたコンテンツもhtmlファイル、css、JavaScriptで構成されるファイル群です。これらを全て1つのフォルダに入れることでコンテンツとしては一応成立します。
　とはいえ・・、例えば、以下のような構成のコンテンツがあったとして、読者にはその中にあるindex.htmlファイルからアクセスしてもらって・・・となるわけです。
複数のhtml、css、JavaScriptを格納するコンテンツファイルのうち、index.htmlにアクセスする図
　これは厳しい・・。少なくとも私は気分が萎える・・・
　読者が必要のないファイルをうっかり開いてしまう可能性も高く、コンテンツのソースを変更してしまって読めなくなってしまう可能性も低くありません。そもそもこの状態では権利保護のへったくれもありません（あ、でも、不可能ではないのか。）。
　そういうわけですので、コンテンツを配布するにはやはり以下にように1つのファイルとしてに固める必要があります。
前の図のコンテンツをアーカイブファイル化して1つのファイルとして扱えるようにした図
　1つのファイルとして固める。
　読者にはファイルの中身を意識させない・いじらせない。
　
　EPUBやKindle形式のようなフォーマットも、おおざっぱな見方をすれば上のようにhtmlファイルなどを固めたパッケージ用フォーマットとして見ることができます。
　EPUBやKindle形式のようなフォーマットとして固めるのではなく、HTML5として固める方法として、以下の２つを少し詳しく紹介します。

  • ネイティブアプリ化
  • ウィジェット化

　
　

2.1. ネイティブアプリ化

電子書籍をネイティブアプリ化することでパッケージ化する。つまりはアプリ版の電子書籍をHTML5で作るということです。iOSやAndroidのApp Store経由で流す場合はそれぞれのOSにアプリケーションとしてインストールすることになります。
ビュアーアプリを必要とせずに、単体でコンテンツを読むことができます。コンテンツと一緒にそれを読むためのビュアーアプリも一緒にバンドルされているというイメージになります（正確にはそのデバイスのもつレンダリングエンジンを使用すると思われるので、すべてがバンドルされているわけではない）。
　しかし、ネイティブアプリを作成する場合、たとえば、スマートフォンやタブレットPC向けに作成しようとすると

  • iOS: Objective-C
  • Android: Java
  • Windows Phone: C#/VB

という感じでプラットフォームごとに別々の言語を使用しなくてはなりません。
　ちょっとそれはやってられない・・・という方のためにPhoneGapというフレームワークがあります。

PhoneGap
　
　HTML+CSS+JavaScriptで開発したアプリケーションをネイティブアプリケーション化するフレームワークです。ネイティブアプリ化させることができるだけではなく、様々なプラットフォームに対応させることが可能になります。現時点ではWebアプリではアクセスができないデバイスのネイティブな機能にアクセスするAPIも多く提供していますので、カメラをつかったインタラクティブな電子書籍などもつくることができるようになります。　

Supported Features « PhoneGap
　　
また、これはiOS専用ですが、Bakerという電子雑誌用のフレームワークもあります。

Baker


Baker Ebook Framework 3.1
・HTML5ベースを使った電子書籍フレームワーク「Baker」 – MOONGIFT
簡単にいうと、Xcodeのプロジェクトです。コンテンツをいれるbookディレクトリ以外はすでに用意されているので、このbookにコンテンツファイルであるhtmlファイルやcssなどをいれてやり、コンパイルすればそれだけでできる。
<img src=”https://code.kzakza.com/wp-content/uploads/2012/01/baker1-e1326375184227.png” alt=”XcodeでBakersを展開している図” title=”baker” width=”450″ height=”442″ class=”shadow” size-full wp-image-1331″ />
　
上のBakerをさらに利用したLakerというフレームワークもあります。より動的でインタラクティブなものがつくれるようになっているのでしょうか。デスクトップ用ブラウザでも見られるコンテンツの作成も実験的にサポートしているようです。

Laker


Laker
・jQueryやHTML5を使ってiPhoneやiPad向け電子書籍を作成する為のフレームワーク・Laker – かちびと. net　
　
　電子書籍をネイティブアプリとして作成するメリットとデメリットは以下になるかと思います。　

メリット

・1つのファイルとしてパッケージ化できる。
・iOSやAndroidのApp Storeなどのプラットフォームにコンテンツを配信し、有料化することができる。
・PhoneGap等のフレームワークを使用すれば、ハードウェアの機能にアクセスすることができる。
　

デメリット

・ネイテイブアプリなので読者に「インストール」という「読書」にあまりふさわしくない行為をさせてしまうことになる。
・プラットフォーマーの意向に左右されやすい。
・プラットフォーマーに支払う手数料のコスト
・永続性の問題(プラットフォームのOSのバージョンアップをいつまでもサポートできるのか)
　
　既存のプラットフォームに乗せて課金ができる、コンテンツを有償で配信できるというのは、コンテンツプロバイダにとってなによりの利点かもしれません。デメリットのプラットフォーマーの意向に左右されやすいというのは、その利点の裏返しとも言えます。パッケージはしたいけど、プラットフォーマーの意向には左右されてたくないぞぉという人にとってはウィジェット化という選択肢もあります。
　
　

2.2. Webウィジェット

　ウィジェットはアプリ化と同じでHTML5+CSS+JavaScriptを一つのアプリケーションとして固めたものです。W3Cでかなり検討が進んでおり、ほぼ固まったと言える状態です。
・Widget Packaging and XML Configuration（勧告）
・Widget Interface（勧告候補）
・XML Digital Signatures for Widgets（勧告案）
　これらの仕様の詳細については以下のIBMの解説が詳しいのでこちらをご覧ください。
・W3C ウィジェットの構成とパッケージ化
　
　現在、どのブラウザがWeb Wedgetに対応しているかは私が調べた範囲ではよくわかりませんでしたが、Operaは対応しているようです。あと、iOSアプリのCloudReadersもWidgetをサポートしているらしいです。
・Opera: Widget packaging and configuration support in Opera Presto 2.7
　ただし、上で紹介したIBMの解説でも紹介されていますが、HTML+CSS+JavaScriptをパッケージ化するウィジェットがすでに複数のプラットフォーマーから提供されており、W3CのWeb Wedgetで一本化とはなかなかすぐにはいかないのではないかと思われます。
　

2.3. その他

その他、以下のようなフォーマットも存在します。ブラウザが主にサイトを一纏めにして保存する際の使用されるようです。

    　

  • MHTML形式（Firefoxはプラグインが必要になるが、他の主要なブラウザでは読むだけなら対応しているらしい。）
  • webarchive形式 (Safari)

WARC(Web ARChive) は違いますよね・・。　
　
　
　ウィジェットが選択肢になるのは、もう少し先になるのかなと思います。ただし、プラットフォーマーに左右されずにパッケージ化できるという点では非常に魅力的な方法であると思われます。一本化されるのがW3Cの仕様かどうかは分かりませんが、いずれはまとまるのではないかと思います。そうあって欲しいですね。　
　
　プラットフォーマーの意向に左右されたくない。しかし、Wedgetが使用できるのはまだ先かというところで、いっそWebサイトに移行してしまおうという動きも見られるようになっています。これについては、また次のエントリで紹介します。
　
　
※2012/01/11訂正
当初、このエントリはパッケージ化の手段としてネイティブアプリ化のみを紹介しておりましたが、W3C Webウィジェットの仕様やMHTMLなどについて、HTML5コミュニティ、EPUBコミュニティ、Twitter上でお教えいただきました(ありがとうございます！)ので、構成を変更してWebウィジェットなどの紹介も追加いたしました。
※2012/01/12訂正
Objective-Cを使わずともHTML+CSS+JSだけでXcodeを使ってiOSのネイティブアプリが作れるかもと書いていましたが、HTML+CSS+JSだけではできないと神崎渉瑠さんよりコメントにてご指摘を頂きましたので、「ネイティブアプリ化」の項を修正・加筆書しました。。そもそもiOS SDKも必要ではないか（ツッコミ）。その件をご指摘くださった神崎渉瑠さんのコメントも合わせてお読みいただけると幸いです。

Webでの課金の仕様を検討するW3CのWeb Payments Community Group

kzakza

　HTML5 Advent Calendarの10日目です。
　Advent Calendarは、12月1日から25日までの間、毎日違う人が特定のテーマに沿ってブログ記事を書くというイベントです。HTML5 Advent Calendarの場合はHTML5について毎日違う人がブログを書くことになります。私はその12/10を担当しています。
・HTML5 Advent Calendar 2011 : ATND
　ちなみにAdvent Calendarは他のテーマでもたくさん立ち上がっていています。年末をこういう形でワイワイやって盛り上がろうぜというノリ、いいですね！
・Advent Calendar 2011 (jp) 開催予定リスト – Life like a clown
　というわけで、10日目の私はWeb上の課金の仕様化を検討しているW3CのWeb Payments Community Groupを紹介したいと思います。
・Web Payments Community Group　
　

1. W3CのCommunity Group

　そもそもこの”Community Group“とは何ぞやというところからです。W3Cには仕様の検討の場としてWorking Groupなどの検討体が存在します。しかし、Working Groupは設置してから実際に検討を開始するまでに少なくない手間と時間がかかってしまうため、そのハードルを下げる試みとして新たにW3Cに設けられた検討体がCommunity Groupのようです。Working Groupの前の段階に置かれているようで、Working Groupと比べると立ち上げるハードルがかなり低いために検討を素早く始められる上、仕様化が可能かどうかもわからない様々な可能性を探ることができる利点があるようです。
from W3C Community Groups: Web Payments Case Study（2011 W3Conf Manu Sporny氏発表資料）
　Community GroupのほかにBusiness Groupという検討体も新たに設けられました。
　詳しくはフロントエンド・エンジニアの矢倉さんのブログと2011 W3ConfにおけるManu Sporny氏の発表資料をご覧ください。
・ W3CのCommunity GroupとBusiness Group | Web標準Blog | ミツエーリンクス 　
・W3C Community Groups: Web Payments Case Study（2011 W3Conf Manu Sporny氏発表資料）
　

2. Web Payment Community Groupとは

　　Web Payment Community GroupはオープンなWeb上の課金の仕様化を検討するCommunity Groupです。W3CにCommunity Groupという新しい検討体が導入された時期に立ち上げられています。
　このCommunity Groupが目指すところはCommunity Groupの仕様草案の冒頭で述べているように

The PaySwarm Web platform is an open web standard that enables Web browsers and Web devices to perform Universal Web Payment. PaySwarm enables the people that create digital content such as blog posts, music, film, episodic content, photos, virtual goods, and documents to distribute their creations through their website and receive payment directly from their fans and customers.
from “PaySwarm 1.0 – Web API“

　
　ブログや音楽、写真、映像などのデジタルコンテンツを作り手が自分の作品のファンや顧客にAmazonやGoogleのような巨大なプラットフォームに依存せずに自分のサイトから直接、有料で配信するオープンな仕組みをつくる
　ということのようです。
　コンテンツのマイクロ化が進むと課金する金額もマイクロ化していくということで、MicroPaymentsの実現も当然対象になっています。多分、これはかなり重要だと思います。
　
　PayPalでできるようなことを巨大なプラットフォームに依存せずにオープンかつ分散型システムで実現しよう、そんなことを目標としている感じがします。
　ところで、仕様等でPaySwarmという言葉が散見されますが、すいません（汗）、なぜPaySwarmというのかはよくわかりませんでした・・・。
　しかし、W3CのCommunity Groupとして検討される前からPaySwarmという形でWeb課金の検討が行われていたようです。Web Payments Community GroupはこのPaySwarmでの検討がベースとなっている、というよりPaySwarmでの検討がWeb Payments Community Groupに引き継がれたと考えてよいのではないかと思います。
　以下はPaySwarmを紹介する動画ですが、Web Payments Community Groupの目指すところと共通しているようでもありますし、他の動画を比較してもわかりやすいと思われましたので掲載します。

　
　　
　　

3. 仕様草案

　W3C非公式な仕様草案としてWeb Payment Community Groupからすでに”PaySwarm 1.0 – Web API“が公開されています。
・PaySwarm 1.0 – Web API
　あくまでCommunity Groupの草案ですので、次の段階のW3CのWorking Groupの検討の対象になるかどうかは現時点ではわかりません。わかりませんが、Web標準で「課金」を実現するためには何が必要なのかという議論そのものに意義があるように思いますし、意義云々以前に面白いですよね。
　といいつつも・・・
　実は仕様書をまだ読み込んでいません（読んでもよくわかりません）。しかし、メタデータの交換にRDFaが利用されているようで、ライブラリアンとして、その点は興味深いので、もう少し深く追ってみたいところです。ちなみにWeb Payments Community GroupのManu Sporny(@manusporny)氏はRDF/RDFaの人でもありますので、LinkedDataなどのコミュニティと縁が深い仕様かもしれません。
　
　仕様草案を実装したデモサイトがすでに公開されています。
・The PaySwarm Developer Sandbox
　

4.想定されるユースケース

　PaySwarm 1.0 – Web APIで想定されるユースケースも公開されています。いずれもプラットフォーム非依存な事例です。
・PaySwarm – Use Cases
　すべては紹介できませんが、想定される利用法として以下のような例が挙げられています。

  • 小規模で独立したコンテンツプロバイダもしくは個人によるコンテンツ配信の取引に掛かる課金。コンテンツプロバイダというとそれでも個人というよりも組織を想起させますが、ブロガーのような個人のコンテンツ配信も対象です。
  • コンテンツのライセンスとコンテンツの取引の切り離し。ライセンスは利用とアクセスの権利を規定するもので取引とは切り離すべきだと。
  • 数千の個人からのマイクロペイメント。写真集を購入した読者に少額のオプションを提供したり、熱烈なファンからマイクロ後援を集めたりとか。
  • モバイル端末による実社会での課金の利用。Web上に限定されるスマートフォン経由でお金を店頭でも支払おうよと。
  • 外貨の両替。
  • 地域通貨として。
  • 電子版レシートの発行。とあるサイトでアーチストの曲をブラウザ経由で購入したとする。その際に受け取ったレシートをそのアーチストのもっていくと購入した際のレシートが要求されるので渡すと未発表の曲がダウンロードできたり様々な特典が受けられるとか。

　　スマートフォン経由で実社会でも利用できるようにしようと考えているのは少々驚きました。　
　

5. 議論を追うには

　　
　電話会議の議事録は以下で公開されております。メーリングリストのアーカイブも公開されています。
・PaySwarm – Teleconferences
・public-webpayments@w3.org Mail Archives
　　
　Twiiter上では前述のManu Sporny(@manusporny)氏がWeb Paymentsの情報を発信してくれていますし、#payswarm や #futureofmoney　という ハッシュタグでも議論や情報の交換がされているようです。
　
　「おもしろい！」と少しでもお感じの方、議論をぜひ追ってみてください。
　
　

HTML5のフォームの機能拡張へのブラウザの実装はどうなんだ? : typeコンテンツ属性の場合

kzakza

　HTML5のform拡張が今のブラウザでどの程度対応しているのだろうかとちょっと試してみました。あらかじめ断っておきますが、対応していないブラウザでみると、全く何がなんだかなよくわからないエントリです。
　　
　まずはtypeコンテンツ属性です。
・typeコンテンツ属性
　<input type=”ココにいれる属性” />
　結論からいうとOperaが一番対応しているみたいですね。次はSafariやChromeといったWebkit系のブラウザですが、Operaの対応ぶりと比較するとかなり差がついてしまっているようです。FirefoxはFF8でも全くといってよい程対応してません。IEは試せる環境がないので試していませんが、IE9だとどうなんのでしょうか。
というわけで、Operaを使える環境の方はOperaでご覧ください。

HTML5の新type属性のテスト

　以下はW3CのHTML5の仕様からの抜粋になりますが、HTML4時代からあるtypeコンテンツ属性を含めると以下になるようです。HTML5で新しく採用されたtypeコンテンツ属性、実装にあまり進展が見られないような気がします。

Keyword State Data type Control type
hidden Hidden An arbitrary string n/a
text Text Text with no line breaks Text field
search Search Text with no line breaks Search field
tel Telephone Text with no line breaks A text field
url URL An absolute IRI A text field
email E-mail An e-mail address or list of e-mail addresses A text field
password Password Text with no line breaks (sensitive information) Text field that obscures data entry
datetime Date and Time A date and time (year, month, day, hour, minute, second, fraction of a second) with the time zone set to UTC A date and time control
date Date A date (year, month, day) with no time zone A date control
month Month A date consisting of a year and a month with no time zone A month control
week Week A date consisting of a week-year number and a week number with no time zone A week control
time Time A time (hour, minute, seconds, fractional seconds) with no time zone A time control
datetime-local Local Date and Time A date and time (year, month, day, hour, minute, second, fraction of a second) with no time zone A date and time control
number Number A numerical value A text field or spinner control
range Range A numerical value, with the extra semantic that the exact value is not important A slider control or similar
color Color An sRGB color with 8-bit red, green, and blue components A color well
checkbox Checkbox A set of zero or more values from a predefined list A checkbox
radio Radio Button An enumerated value A radio button
file File Upload Zero or more files each with a MIME type and optionally a file name A label and a button
submit Submit Button An enumerated value, with the extra semantic that it must be the last value selected and initiates form submission A button
image Image Button A coordinate, relative to a particular image’s size, with the extra semantic that it must be the last value selected and initiates form submission Either a clickable image, or a button
reset Reset Button n/a A button
button Button n/a A button

from “4.10.7 The input element”. “HTML5 A vocabulary and associated APIs for HTML and XHTML”