11月 18

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

 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”  
 
 

11月 08

W3CでのDRMの仕様の標準化を進めるべきかどうかの議論を少し追ってみました。

 先週のW3C TPAC(Technical Plenary and Advisory Committee)の中で行われたHTML Working GroupのF2F(顔合わせ)ミーティング(2011/11/3-4)の要約がW3C Blogに掲載されています。その中にDRMの仕様の標準化をW3Cの中で検討できないかという議論が行われたようです。以下はW3C Blogの抜粋です。

DRM

There is a discussion brought to the HTML WG by the WebTV task force to know if there is a possibility to add a mechanism to protect content. There is no resolution yet. On this same topic, an interesting article has been published on the history of the different systems proposed in the past.

from Open Web Platform Weekly Summary – 2011-10-31 – 2011-11-06 – W3C Blog
 
 Web標準でDRMの仕様ができるならこりゃすごい話だと思い、どんな議論がされていたのか、少し追ってみました。

 上で要約されているHTML Working GroupF2Fミーティングの議事録が公開されています。その議事録を読むとDRMについての議論はWeb and TV Interest GroupMedia Pipeline Task Forceが作成したRequirement Document Draft(要求文書案)という要望リストをベースに進められたようです。ですので、DRMについての議論も映像コンテンツの保護を目的するDRMが中心になっているのではないかと思われます。

では、議事録を紹介するまえにこの要求文書案の該当部分を先に抜粋します。

 

Content Security and Digital Rights Management

The delivery of premium media over an unsecured network such as the Internet requires the protection of proprietary and copyrighted content. Standardized support for content protection requires the following.

R9. Security and Digital Rights Management Identification (Dropped. No change necessary)
The media element interface should support the specification of content protection and digital rights management formats (e.g. DECE Ultraviolet, DTCP-IP, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)

R10. Security and Digital Rights Management Parameters (LC bug #13333 and #13625)
The media element interface should support secure specification of content protection and digital rights management parameters (e.g. subscription requirements, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)

R11. Security and Digital Rights Management Feedback (Gap? Do we just need to agree on common identifiers?)
The media element interface should support the feedback of relevant content protection and digital rights management information (e.g. supported DRMs, DRM ready, need to reactivate license, etc.).
Relevant Use Cases Include: Content Protection (Issue-40)

frome Requirement Document Draft

 上のR9はすでに検討から外れましたが、R10とR11が残っています。この2つの要求について11/3のF2Fミーティングで議論が進められたようです。その該当部分の議事録が以下です。

R10
… getting DRM system information
… exchange DRM related messages
… ref: OIPF DAE specification
… R11. Content Protection Feedback and Errors
Tantek: are the slides in the respective bugs?
Clarke no but they could be
ACTION Clarke add contents from the slides of the presentation to each specific bug
[trackbot] Sorry, couldn’t find user – Clarke
MW: Different conclusions though, might be components exposed through the web interface, pass through for parameters is different than webarch that hides platform/device specific things
… re: content protection
… some devices have content protection, some dont’
… my question to the group is: is it acceptable to introduce this capability to the web platform (pass thru), or some other strategy?
Anne: the last time this was discussed on WHATWG list
… least controversial suggestion was API feed bits into the video stream
… DRM would be implemented at the application level
MW: you can’t implement the DRM in the JS
… needs to be implemented in trusted execution environment
[karl] there is nothing secure in life. useless pun.
MW: objective of DRM is not to make it impossible but difficult, for some well defined values of difficult
… need these capabilities in the trusted computing layers
… below the video element
Anne: we are already at the place where you have H264 decoding in JS
… I was just stating the last thing that was discussed on this topic that had some traction beyond we don’t want to go there.
John Simmons of Microsoft: Echoing what Mark said.
… key takeaway
… DRM systems are going to be used on video delivered to devices
… people who develop DRM understand those constraints
… e.g. can’t implement in JS
… key question is whether HTML will be able to accomodate DRM protected content
… or continue like silos today
… which prevent large scale growth of internet television that we’d like to see
MV: related to 179
… there are these two proposals
… 1. for parm
… 2. not use it
… data- and x- are supposed to be prohibited from use
… but no change proposal says use those
… didn’t make sense
… details are in the issue 179 two alternate proposals
… can anyone comment?
PC: project change proposal?
… original change proposal
MV: just above the blue box
… furthermore the data-* mechanism etc.
… can’t be used
… but then in Sylvia’s counter proposals says to use them.
… does the quoted text need clarification
… or is it just a misunderstanding?
Hixie: the data-* attributes are intended to only be used by scripts in the page, not by the user agent
… if you have something the user agents would use, then either we would add it to the language
… or if it was experimental we would use x-* syntax
… e.g. webkit has x-webkit-*
Adrien: the misunderstanding was how x- attribute might be used on the way to standardization
… e.g. like it’s done with vendor prefixing in CSS.
… in order that those experimental implementations don’t drive actual content, we use a vendor prefix
… the proposed standard doesn’t have a vendor prefix
… the vendor prefixes are a temporary measure to experiment while standard is being agreed.
MV: concrete case is UPnP
… available spec
… but no support for it
… slightly different model UPnP video vs. regulary HTML video access
… a separate group UPnP could publish use x-upnp-* params, and encourage others to
Hixie: if they’re writing an actual standard they wouldn’t use x-
… just upnp-
MV: so ok for them to just use upnp- ?
Hixie: I wouldn’t recommend it, would prefer to come to the group
MV: I agree primary idea is bring these in bug 13625 (13635?) also tracks separate attribute
[pimpbot] 11http://www.w3.org/Bugs/Public/show_bug.cgi?id=13625 b.lund, P2, NEW, 13There is no way to pass audio and video content metadata to the user agent that is required in some cases for playback.
PC: I want to point people to the conformance clause in HTML5
… It says you can conform by pointing to HTML5 and other set of additional specifications
… a vertical industry could say you conform to HTML5 and this other specification
… too many people believe you want to force everything into the HTML5 spec.
… I want to support Ian’s view that if something is generic we want that discussion and get that in
… or at least know about it
… so that we can detect when something becomes emergently generic
Hixie: I agree
… the conformance section really it says what’s been true of any spec
MW: I wouldn’t encourage people to write extensions. we have an interest in strongly discouraging separate extension. we don’t want fragmentation.
… if you look at OIPF and HDTV you have 100s of 1000s of pages of stuff
… a uniform platform, that should be our goal
Hixie: in practice as people do start writing specs that start extending HTML in that way, it probably means we failed, but in reality it might happen anyway

from HTML WG f2f — 03 Nov 2011

DRMについての議論がどこまで続いているのか、よくわかりませんでしたので多めに抜粋してあります。

この会議ではClarke Stevens氏がどうもDRMについて、提案をしたらしいのです(おそらく)。そのClarke氏が使用したスライド資料がどうも見つかりませんので、議論はちょっと追いにくいのですが、「HTMLやJavaScriptでやったもんかな〜(疑問)」「HTMLがDRMで保護されたコンテンツに適応できるのか」みたいな意見が出たみたいです。どんな結論がでたのかはよく分かりませんが、おそらく出なかったのではないかと。個人的には有料のWebサイトというものがありえるのではないかと思うので是非議論をすすめてほしいと思うところです。今後、どのように進展していくのか興味深いところです。

さらにWeb and TV Interest GroupのメーリングリストでこのDRMに関する議論を遡ることができます。
Web and TV Interest GroupのMLのDRMに関するやりとり
 
 
 

11月 04

Amazonの電子書籍の貸し出しサービスについて少し・・

 まずは私の妄想から・・・。

  1. 借りた電子書籍をダウンロードできてローカルで読める。
  2. 借りた書籍には下線やコメントやその他もろもろなことができる。
  3. 返却。
  4. また借りる。
  5. 前回借りた時に引いた下線やコメントなどが表示される。そういった情報はクラウドで保存されているので。
  6. 自分が引いた下線やコメントやその他諸々は非公開にして自分だけが見られるようにすることはもちろんのこと、特定のグループに公開範囲を限定してグループ内で共有することも、全利用者に公開して共有することができる。ここでいう公開は他の人が読書中にその本文に自分の引いた下線やコメントなどが表示されること。
  7. グループはプラットフォーム内にいくつも作ることができ、利用者は複数のグループに参加することができる。読んだ本の下線、コメントなどの公開範囲も利用者は各グループごとに柔軟に設定することができる。

 つまり、読書をキーとしたSNS的なサービスなのですが、こんなサービスどうでしょうか。ゼミで共有したり、勉強会で輪読したり。こんなSNSなサービスを図書館が提供したら面白いと思っていました。以前、他のブログで少し触れました。

電子書籍をテーマにこんなソーシャルなWebサービスはつくれないか。 | e-chuban blog

 しかし、Amazonが1から5までやったちゃいましたねぇ・・・。6以降も時間の問題か・・。

hon.jp DayWatch – 米Amazon、電子書籍の貸し出しサービス「Kindle Owners’ Lending Library」を開始。月1冊、無期限で

 一定の会員料を払えば、コンテンツが使い放題的なサービスは結構ありますので、こういうサービスを展開すること自体は全く不思議ではない。もともとAmazonが提供するKindle Storeは電子書籍を販売するというよりもサービスを提供するという側面が強いなぁと思っていましたが、それがいよいよ強くなってきた感じがします。
 
 読者が引いた下線やコメント、そして、今回触れなかった他の書籍に対する参照情報(具体的にいうとリンクです。ハイパーリンク。他の書籍の本文に対するハイパーリンク)などはクラウドに依存せざるをえないものなのかという問い対する答えは私の中ではまだ出ていません。もし依存せざるを得ないなら、ソーシャルリーディングも学術情報に必須の参照も巨大なプラットフォームありきになってしまうのではないかという気もしますが、そうなるとプラットフォームごとにコンテンツが分断されて悲惨なことにならないようにきちんと関連する仕様や標準をつくっておく必要があるのではないかと思います。

 巨大なプラットフォームに依存しない方法で実現できる仕組みはないのか!という問いを投げかけたところで今日はおしまいにします。データの保存と共有を巨大などこか一箇所に依存しない形できないものか、そういうWeb標準な仕組みは検討されていないものかと。以下はやや関連がありそうで面白そうですが、どうなんでしょうね。

Unhosted: separating web apps from data storage
http://unhosted.org/ 
 

11月 03

ぼくのかんがえる電子書籍リーダーのUI : 紙の書籍のUIを真似ただけでは足りなくて

 ファミコンが子どもの心を鷲づかみにしていた時代に誰しもノートに書いた「ぼくのかんがえるゲーム」。そんなノリで電子書籍リーダーのUIについて書いてみます。

 まず現状から申し上げると、iPadなどのタブレットPCがで利用できる電子書籍リーダーアプリのUIはほとんどが以下のような感じですよねぇ。

iPadのiBooks UI
iTunes App Store iBooks より

 基本的に紙の書籍のUIをベースにしているわけですが、
 

正直、いろいろと足らんと思うのです。 
 

 例えば、ですが・・

  • 複数の本を同時に開けない。
  • 複数のページを同時に開けない。
  • 上の2つと関係しますが、複数の本やページを見比べることができない。
  • ページ間の遷移が酷く面倒。19ページから67ページに移動とかそんなピンポイントな移動は「無茶言うな!」という気分になる。
  • 今日はあと一区切りでとおしまいにしようとか思っているけど、その一区切りがどれくらい先か、数値による表示はあるけど実際のところようわからない。←さすがに言いがかりか?
  • ブックマークとかしおり機能とか沢山つけてしまうと、後で使おうと思っても一杯になって整理も「はぁ、もうめんどくさい!」←ものぐさですいません。

 
 とかとかいろいろと不満がでてくるのです。本文と注を行ったり来たりする学術書は結構辛い、というわけで、電子書籍にあるべきUIとは何かについては、たまにいろいろと妄想したりするのですが、こんなUIどうでしょうということで、少し書いてみました。 
 

○複数の本やページを同時に開く

 ブラウザのタブのようなUIはどうでしょう。こんな感じで同時に開いてタブでコンテンツの表示を切りかえるのです。

 同じ本の複数のページはもちろん、複数のページを同時に開きます。タブを切り替えるとこんな感じで。


 

○複数の本やページを同時に表示する

 電子書籍の大きな欠点は複数の書籍を同時に開いて見比べることができないことです。本ならば並べて見比べることもできるんですが。電子書籍でもやりたいですよね。EPUBやmobiはリフローでデバイスのサイズの制約をあまり受けません。だからiPadでもスマホでも読めるわけですが、ならばこんな感じで同時に表示させていはいかがでしょうか。一方はスマホサイズで表示させるとか。


 

○さっき見たページを行ったり来たりしたいんですよ

 ということで、以下のようなどこかでみたことのあるボタンは必要ですよね。履歴を使って行ったり来たりと。すでにこの機能も備えているものもあるようですが、Webブラウザと比較するとまだまだおまけという感じが拭えません。


 
 このボタン、次で述べる検索機能が実現するとより重要になってきます。検索結果を行ったり来たりしなければなりませんので。

○目次だけでは足りません

 電子書籍の中を自由自在に動くにはパラパラとページを順番にめくったり、目次からリンクをたどって飛んだ行ったりするだけでは全然足りませんので、やはり以下のような検索機能は必須だと思います。目的地にはずばっと行きたい。

 すでに上のような検索窓は現在の電子書籍リーダーでも備えています。しかし、WordやPDFリーダーの検索機能のようにヒットした結果を順番に見ていくという本当にただのテキスト全文検索なものが多くてあまり使う気になりません。

 検索といったら、やはり以下のように検索結果を一覧してほしい。できれば、読者にとって重要な順番で、というと曖昧ですが、線やコメントつけたものを上位に上げる、すでに読んだ部分を上位に上げる、逆に未読な部分を上位にあげるとかいろいろあると思うんです。今読んでいる箇所に関係が深い順とかでもいい。もっとソーシャルでもいいし、PageRankでもいい。

 ちなみに上では今開いている本の検索結果を一覧していますが、同時に今開いている本やライブラリに登録されている本を検索してくれるとさらに嬉しい。上の図でもアンダーラインに靑地とかで表示してそれっぽく見せていますが、リンクが貼られて自由に検索結果を行き来できるとよいですね!
 
 

○電子書籍でパラパラページめくるのとか厳しいのでスクロールできるようにしてください

 紙の書籍だとページをぱらぱらめくりながら、内容をざっと確認しつつ、目的のページに移動とか簡単にできますが、全く同じことを電子書籍でやるのはビジュアル的にはともかう、実用的ではないと思います。それで、紙の「ぱらぱら」の代わりにスクロールはどうでしょうかと。
 
 コンテンツの遷移の方法にもいろいろありますが、ここではスクロールとページングの2つを比較してみたいと思います。完全に主観ですが、この2つ、こんな違いがあるんじゃないかと。

・スクロール
 コンテンツの内容を確認しながらすばやく遷移することができる。しかし、スクロールするとコンテンツ全体が動くので、次に目で追うべき文字を一瞬見失う、もしくは見失わないような注意が必要になる。コンテンツを遷移する度に感じる小さなストレスは長い文章をじっくり読みたい時には堪えるかもしれません。しかし、まるごとコンテンツが入れ替わるページングと異なり、少しずつコンテンツが遷移していくので、コンテンツの前後の確認がしやすいことは大きな利点です。

 段落の間は空けましょうとか、フォントサイズに強弱つけるなどのWebならではの文章作法はスクロールしながらでの読みやすさを追求した故かもしれません。 

 

・ページング
 ページングとはコンテンツを1ページ単位で分割して表示する方法です。つまり、1スクリーン単位でコンテンツを分割し、次のコンテンツに遷移する場合は今表示しているコンテンツと続きのコンテンツとまるごと入れ替えることになります。コンテンツの次の開始点が縦書なら右上、横書なら左上と決まっているのでページが切り替わっても次に目で追うべき文字を探す必要がないので、スクロールで感じるようなストレスはあまりない(はず)。長文をじっくり読むことに向いていると思います。

 iPadのInstapaperアプリがスクロールとページネーション、どちらも使えるようになっているのでiPadをお持ちの方は試されると面白いかもしれません。
  
 つまり、

  • じっくり読みたいときはページング
  • 紙の本のようにパラパラ内容を確認しながらすばやくコンテンツを遷移させたい場合はスクロール

がよいのではないかと。だから、電子書籍リーダーには両方使えるようにしてほしいと思うのです。 
 
 
 

○現時点でのまとめ

 つまり、これまで上げたUIについてまとめると 

  • ブラウザのUIを取り入れてください。 
  • Webのナビゲーションも取り入れてください。

となります。こういうことを書くと、  
 
 

電子書籍はいずれWebに吸収されるとでも考えているのだろう
 
 
とか言われそうですね。しかし・・

「Webが…今のままでずっといると思うなよ……!!」
「電子書籍が…今のままでいると思うなよ……!!」

 ということで、電子書籍がWebに吸収されるという考えを持っていると思われるのは私の本意ではありません。Webも電子書籍も今後、その有り様から変わっていくだろうと考えていますので、どちらか一方がそのまま残って片方を吸収するということはないのではないかと考えています。

しかし、UI的には電子書籍はブラウザやWebに学ぶところが多々あるはずです。紙の書籍と電子書籍とUI的観点から比較して今でもはっきり言えることは、 
 

電子書籍には物理的なUIがない
 

ということです。 

 紙の書籍には本の厚さ、紙質、本の重さ、さらにいうとコンテンツに特化した装幀などがあります。コンテンツに直接触ることができるUIを持っているのです。それを前提としての紙の書籍のUIなのですが、電子書籍にはそれがありません(紙の書籍のUIについては一度別のブログで書きました)。電子書籍はナビゲーションを1つのスクリーン上で実現しなくてはならない。物理的なUIを持つ紙の書籍のUIを真似てはいろいろと足りないというのはそういう理由です。

 物理的なUIは使えない、1つのスクリーン上で全てを実現しなくてはならないという点ではWebも共通しています。ならば、そのWebの閲覧ソフトであるブラウザ、そしてコンテンツであるWebには学ぶべき点は多いのではないかと思うのです。Webブラウザは1つのスクリーンですべてのナビゲーションを実現しなければならないという制約下で20年以上試行錯誤してきたわけですから。 
 

※上の図で書籍の本文の一例として使用させていただいた書籍

河口慧海『チベット旅行記』(青空文庫)より
宮本百合子『しかし昔にはかえらない』(青空文庫)