HTML5で作成したコンテンツのパッケージの方法について

[Kazuhiro Ando]

皆様

　たびたび失礼します。安藤(@kzakza)です。今回は標記について質問をさせてください。

　前置きが長くなってしまいますが・・・

【前置き】

　最近、電子書籍について何かと話題になり、昨年、秋に仕様が確定したEPUB3についても対応するビュアーやツールがそろそろ出始めているようです。いろいろEPUB3で作成したコンテンツが出回り始めるかなあと思っています。

　一方で、EPUBではなく、もうHTML5による電子書籍についても時折話題になったりしています。特に電子雑誌にその動きがみられるようです。動きとしては大きくわけて２つにわかれるのではないかと考えるのですが、

(1)Webサイトの電子書籍化
　　Ｗｅｂサイトですが、特定のデバイス、例えば、iPadのようなタブレットＰＣでみると電子書籍っぽくみえるというものでしょうか。

たとえば、これです。
http://www.asidemag.com/

たぶんPlsyboy誌もおそらくそうだと思われます。
http://i.playboy.com/

(2)HTML5を1つのファイルとしてパッケージング

　これはネイティブアプリとして固めてＡｐｐ　Ｓｔoreなどで配信するものかなと思っております。アプリ版電子書籍というものです。

　これはいろいろとフレームワークもあると思いますし、たしかiOSならXcodeだけでアプリ化できると聞いたこともあります（年間8400円が払えなくて最後まで使ったことがないのでこのあたりはわかりません）

　電子書籍でカメラ機能を使わせたいとかネイティブアプリを利用できるようにしたいというならPhoneGapなどを使う手もあるかと思います。

　こんなフレームワークもあるようです。
Baker Ebook Framework 3.1
http://bakerframework.com/

Laker
http://www.lakercompendium.com/

【ここから本題】
　　ここからがお尋ねしたいところなのですが、HTML5で作成したコンテンツを(2)のようにパッケージとして作成する場合の方法というのはアプリ化以外にどのような方法がありますでしょうか？HTML5を利用したものとしてEPUB３やKindle形式などフォーマットもありますが、これ以外でもしありましたら、お教えいただけると幸いです。

　MHTML形式・・というものは使えるんでしょうか・・・？

安藤(@kzalza)

[Kazuhiro Ando]

　たびたび失礼します。安藤( @kzakza) です。
　先程のメールの【前置き】部分につきまして、あまり整理されていないのですが、昨日ブログでまとめてみました。

パッケージ化されたHTML5電子書籍 – HTML5電子書籍(1) -
http://code.kzakza.com/2012/01/html5ebook/

　誤字も多いと思われますし、そもそも間違っている箇所もありなのでこのMLに流すことに、ややためらいもありましたが、参考までにこちらも合わせて流させていただきます。もし間違っている箇所等ございましたらご指摘いただけると幸いです。

　このブログを書きつつ、情報を整理していくなかで生じた疑問が先程のメールの質問になります。

安藤

[Shumpei Shiraishi]

どうも、白石です。

> 　　ここからがお尋ねしたいところなのですが、HTML5で作成したコンテンツを(2)のようにパッケージとして作成する場合の方法というのはアプリ化以外にどのような方法がありますでしょうか？

W3Cウィジェットとかどうでしょう。
http://www.ibm.com/developerworks/jp/web/library/wa-w3cwidget/

2012年1月11日19:49 Kazuhiro Ando <a1t2...@gmail.com>:

> --
> このメールは Google グループのグループ「html5j.org」の登録者に送られています。
> このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
> このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。
>

[a1t2...@gmail.com]

白石様
さっそくお教えいただき、ありがとうございます。
こんな仕様があったのですね。全く存じませんでした。

あとでじっくり読ませていただきます。

取り急ぎお礼のみにて失礼します。

安藤

[Wataru Kanzaki]

神崎渉瑠です。

> (1)Webサイトの電子書籍化
> 　　Ｗｅｂサイトですが、特定のデバイス、例えば、iPadのようなタブレットＰＣでみると電子書籍っぽくみえるというものでしょうか。
>
> たとえば、これです。
> http://www.asidemag.com/

iPadを持ってないのでビデオを見ただけですが、そういう作り方をすれば可能です。

ページングが「スクロール」か、「今見ている画面を書き換える」か、の違いだけの、フルAjaxサイトです。

既存サイト/ライブラリでは、Googleの検索結果やTwitterのようなところで、
ある程度スクロールしていくと、次のページを先読みしてページの下に連結するというものがありまし、
（フッター（グローバルナビ、著者情報）が読めないので、無限スクロールは私は好きではないですが）
jQuery mobileでもこの方法を使っています。
（jQuery mobileの読み込みのきっかけ、スクロールは、
スワイプ（ドラッグ）ではなく、タッピング（クリック）とJavaScript/CSSアニメーションによる自動操作です。）

上記サイト（ビデオ）のような方法では、「スクリーンの大きさ＝1ページ」という概念が必要になってきます。

PCではスクリーン（ブラウザウインドウ）のwidthやheightは環境ごとに全く違いますので、不可能に近いと思います。
ですが、スマートフォン、タブレットPC専用にするのであれば、
多くがviewportやCSSのmedia queriesをサポートしていますので、
ピクセル単位でDTPのような（文字数制限や画像サイズ制限を含めた）調整を行えば可能だと思います。
また、たぶん、PCブラウザのように、「文字サイズだけを拡大」というのができないと思うので、ずれることはないと思います。

カメラなどについては、W3Cのワーキンググループで策定があります。
http://www.w3.org/2009/dap/
（RoadmapのHTML Media Capture参照）

> (2)HTML5を1つのファイルとしてパッケージング

> 　MHTML形式・・というものは使えるんでしょうか・・・？

中身はmultipart/mixedという、HTMLメールで使われている方法です。
それをサポートしているブラウザなら、見れます。

別の方法でHTMLファイルに埋め込むこともできます。
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADoAAAA6CAM”>
（対応しているブラウザのみ。png画像をbase64変換したものです。image/jpegやimage/gifなども使えます。）

この方法を使って、JavaScriptファイルと画像（backgroundImage）をパッケージングしました。
http://dabtilt.wi-wi.jp/dabbar.js

これらの方法で1ページにすべてを埋め込み、
タブメニューやアコーディオンメニューのような方法で、一部分を非表示、
何かのきっかけで表示を切り替えるようにすれば、ページングを実現できます。

あとはスタイルシートで書籍っぽいデザイン（レイアウト）にすれば完成です。

ともあれ、ローカルで読むだけならPDFがデファクトスタンダードですし、、、
できるけどやらない（主に互換性、WACG/ユーザビリティーの問題で）、ではなかったかと思います。

-----
Wings-Winds
http://www.wi-wi.jp/
神崎渉瑠

[Kazuhiro Ando]

神崎渉瑠様

　安藤 (@kzakza)です。返信ありがとうございました。ブログへのコメントもありがとうございます（ご指摘をうけて修正いたしました）。

>> (1)Webサイトの電子書籍化
についてです。

　ほとんど座学の私がこんなことを申し上げるのも恐縮なのですが、
今後、1つのサイトで様々なデバイスに柔軟に最適化させりレスポンシブ・ウェブデザインというのもの今後、増えてくるのではないかと思われます（個人的はそうあってほしいと思います）。

様々なスクリーンサイズ、異なる利用シーンのデバイスに最適化させねばならないという点では、Web上のコンテンツも電子書籍も同じですので、この両者がデバイスの最適化を追求すると、UIがかなり似てくるのではないかと思います。Webサイト上で提供される限り（という前提は必要ないかもですが）、同じデバイスで読むかぎり、Webコンテンツと電子書籍（もしくは電子雑誌）の違いはわからない、読む側もとくにそれを意識しないという感じになるのかもと思っています。

　その中でコンテンツプロバイダが「書籍」らしく見せたい、もしくはそのほうが読みやすいという場合にはCSSのPaged
MediaやJQueryなどを使用して、通常のWebサイトとは異なる機能やUIを付け加えるようになるのかなと思います。たとえば、デスクトップ版のブラウザでみると普通のサイトですが、タブレットPCなどでは雑誌っぽいUIにさせるなど。EconomistやWiredのように雑誌の全文をWeb上で公開しているようなところは、定期購読者向けなどにこういう形で見せるケースがありうるかもしれません。

　と、考えているのですが、昨日のメールで紹介させていただいたasideが例としてあまり適していなかったかもしれません。asideはiPadとiPhone上では雑誌っぽく見られるようですが、それ以外のデバイスでは対応してないみたいです（なのでしょうか？）。

>> (2)HTML5を1つのファイルとしてパッケージング

>
> 別の方法でHTMLファイルに埋め込むこともできます。
> <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADoAAAA6CAM”>
> （対応しているブラウザのみ。png画像をbase64変換したものです。image/jpegやimage/gifなども使えます。）
>
> この方法を使って、JavaScriptファイルと画像（backgroundImage）をパッケージングしました。
> http://dabtilt.wi-wi.jp/dabbar.js

　バイナリデータをテキストデータとして埋め込むことができるんですね。こんな方法があるとは存じませんでした。

　今回は詳しくお教えいただきありがとうございます。思い切ってこのMLでお尋ねしてよかったです。

安藤

2012/1/12 Wataru Kanzaki <goo...@wi-wi.jp>:

[Wataru Kanzaki]

神崎渉瑠です。

安藤さんの考えに対して誤解していたらすみません。

HTML文書というのはどんなビューワー（HTML用語ではブラウザ）でも、問題なく読めるようにすべきだと思いますし、
すべての環境で同じにすることはできませんし、
HTMLがそういうことを想定して作られているわけでもないと思います。

CSS、JavaScript、プラグインも、「あれば便利」を目指すべきだと思います。
「もしJavaScriptに対応しているなら、このような機能を使える。JavaScriptに対応していなくても問題ない」
「もしCSSに対応しているなら、このような表示になる。CSSに対応していなくても問題ない」
「CSSに対応しているのでこのような表示になる。しかし、自分には読みづらいのでこのようにしたい（たとえばブラウザ設定で文字サイズを大きくする）が、問題ない」
「もしプラグインに対応しているなら、プラグインを利用して閲覧できる。なければダウンロードして専用／代替アプリ（ビデオ閲覧ソフトなど）で閲覧することもできる。」
こういう作り方が、ユーザビリティーの目指す所です。

コンテントネゴシエーション（いわゆるブラウザ振り分け）を利用するのは、
すべての環境で同じにしたい、でなければ閲覧禁止ではなく、
「その環境に合わせた最適であろう閲覧環境を提供するため」に使うべきだと思います。

＊すみません、先のメールでWACGと書きましたが、WCAGの間違いです。
Web Content Accessibility Guidlines
http://www.w3.org/TR/WCAG20/
（邦訳） http://www.jsa.or.jp/stdz/instac/commitee-acc/W3C-WCAG/WCAG20/index.html

もちろん、一部は理想論にすぎないことも承知しています。
著作権保護や営業／経営、制作コスト、、、

ついでながら、こういうガイドラインがあります。
Mobile Web Best Practices
http://www.w3.org/TR/mobile-bp/
スマホ、タブレットPCには合わないかもしれませんが、
携帯電話のフルブラウザでも閲覧できるPCサイトの作り方などに、参考になると思います。

iPhone向けは以下のページを参考にしています。
アップルヒューマンインターフェースガイドライン（等）
http://bit.ly/yGvrxo
（転送先）
https://developer.apple.com/library/safari/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html#//apple_ref/doc/uid/TP40006556-CH1-SW1

http://bit.ly/A4eBD9
（転送先）
https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/Introduction/Introduction.html#//apple_ref/doc/uid/TP40002051

でしゃばってすみません。

[wakufactory]

こんにちは

html5のパッケージということですが、ブラウザ限定になりますが Chromeアプリがまさにそうですね。

こんなのを実験的に作ってみたりしてます。
https://chrome.google.com/webstore/detail/fpjejnklohiekenbpailggdkjmcmhjnp

作り方などはこのあたりをどうぞ
http://www.atmarkit.co.jp/fwcr/design/ux/chrome02/01.html

大江和久 ( @wakufactory )

[Kazuhiro Ando]

神崎様

　安藤です。返信ありがとうございます。

　神崎さんのお話を伺って、私のブログのあのエントリでは

　EPUB3ではビュワーのJavaScriptサポートがオプションな上に使える範囲にも制約がある→もっと自由に作れるHTML5電子書籍な方法がある

　という紹介の仕方になってしまい、もしかすると誤解を与えてしまったかもしれませんと気がつきました。

　あのエントリは、EPUB3の仕様で満足できないコンテンツプロバイダには、どのような選択肢があるのだろうかということを整理したくて書いたものです（図書館に勤務しておりますので、もしかして図書館にとって収集が難しいタイプの電子書籍も出てくるはという職業的な関心もあります）。ですので、EPUB3で満足できないコンテンツプロバイダならという前提の書き方になっていますので、アクセシビリティやユーザビリティ的にどうなのだろうというものが中心になってしまっているかもしれません。

　　ユーザビリティの点からお答えすべきなのか、アクセシビリティの点からお答えするべきなのかちょっと迷ってしまいますが、職業的に関心のあるアクセシビリティの点から申し上げると

・HTML-文書構造
・CSS ー見せ方
・JS-機能拡張

　と役割を分けたうえで、コンテンツ本体はHTMLに構造をきちっと定義していれる。というのがスクリーンリーダーを利用されるような方の利用も想定すると望ましいのかなと思っております。

　そういう意味では、CSSに見せ方、レイアウトなどを含めて柔軟に定義できるような作り方をHTMLファイルでするべきという理解です。

　とはいえ、HTML5になると、アプリケーション指向が強くなり、JSの役割が大きくなる一方のように感じます。たとえば、アプリ型電子書籍でアクセシビリティを確保するにはどうすればいいのだろうかという点は今後、調べなければと思っているところです。

　といいつつも、WCAG2.0の中身まで詳しく存じ上げているわけではないのが情けないところです・・。HTML文書のアクセシビリティをいかに向上させるかはについて、皆様にいろいろと教えを請いたいと思っているところです（その前に自分でがんばれですね・・）。

　アクセシビリティとユーザビリティは同じではないですが、相容れないものではないと思いますので、アクセシビリティを追求していけば、ユーザビリティも向上すると思います。

　長々と書いてしまい、恐縮です。しかも、返答になっていないような・・・。

安藤

2012/1/13 Wataru Kanzaki <goo...@wi-wi.jp>:

[Kazuhiro Ando]

大江様

　ありがとうございます!

　 Chrome アプリはほとんど手つかずという感じでしたので、勉強させていただきます。

　ご紹介いただいた作り方などを拝見するとiOSアプリよりも敷居はかなり低く感じました（金銭的にも）。どんなアプリが公開されているのか、ちょっと見てみたいです。

安藤

2012/1/12 wakufactory <w-go...@wakufactory.jp>:

[Wataru Kanzaki]

神崎渉瑠です。
長文失礼します。

私は、ウェブページ（ウェブサイト）とウェブアプリは全く別物と考えています。

ウェブページは、どんな環境でも閲覧できる文書。
アプリは、何かを行うための道具。

Windows専用アプリ
ー＞あるユーザー曰く「Macで動きません。」
アプリ開発者
ー＞Windows専用だからあきらめてください。
or ー＞ わかりました。Macで動くように改造します。

Firefox専用アプリ
ー＞あるユーザー曰く「IEで動きません。」
......（後略）

やってることは、これだと思うんです。

「ある作業をするためのアプリケーションを制作する言語として、C#やobjC。
その選択肢の一つとして、一度作ると様々な環境に対応できる言語としてJavaScriptが選ばれた。」
という、、、
ウェブページと考え方が逆というか、、、

------------
閑話休題
Adobe「Flash、PDF、、、」
( ;´･ω･`)人(´･ω･`; )
Sun/Oracle「Java、、、」
------------

本来の電子書籍はウェブページの作り方に近いと思います。
書籍フォーマット対応ブラウザであればどんな環境でも読める、というのが最大のメリットだと思います。
（その過程で作品に対する対価の支払いがあればなおよし。
そのためにDRMのないHTMLよりもEPUBが使われるという。『著作権』の考え方ですね。）

では、わざわざアプリにするメリットは何かというと、
アプリなら、アプリ配布サイトで紹介してもらえるのに、
ウェブページならSEOだ何だのと施さないと、そのページにたどり着けません（作品を読めない）ということではないでしょうか。
それから、対価の支払いの問題だと思います。（作者に取っては、読まれることよりもこちらの方が問題が大きいのでしょうか？
それとも、「アプリ制作者」の問題でしょうか？）

--------------------------
・ご存知かもしれませんが、無料の音声ブラウザを紹介します。
ALTAIR for Windows
http://www.normanet.ne.jp/~altair/

Windowos XP用ですが、弱視者対応のスクリーンショットを見れば、
書籍がどんな環境で読めることも望ましいかというのも想像できると思います。
EPUB、HTML（フォーマット、言語仕様）は、こういう表示にも対応しています。

一般書籍は文字が小さすぎて読むことができなかった、それが電子ブックで読めるようになるかもしれない。
私は、そういう人たちにこそ読んでもらいたいと思います。
HTMLアプリはこれが不可能になり、本当に「どんな人にも」やさしい作りではなくなります。
「読める人だけ読めれば良い」というのであれば、私は推奨も非推奨も訴えたりはしません。

・old newsかもしれませんが。
e読書ラボ（東京都神保町）
http://edokusho.info/
リーダー体験などもできるそうです。

On 2012/01/14, at 4:59, Kazuhiro Ando wrote:

> 神崎様
>
> 　安藤です。返信ありがとうございます。
>
> 　神崎さんのお話を伺って、私のブログのあのエントリでは
>
> 　EPUB3ではビュワーのJavaScriptサポートがオプションな上に使える範囲にも制約がある→もっと自由に作れるHTML5電子書籍な方法がある
>
> 　という紹介の仕方になってしまい、もしかすると誤解を与えてしまったかもしれませんと気がつきました。
>
> 　あのエントリは、EPUB3の仕様で満足できないコンテンツプロバイダには、どのような選択肢があるのだろうかということを整理したくて書いたものです（図書館に勤務しておりますので、もしかして図書館にとって収集が難しいタイプの電子書籍も出てくるはという職業的な関心もあります）。ですので、EPUB3で満足できないコンテンツプロバイダならという前提の書き方になっていますので、アクセシビリティやユーザビリティ的にどうなのだろうというものが中心になってしまっているかもしれません。
>
> 　　ユーザビリティの点からお答えすべきなのか、アクセシビリティの点からお答えするべきなのかちょっと迷ってしまいますが、職業的に関心のあるアクセシビリティの点から申し上げると
>
> ・HTML-文書構造
> ・CSS ー見せ方
> ・JS-機能拡張
>
> 　と役割を分けたうえで、コンテンツ本体はHTMLに構造をきちっと定義していれる。というのがスクリーンリーダーを利用されるような方の利用も想定すると望ましいのかなと思っております。
>
> 　そういう意味では、CSSに見せ方、レイアウトなどを含めて柔軟に定義できるような作り方をHTMLファイルでするべきという理解です。
>
> 　とはいえ、HTML5になると、アプリケーション指向が強くなり、JSの役割が大きくなる一方のように感じます。たとえば、アプリ型電子書籍でアクセシビリティを確保するにはどうすればいいのだろうかという点は今後、調べなければと思っているところです。
>
> 　といいつつも、WCAG2.0の中身まで詳しく存じ上げているわけではないのが情けないところです・・。HTML文書のアクセシビリティをいかに向上させるかはについて、皆様にいろいろと教えを請いたいと思っているところです（その前に自分でがんばれですね・・）。
>
> 　アクセシビリティとユーザビリティは同じではないですが、相容れないものではないと思いますので、アクセシビリティを追求していけば、ユーザビリティも向上すると思います。
>
> 　長々と書いてしまい、恐縮です。しかも、返答になっていないような・・・。
>
> 安藤
>

(snip)

[Kazuhiro Ando]

神崎様

　安藤（図書館勤務）です。私も長文失礼します。

　また、途中からHTML5から離れてしまいそうで、申し訳ございません。

> 私は、ウェブページ（ウェブサイト）とウェブアプリは全く別物と考えています。

   Webアプリの定義をきちんと把握しておりませんで、はっきりしたことが申せないところなのですが、最近のサイトをみているとアプリケーションライクなサイトが見られるようになっています。

  例えばですが、facebookやtwitterのモバイルサイトが、公式のネイテイブアプリにかなり似せたＵＩになっています。機能もカメラのようなハード側の機能を使うことができないようですが、それ以外は公式アプリと機能的な違いはさほどないものになっています。こういうアプリケーションライクなサイト、というべきか、インストールの必要のないURLに移動するだけで使用することができるアプリケーションは今後増えてくるのではないかと思われます。

  というところを見ていくと、Webサイトとアプリケーションの境界線がなんとなくあいまいになってきている印象です。ここまでfbやtwitterのようにここまでアプリケーションに近づけなくても、ページの一部にこれまでのWebページでは出来なかったアプリケーションっぽい機能が組み込むということは十分ありえると思います。

  　現在はブラウザごとにW3Cの仕様を実装するスピードや種類が異なるので、ブラウザごとの対応が必要になりますが、仕様の検討が進み、ブラウザの実装の標準化が進めば、どのブラウザでも同じようにインストール不要でアプリケーションが使用できるという状況になるのかなぁと思います（いつになるかわかりませんが）。Webそのものがプラットフォームになり、OSやプラットフォームに左右されないオープンな環境を提供することになるかもと。

> では、わざわざアプリにするメリットは何かというと、
> アプリなら、アプリ配布サイトで紹介してもらえるのに、
> ウェブページならSEOだ何だのと施さないと、そのページにたどり着けません（作品を読めない）ということではないでしょうか。
> それから、対価の支払いの問題だと思います。（作者に取っては、読まれることよりもこちらの方が問題が大きいのでしょうか？
> それとも、「アプリ制作者」の問題でしょうか？

　　同意です。
 　コンテンツを握るプラットフォームは
 ・コンテンツへのリーチ
 ・課金（とくに少額課金）
 ・権利保護（DRM）も

 　を握ることが重要なのだと考えますが、電子書籍については現時点で、日本でその３つをすべて押さえているところは存在しないがために、次善の策としてのApp
Storeで販売しているところが多いかと思います。個人的には電子書籍について、そのすべてを握る巨大プラットフォーマーが日本で生まれるよりは、せめてリーチ、課金、権利保護の各レイヤーを分けることはできないのか、できれば、オープンなプラットフォームで実現できればと、かなりあいまいな願いを抱いていますが、Web上の課金の標準化については、W3Cの下で検討が始められたようですので、ちょっと期待しています。まだ、Community
Groupの段階なので仕様化されるか未定ですが。

 http://code.kzakza.com/2011/12/web-payments/

> 一般書籍は文字が小さすぎて読むことができなかった、それが電子ブックで読めるようになるかもしれない。
> 私は、そういう人たちにこそ読んでもらいたいと思います。
> HTMLアプリはこれが不可能になり、本当に「どんな人にも」やさしい作りではなくなります。
> 「読める人だけ読めれば良い」というのであれば、私は推奨も非推奨も訴えたりはしません。

  こちらも完全に同意です。全ての人が等しく全ての情報にアクセスできるという環境を提供することこそが、図書館の根本的な役割でもあると考えています。読書ができないというと視覚障害者の方がまず想起されるところですが、高齢者の方で目が悪くなったから本を読まなくなったという方は非常に数多くいらっしゃいます。アクセシビリティの強化された電子書籍のニーズは必ずしも特別なものではありません。

  なので、私もアクセシビリティの強化されたEPUB3が主流になってほしいと思いますし、非常に期待しています（それ故にあのエントリはEPUBありきで、例外的なコンテンツをHTM5電子書籍という書き方になったことはご理解ください）。昨年秋に仕様が確定したEPUB3にはDAISY(Digital
Accessible Information
SYstem)という一般的には視覚障害者向けと認知されているデジタル書籍のフォーマットの機能を数多く取り込んでいます。さらにいえば、EPUB3とDAISYの次期フォーマットであるDAISY4ではEPUBとDAISYは融合といっていい関係になります（これまた自分のブログですが・・）。

 http://wp.kzakza.com/2011/02/epub3_daisy4/

  DAISYの作成は紙の書籍をベースにすると非常にコストガかかるそうで、点数としてはあまり多くはありません。EPUB3の普及でよりアクセシブルな書籍が当たり前になるという時代がそう遠くない時期にくるのではと思い、非常に期待している次第です。

　とはいえ、デジタルになってしまうと、同じデバイスでWeb上のコンテンツも「書籍」のコンテンツも読まれることになるのでしょうから、デバイスに最適化させていく過程でそれぞれで影響を与えることはありうるかもしれませんね。

安藤 （@kzakza）

2012/1/14 Wataru Kanzaki <goo...@wi-wi.jp>:

[Wataru Kanzaki]

神崎渉瑠です。

私の考えは「『あれば便利』という作り方をすればいい」です。

あと、対象としている人の種類（？）にも関係しますね。
ビデオサイトやアルバム（写真）サイトをテキストブラウザで見てもらおうとは思いませんし、
そういうブラウザへはサイトの特徴などを説明して無視していいと思います。
また、たとえばゲーム解説を目の見えない人にしたところで、「ゲーム」ができないんだから意味はないと思います。
（解説だけでも聞きたいという人もいるでしょうけど、、、）

逆に、書籍は目の見える人だけのものではないと思います。
（漫画や、プログラミングなど目の見える人向けの何かの資料を除く）
だから、目の見えない人向けの作り方を考えるべきではないのか、そう思うわけです。

書籍に限定したパッケージングか、書籍以外に限定したパッケージングか、もっと一般的なパッケージングか、
そういうところでも、やり方が違ってくると思います。
書籍をアプリケーションにするなら、ユーザビリティーを考えたアプリケーションにすれば良いと思いますが、おそらくそれは不可能ではないでしょうか。
なら、コンテンツだけを配布して、ユーザビリティーが考慮されたアプリケーションで読んでもらう方が良いと思います。

TwitterはJavaScript対応、カメラ対応、”何か"対応ブラウザに対してはそれようの作り方になっていますが、
未対応ブラウザへはその機能が使えないだけ、
または、モバイルサイト（全機能を使わない、プレーンなHTMLのページ）に誘導しています。

昔はAltairでアクセスすると、メニューから脱出できなかったですけどね。
先ほどアクセスしてみると、「モバイルサイトを見てください」と書かれていました。
その先はログイン必須、Altairでログインできなかったので見ていませんが。。。
（結局、アクセスできないらしい、、、cookieの設定か何かなんですかね、、、？、、よくわかりません。）

アクセシビリティーは主に障害者向け、ユーザビリティーは主に健常者向けの言葉だと思いますが、私は同じ物と考えています。言い回しについては気にしないでください。

[YONEKURA Koji (intranet)]

初投稿でありながら、あまりにも素朴な疑問を投げかけてしまって恐縮です。

HTML5で作成したコンテンツは、アプリケーション的なふるまいをすることが基本なのでしょうか。

HTML5によるコンテンツには、純粋なドキュメントがあってもいいと思うのです。
純粋な、とは、スクリプトを含まないHTMLとCSSだけで記述したコンテンツです。
そのようなコンテンツは珍しくないと言われるかもしれませんが、HTML5では、コンテンツはDOMに展開されるのが前提ですよね（？）。
スクリプトからドキュメントへのアクセスを行わなければDOMは必要ないと思うのです。
よって、純粋なドキュメントとは、DOM展開されないコンテンツということです。
例えば、文書型宣言だとかhtml要素だとかに、DOM展開をしないといったオプションを指定して、ユーザエージェントによるコンテンツの処理を軽量化するという考えとかがあってもいいような気がするのです。
このような考えは、HTML5の思想に反しているのでしょうか。

[Kazuhiro Ando]

投稿ありがとうございます。安藤です。

> HTML5で作成したコンテンツは、アプリケーション的なふるまいをすることが基本なのでしょうか。

　ネイティブアプリとして作成するコンテンツはアプリケーション的な振る舞いも必要になるかと思いますが、こちらのウィジェットとして作成するのであれば、JavaScritpは必須ではないように思えますので、HTMLとCSSだけで作成するコンテンツも作れるのではないかと思います（ウィジェットには他にconfig.xml
というパッケージの構成を記述するファイルが必要なようですが）。

http://www.ibm.com/developerworks/jp/web/library/wa-w3cwidget/

> そのようなコンテンツは珍しくないと言われるかもしれませんが、HTML5では、コンテンツはDOMに展開されるのが前提ですよね（？）。
> スクリプトからドキュメントへのアクセスを行わなければDOMは必要ないと思うのです。
> よって、純粋なドキュメントとは、DOM展開されないコンテンツということです。
> 例えば、文書型宣言だとかhtml要素だとかに、DOM展開をしないといったオプションを指定して、ユーザエージェントによるコンテンツの処理を軽量化するという考えとかがあってもいいような気がするのです。
> このような考えは、HTML5の思想に反しているのでしょうか。

　JavaScriptを使用しない場合でもDOMに展開されたコンテンツをHTMLかXHTMLでシリアライズするということではいけないのでしょうか（EPUB3はXHTMLでシリアライズされています）？

　すいません・・。不勉強でHTML5とDOMの話について（そもそもDOMについて）よく理解しておらず、お尋ねの件についてうまくお答えすることが私はできないのですが、おっしゃるようなことな可能なのでしょうか。HTML5はDOMが前提なのかと思ってました・・。

安藤

2012/1/16 YONEKURA Koji (intranet) <k-yon...@ah.jp.nec.com>:

[Wataru Kanzaki]

神崎渉瑠です。

本を書いたことも、アルファブロガーでもないので私が言ってもしょうがないかもしれませんが、
HTML5の99%がJavaScriptとCSSです。（以前は8割とか9割と言っていましたが、割合を増やしました。）

https://developer.mozilla.org/ja/HTML
Mozillaのページは、使用されているタグを見るとHTML5のものですが、
JavaScriptのon/offの切り替えで、見た目がほとんど変わりません。

私ならMozillaのサイトもHTML5と言いますが、
紹介する場合は、JavaScriptにCSS、大量のビデオと音楽、そういう派手な方がウケがいいと思います。

http://www.nintendo.com.au/gamesites/mariokartwii/
（音が出ます。動作（JavaScript）がかなり重いのでブラウザクラッシュ注意。）

この作り方は、５年くらい（以上前？）にHTML4+CSS2.1+JavaScriptで作られているページを見たことがあります。
CPUがC2Dが出るか出ないかの時代にこんな物を作られたら、とても見られた物ではなかったですけどね。

つまり、HTML5と言われている物でも、HTML4でも作ることが可能な物もあるということです。
（だって<nav>や<section>、<video>を使うか<div>、<object>を使うかの違いしかありませんから。）
nintendoのサイトはIE6ではFlashページに飛びますから、
昔の作り方の方がいろんなブラウザに合わせられていた、ということになります。

<canvas>にしても、ブラウザ独自機能として何年も前から使われています。
（canvasとfilterや、CSSスプライト（background-image/positionやclip）を切り替えて）

動作の軽量化については、
CSSが原因なのか、JavaScriptが原因なのか、転送量が原因なのかで異なりますので、一概には言えません。
CSSが原因ならJavaScriptを使う使わないに関係ありません。
JavaScriptが原因ならJavaScriptを切れば軽量化されますが、
転送量が原因ならAjaxにする方が軽量化されます。（framesetはそれを目的として作られた物です。）
ただし、AjaxにしたときのJavaScriptが重くなる原因になりかねないので、要注意です。

> 例えば、文書型宣言だとかhtml要素だとかに、DOM展開をしないといったオプションを指定して、ユーザエージェントによるコンテンツの処理を軽量化するという考えとかがあってもいいような気がするのです。
ブラウザ設定でJavaScriptを停止させてください。
制作者がJavaScriptを作るのは、JavaScriptを使わせるためですから、
もしHTMLタグとしてそういう物が定義されたとしても、使われることはないと思います。

[Takeo Kunishima]

「HTML5では、コンテンツはDOMに展開されるのが前提」というのは誤解があるように思います。
マークアップ言語のsyntaxとしてHTML形式とXHTML形式の2つがあり（ここはHTML 4.0以前や
XHTML 1.xとは異なる）、そのsemanticsをDOMで規定する、ということであり、HTML5文書を
必ずDOMに展開しなければならないわけではない、と理解しています。

国島丈生

2012年1月16日18:48 YONEKURA Koji (intranet) <k-yon...@ah.jp.nec.com>:

> --
> このメールは Google グループのグループ「html5j.org」の登録者に送られています。
> このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
> このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。
>

--
Takeo Kunishima
http://tk.kunilab.org/ja/
http://kunishi.blogspot.com/
Twitter/Facebook: kunishi, LinkedIn: takeokunishima