語彙は1つで2つの構文を持つ HTML 5
そもそも…
なぜ新たな HTML なのか?
XHTML には何が起ったのか?
HTML 5 では何か解決されるのか?
ユーザエージェント (UA) 間におけるアプリケーションの相互運用性問題
HTML 5 仕様では、ブラウザだけでなく、仕様への適合性検証ツールもユーザエージェントとして言及しています。
ただし、HTML 5 仕様では、ブラウザ間での相互運用性を確保するための要件を定義することに主眼を置いています。
W3C ではこれまで HTML や DOM のブラウザにおける相互運用可能な処理方法を詳細には規定していませんでした。
適合性が確保されたユーザエージェントやブラウザの挙動を
規定します。
HTML 4 や XHTML 1 では、 これまでユーザエージェントやブラウザの挙動を、的確に、徹底的に、かつ、厳密には規定しようとはしていませんでした。一方、 HTML 5 や XHTML 2 では仕様設計において、 HTML 4 や XHTML 1 とは異なる目標を設定しています。
HTML 5 は、 HTML の記述方法 (マークアップ) と DOM に関し、適合性が確保されたアプリケーションの挙動を 的確に、徹底的に、かつ、厳密に記述し、 純粋に機能毎に仕様を定義する最初の仕様となります。
これは、アプリケーション機能毎に定義した他の業界仕様と同様です。
…以前の HTML 仕様では、 機能毎の仕様記述に対する業界ニーズを満たせなかったでしょう…
HTML 5 仕様に関心を払うだけで、 HTML 5 への 適合性が確保されたユーザエージェントやブラウザの実装が可能になります。
HTML 5 は
text/html を利用
XML/XHTML 構文で記述された
HTML 5 であれば、
複数の名前空間に属する要素も織り込んだ複合文書も記述できますが、
text/html に基づく場合は利用できません。
HTML 5 仕様において対象外となるのは?
HTML 5 では、 HTML 構文で記述されていても、 SGML としては扱われません。
http://validator.w3.org/ブラウザ側には SGML 解析器は実装されていませんので、 DTD に基づく検証も、その他の SGML 検証ルールにも従っていません。
そのかわり、HTML 解析に特化した解析器を実装しています。
HTML 5 では、XML 構文に基づく HTML を規定 していますが…
整形 (well-formed) された XML 構文のみの HTML だけに限定しているわけではありません。
text/html: 属性の記述方法次のいずれの記述も HTML に準拠しています
<input disabled><input value=yes><input type='checkbox'><input name="be evil">DOCTYPE 宣言<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><!doctype html><meta
http-equiv="Content-Type"
content="text/html;
charset=utf-8"><meta charset="utf-8">整形式 (well-formed) XML、つまり XHTML のみに HTML を限定しないのは何故でしょうか?
XML では全ての XHTML 文書に対し、厳密なエラー処理が求められます。
これは、XHTML で記述された如何なるページにも、些細なエラーですらあってはならないことを意味します。
このとき、ブラウザはページを一切描画してはいけません。
しかし、Web 上の 95% 以上の HTML コンテンツが XML 整形式ではないこともまた事実です。
それゆえに、「事実存在する」「巷にありふれた」、場合によっては「旧来からの」「滅茶苦茶な」HTML の相互運用可能な解析方法を規定する必要があります。
HTML 5 では、HTML に準拠したユーザエージェントやブラウザにおける HTML の厳密な解析方法 (既存のブラウザ実装にも酷似したアルゴリズム) を精緻かつ詳細に規定しています。
これには、application/xhtml+xml としてではなく、text/html として記述された XML 整形式ではない HTML の解析方法も含みます。
明確に機能毎に規定された仕様である HTML 5 におけるもう1つの重要な改定項目は、記述方法やそれ以外のあらゆるエラーの処理方法を正確に規定している点で、これにより、あらゆるユーザエージェントやブラウザにおいて相互運用可能な方法でエラー処理が行われます。
仕様書に準拠していない文書であろうと、相互運用性を確保するためにエラー処理方法を規定しなければならないということです。
仕様書の規定に関わらず、適正でない (invalid) コンテンツ記述もあり得るため、コンテンツ製作者が行ってはならないことを言明するとともに、それでもなおコンテンツ製作者が規定違反を行った場合の対処方法を実装者に提示します。
あらゆる既存のコンテンツを取り扱えるようにすることで
"Don't Break the Web" 「Web の分断を回避せよ」
public-html@w3.org メーリングリスト皆様の疑問にもお答えします。
CSS は HTML 5 でも HTML 4 や XHTML 1 同様に取り扱われます。CSS と HTML 5 は互いに独立した仕様であり、影響が及ぶことはありません。
少なくとも Apple、Google、Mozilla、Opera、
Microsoft、Nokia を始めとする多様な組織がこの標準化活動に積極的に参画しています。
改良されたフォーム、canvas や video 要素等、HTML 5 の新たな機能の幾つかは、Apple、Mozilla、Opera が提供するブラウザに既に実装されています。
ACCESS、Nokia、Apple (iPhone) といった携帯機器向けブラウザ企業も本作業部会に参画しています。
これらのことからも、ブラウザにおける HTML 5 採用の見込みは非常に高いと言えます。
コンテンツ製作ツールは、ブラウザ側で対応している機能への対応が必要不可欠であるため、コンテンツ製作ツールにおける採用の見込みも同様に非常に高いと言えます。
つまり、ブラウザ側での HTML 5 の採用が進めば、必然的にコンテンツ制作ツール側での採用も進むと考えられます。
HTML 5 の主要な設計目標の1つは、既存のコンテンツに対する後方互換性を確保するとともに、新たな機能を盛り込むことで、(それらの機能に対応できずに相対的に魅力を失う) 旧来のブラウザを「洗練された方法で淘汰させる」ことにあります。
コンテンツ提供者は、HTML 5 対応ブラウザによって既存のコンテンツの表示が崩れたり、表示できなくなったりすることはないため、コンテンツ「破壊」を回避するために、コンテンツ移行を行う必要はない。
http://html5.validator.nu/HTML 5 の新機軸
innerHTMLXmlHttpRequest…<input>新たに導入される要素
文書構成のために新たに導入される要素
<section><nav><article><aside><header><footer>canvas 要素: img 要素にスクリプト記述機能を追加
Y! Pipes などで利用されています。
<canvas width="150" height="200" id="demo">
<!-- fallback content here -->
</canvas>
<script type="text/javascript">
var canvas = document.getElementById("demo"),
context = canvas.getContext("2d")
context.fillStyle = "lime"
context.fillRect(0, 0, 150, 200)
</script>
<canvas> 利用例video 及び audio 要素例: 永続的なクライアント側データベース記憶域用 API
Google Gears 開発部門や Apple の技術者、Opera などのブラウザ事業者らによるメーリングリスト上での議論の結果、HTML 5 では Google Gears 同様の クライアント側データベース記憶域用 API を盛り込むことになりました。
Webkit 開発部門は、Google Gears 同様の HTML 5 クライアント側データベース記憶域用 API を WebKit へ初期実装したことを発表しています。
http://webkit.org/misc/DatabaseExample.html標準に準拠した Web アプリケーションであれば、どのようなブラウザ上でも同じように利用可能になるため、如何なる特定事業者の如何なる特定製品にも縛られることもなくなり、選択の自由を享受できます。
質疑応答 (日本語でどうぞ)