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”  
 
 

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に関するやりとり
 
 
 

W3Cで策定中のモバイル向けWebアプリを進化させるHTML5関連のデバイスAPI

 今、JavaScript関係の本を読みつつ、HTML5関係の本もぱらぱらと並行して読んでます。JavaScriptに対する理解がまだまだ全然なので、「サンプルコードとか、もう読むのが辛い・・」、「いや、もう、どんなこと書いてあるかその概要がざっと読めればいいや」、「いや、コードの気の流れが理解できればいいや」・・とハードルを下げ続けて現在に至ります。 といいつつも、HTML5面白いなあとほんわか感じています。
 
 Webアプリがネィティブアプリに機能的に近くなるのは、HTML+CSS+JavaScrptでできることが格段に増えるということで、Rubyを少しかじった程度のなんちゃってコーダー(笑)としては、「CやJavaを覚えずとも、JavaScriptでいけるんか!」とヘタレな感じですが、嬉しい限りです。とはいえ、現状ではWebアプリとネィティブアプリでは、以下のブログで紹介されているようにそれぞれ一長一短があるようです。
ネイティブアプリとウェブアプリ(Webアプリ)のメリット・デメリットまとめ – hachimitu blog
 しかし、上で言及されているようなカメラやセンサーなどのハードウェア固有の機能を操作できないというWebアプリの欠点は将来的に解消されていくのかもと思わせる仕様の検討がW3Cでされているようです。W3Cで検討されている仕様は膨大にあって、私はTwitterで流れてくる情報を追うのが精一杯ですが、その中で拾えた仕様のいくつかをまとめてみました。ちなみにここではいくつもものW3Cの仕様を紹介していますが、私はまだ読んでません(汗)。これからこういうのを読みたいという思いでまとめたという意味もありますのでご容赦ください。ここで書かれている事に対する間違い等のご指摘は大歓迎です。

■DeviceOrientation Event Specification

 デバイスの向きや動きに関する情報のDOMを定義している仕様です。つまり、デバイスの向きや動きを探知するセンサーをつかっていろいろとできる仕様のようです。とまあ、ちょっと知ったかぶってみましたが、後述の羽田野太巳(@futomi)さんのツィートでその存在を初めて知りました。
DeviceOrientation Event Specification
http://dev.w3.org/geo/api/spec-source-orientation.html 
 この仕様はまだEditor’s Draftの段階でまだまだ確定にほど遠いはずなんですが、HTML5.JPの羽田野太巳(@futomi)さんによる10月15日付けの以下のツィートによるとiOSデバイスではすでに実装されているようです。時期的にiOS5アップデート後のSafariについて言及されているのだろうと思いますが、すごいですね。

 この仕様については日本の情報も比較的多い。 
ヅラッシュ! – Android 3.0 端末の傾きを JavaScript Device Orientation で取得するサンプル
DeviceOrientation Eventでシェイク!iPhoneウェブアプリで使ってみる | 岡山のウェブサイト制作プロダクション “ニイハチヨンサン” のブログ
Chromeでも加速度センサー(DeviceOrientation Event)が使える様になってたみたい – 強火で進め
 
 

■WebRTC 1.0: Real-time Communication Between Browsers

 
音声や動画のリアルタイム通信機能を行うための仕様が以下のWebRTCという仕様で、Skypeのようなチャットなどに使われることを想定しているようです。カメラ、ビデオカメラ、マイクロフォンなどデバイスのインターフェイスから得た情報をHTML5に対応したブラウザで扱うことができるAPIらしい。まだEditor’s Draftの段階で、実装しているブラウザは後述の秋葉秀樹(@Hidetaro7)さんが紹介するAndroid用の開発版Opera Mobileぐらいなのでしょうか?
WebRTC 1.0: Real-time Communication Between Browsers
http://dev.w3.org/2011/webrtc/editor/webrtc.html
Chromeブラウザ初の「WebRTC」実装発表 – JavaScript/HTML5でIMを簡単開発 | エンタープライズ | マイコミジャーナル
MozillaがWebRTCグループ参加を正式表明~Firefoxへの統合も視野に -INTERNET Watch
HTML5ブラウザで音声や動画のリアルタイム通信機能「WebRTC」 :: dotHTML5
 
 この仕様は秋葉秀樹(@Hidetaro7)さんの以下のブログのエントリでその存在を初めて知りましたが、そのエントリで紹介されているようにカメラアプリなどの開発に活用することもできるようです。個人的にはチャットよりもこちらのほうが興味深いので、このエントリでも紹介させていただきました。 
HTML5でつくるカメラ&落書きアプリ(中国GTUGハッカソンで発表) | 秋葉秀樹個人ブログ 
HTML5-WEST.jp 勉強会「HTMLでつくるカメラ&落書きアプリ」フォローアップ | 秋葉秀樹個人ブログ
 

■Device APIs Working Groupが策定を進めている仕様群

 W3CのDevice APIs Working Groupが策定を進めているAPIの仕様群です。面倒ですが、”Priority APIs”と”Other”に挙げられているAPIで仕様がドラフトでも公開されているものを自分の勉強がてら以下にリスト化してみます。以下で全部ではもちろんありません。詳しくはDevice APIs Working Groupのサイトをご覧ください。デバイス関係だけでいろいろなAPIがありますねぇ・・・・。
Priority APIs
Battery Status Events(2011/10/18時点でPublic Working draft)
Contacts API(reading from addressbook)(2011/10/18時点でLast Call)
HTML Media Capture(2011/10/18時点でPublic Working draft)
The Messaging API(SMS, MMS, emails)(2011/10/18時点でPublic Working draft)
The Network Information API(2011/10/18時点でPublic Working draft) 
Other
Calendar API(2011/10/18時点でPublic Working draft)
Feature Permissions(2011/10/18時点でEditor’s Draft)
The Media Capture API (programmatic access to camera/microphone)(2011/10/18時点でPublic Working draft)
Sensor API Specification(2011/10/18時点でEditor’s Draft)
Permissions for Device API Access(2011/10/18時点でPublic Working draft)
  
 仕様を読んでいないのでよくわかりませんが、ここで検討されているHTML Media CaptureThe Media Capture APIを使ってでも将来的にカメラアプリやビデオカメラアプリなどのWebアプリが作れたりするのでしょうか。その辺、もう少し勉強してみたいところです。
 ”Other”にあるSensor API Specificationはデバイスが持つ様々なセンサーが提供する情報にアクセスするためのAPIを定めた全般的な仕様のようです。最初に紹介した”DeviceOrientation Event Specification“やGeolocation APIなどの上位にくる仕様ということでしょうか?デバイスがもついろいろなセンサーを活用することができるAPIの仕様のようです。センサーやカメラなどハードウェアが持つ機能をHTML5対応のブラウザからアクセスしたり、操作したりできるようになるといよいよ面白くなりそうですね。 
 

■さらにスコープを拡げて>Ubiquitous Web Applications Activity

 これまで紹介した仕様はUbiquitous Web Applications Activity下のWorking Group(分科会)で検討されている仕様です。他にもいろいろとありそう。じっくり調べてみたいところです。
Ubiquitous Web Applications Activity
http://www.w3.org/2007/uwa/Activity.html