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