HTML5.1 W3C Working Draft 08 October 2015

Table of Contents

1 Introduction 1.1 Background 1.2 Audience 1.3 Scope 1.4 History 1.5 Design notes 1.5.1 Serialisability of script execution 1.5.2 Compliance with other specifications 1.5.3 Extensibility 1.6 HTML vs XHTML 1.7 Structure of this specification 1.7.1 How to read this specification 1.7.2 Typographic conventions 1.8 Privacy concerns 1.8.1 Cross-site communication 1.9 A quick introduction to HTML 1.9.1 Writing secure applications with HTML 1.9.2 Common pitfalls to avoid when using the scripting APIs 1.9.3 How to catch mistakes when writing HTML: validators and conformance checkers 1.10 Conformance requirements for authors 1.10.1 Presentational markup 1.10.2 Syntax errors 1.10.3 Restrictions on content models and on attribute values 1.11 Suggested reading 1.12 About this document

HTML5.1 W3C Working Draft 08 October 2015

　HTMLは、World Wide Webの中核マークアップ言語です。もともとはHTMLは主に科学的な文書を記述するための言語として設計されました。しかしながらその設計は、ドキュメント、さらに他のタイプのアプリケーションの言語を記述するためにその後の数年間にわたってさまざまな用途に適合させて仕様することができるようになりました。

　このセクションは未標準の文書です。この仕様は文書や実装の正しさを定義づけであり、この仕様で定義された機能を使用するドキュメントとスクリプトの作者のための定義、この仕様で定義された機能を使用するページ上で動作するツールの実装の定義、および個人の際と作成者のための定義を対象としてこの仕様の要件を記述しています。 　このドキュメントは環境によっては完全性を求めた精度と簡潔さを明確に示していないため、ウェブ技術に親しみを持っていないユーザーに適合しません。その場合はもっと親しみやすいチュートリアルやオーサリングガイドを使用したトピックの文書をご確認下さいますようお願い致します。 　具体的にはDOMの基礎に精通するためには、本明細書の技術的な箇所をを完全に理解することが必要です。 しかしながらウェブIDL、HTTP、XML、ユニコード、文字エンコーディング、JavaScript、およびCSSの理解は有用でありますが必須ではありませんのでご容赦下さい。

　このセクションは未標準の文書です。この仕様はアクセスしやすいページのために静的なドキュメントからダイナミックなアプリケーションまで及び、ウェブでAPIに文書を書きながら、マークアップ言語と関連項目を提供することに制限されます。 　この仕様の範囲は、プレゼンテーションのメディア特有にむけたカスタマイズのメカニズムを提供することは含んでいません。(デフォルトでウェブブラウザのための表現規則はこの仕様の終わりの箇所に含まれており、言語の一部としてCSSを適用するいくつかの仕様は提供しています。）この仕様の範囲は全体のオペレーティングシステムを対象に記述してはおりませんのでご了承下さいますようお願い致します。 　特定のハードウェア・コンフィギュレーションソフトウェア、映像操作ツール、およびユーザが上位ワークステーションで使用すると予想されるアプリケーションにつきましては範囲外です。この仕様は主にこの基礎に基づきユーザに使用されると予想されるアプリケーションの言語記述を対象とします。そのようなアプリケーションに関する例としてオンライン購入システム、システムやゲーム(特にマルチプレーヤーオンラインゲーム)、公衆電話アドレスブックやアドレス帳、コミュニケーションソフトウェア(インスタントメッセージングクライアント、議論ソフトウェア)、ドキュメント編集ソフトウェアが存在しています。

　このセクションは未標準の文書です。 　HTMLは最初の5年(1990-1995)は多くの改正に直面しながらCERNやIETFで主として主催された数多くの機会を得て拡大していくことになります。W3Cの創造によってHTML開発は再び会場を変えています。続く年の1995年にHTML 3.0として知られたHTML構造文書の最初のドラフトによる拡大は、後に続く1997年HTML4に昇華することになるHTML 3.2として実際的なアプローチへの道を作りました。翌年、W3Cの会員がHTMLを一時進化停止して代わりにXHTMLと呼ばれるXMLベースと同等の構造文書の作業を開始しています。 　この試みはXMLでHTML4の再定式化から始まり、XHTML1.0として知られることになります。XHTMLは新機能を全く加えていないドキュメントで2000年に完成しています。XHTML1.0発表の後にW3Cのメンバーは他のワーキンググループがXHTMLの拡張をより簡単にするためにXHTML Modularizationの旗の下に進化を遂げます。 　その後W3Cは以前のHTMLとXHTML言語と互換性がない新しい言語の構造化に取り組み、XHTML2と記載しました。 　さて一方でHTMLの進化は1998年に停止されたのち、ブラウザベンダーによって開発されたHTMLのためのAPIの一部がDOMレベル1およびDOMレベル2コアとDOMレベル2という名の元に指定されたことで2003年に最高潮に達します。その後これらの試みは2004年に公開されたいくつかのDOM Level 3の仕様に到達したことですべてのレベル3の草案が完成される前にワーキンググループを一度解散となりました。 　2003年にはXFormsの出版物、Webフォームの次世代の技術としてHTML自体を進化させるのではなく代替品を見つけることに新たな関心を巻き起こしています。この関心はWeb技術としてXMLの展開が（RSS以降アトムなど）、既存の展開テクノロジの代替として全く新しい技術に限定されていたという認識から創出されました。 　XForms1.0で既存のHTMLウェブページと非互換であったレンタリングエンジンをを紹介したブラウザの特徴の多くを提供したことはHTML4のフォームを拡張することが可能であったのを示す証拠となる概念の結果になりました。 　ブラウザを必要とすることなしに既存のHTML Webページと互換性がなかったレンダリングエンジンを実装するためにXForms1.0が導入したこの機能を提供したことは、HTML4のフォームを拡張することが可能であったことを示すためのコンセプトの概念となりこの新たな関心の発端になっています。 　HTMLの進化を再開すべきであるという考えは2004年にW3Cワークショップにて試行されました。そこでは、まさしくフォーム関連の特徴をカバーする前述の試みと同様にHTML5ワークの基礎となる原則のいくつかがMozillaとOperaによって共同でW3Cに提示されました。(以下で、説明されます) 　その後まもなく、WHATWGと呼ばれる団体による主催にてアップル、Mozilla、およびOperaによる共同ワーキングで研究を続ける彼らの意図を発表しました。パブリックのメーリングリストは作成されそして、草稿はWHATWGサイトに移管されました。著作権は、仕様の再利用をすべての3つの業者によって共同で所有されて、許諾することに修正されています。 　WHATWGは特に、後方技術が必要であるといういくつかのコア原則に基づきました。これは実現よりむしろ仕様及び実現が互いをリバースエンジニアしないで完全な相互運用性を実現できるくらい詳細な仕様の必要性を変えることを意味しても、その仕様と実現は合致している必要があります。 　特にその要件は、HTML5仕様の範囲が以前にHTML4、XHTML1、およびDOM2HTMLのそれぞれのドキュメントで指定されたことを含んでいることを必要としました。また、以前に標準であると考えられたそれは、その他の詳細を更に含んでいることを意味しました。 　結局W3Cは2006年にHTML5の開発に参加するために関心を示して、2007年にHTML5仕様の開発でのWHATWGと共に働くためにチャーターされたワーキンググループを形成しました。 　それほど制限されていないライセンスがWHATWGサイトにある状態にある間、アップル、Mozilla、およびOperaはW3CにW3C著作権の下で仕様を発表させました。 　其の後多年にわたり、両方のグループはそれまでと同様のエディタのIan Hickson氏と共で一緒に働くことになります。 　2011年にグループの各社には異なった目標を持つ結論に達します。WHATWGはHTMLのために絶え間なく試みを続け仕様を維持しながら新機能を加えることで実用的な標準化を目的としたHTML5推奨の機能のために線を引くことを希望しました。 　W3Cは2012年中頃にはHTML5 Recommendationを創作をし続けながら、次のHTMLバージョンのために作業草案を準備するために新しい編集チームを導入しました。その結果2014年に、HTML5はRecommendationを発表することに到達します。 　発表されたドキュメントでは、本書では指定されたHTMLとHTML4仕様で説明された文書の違いを記録するために発表されています

1.5 Design notes―デザインノート―

　このセクションは未標準文書です。HTMLの多くのケースが無意味であって矛盾しているように一見したところでは見えることがあることを認めなければなりません。HTMLはHTML技術やDOM APIを支持する方々の数10年間の期間にわたって異なったプライオリティをもっている互いの存在を知らない人々同士の広いつながりによって開発され進化してています。 　この機能は多くのソースから起動して常に一貫した方法で設計されるというわけではありません。更にウェブのユニークな特性のために、実現するバグはしばしば「デファクト」になっていきました。 そして、現在法律上的に規格であり、内容が方法でしばしば何気なく書かれているとき、それらを修理する前にそれらを頼りにします。このドキュメントはこのすべてにもかかわらず、ある一定のデザイン目標を固く守ること誓い草案されました。これらは次の文章で説明されます。

　マルチスレッド化、HTML、およびDOMの複雑さでウェブ作者が非難を受けないように、HTMLとDOM APIはスクリプトの同時実行を検出できないように設計されています。ワーキンググループのワーカーのその意図は同時実行の動作がすべてのブラウジング文脈における全てのスクリプト実行に完全にシリアライズするという考えです。 navigator.yieldForStorageUpdates() 例えばこのモデルで呼びだされるスクリプトが妨げられている間に他のスクリプトの起動を許可することです。

　このセクションは未標準文書です。この仕様は他のさまざまな仕様と相互作用しながら依存しています。残念ながらある特定の状況では、相反する要求はこれらの他の仕様の要件に矛盾する仕様であるかもしれません。その場合のその矛盾は「意図的な矛盾」として理由は記載してそれぞれ記述されてきています。

　HTMLには安全に意味論をつけ加えることのできる伸張性メカニズムによる幅広さがあります。 �@要素について拡張するためにクラス属性を使用できます。事実上、未知数のブラウザ拡張と他のツールが支援できる可能性を持つように、最も適切な既存の「本当」のHTML要素を使用している間、それら自身の要素を作成することを可能にしています。 �Aインラインクライアントサイドスクリプトかサーバサイドのサイト全体のスクリプトがDATA -*=""属性を使用することで処理されるためのデータを入れることができます。これらはブラウザ側で抵触しないように保証されており、スクリプトが次にスクリプトを探すことができるHTML要素とそのプロセスに関するデータを含むことを許容します。 �B事前に定義されたセットのメタデータ名に<meta name="" content=""> メカニズムによってページ拡張のためのメタデータを含むことを許容します。 �C事前に定義されたセットのリンクタイプの拡張として特定の意味とのリンクを注釈するのに<rel="">メカニズムを使用できます。 �Dさらに絶対URLには非ASCII文字を含まないキャラクター又はU+0041(LATIN CAPITAL LETTER A)からU+005A(LATIN CAPITAL LETTER Z)はリンクタイプとして使用されること可能にしています。 �E作者はインラインやサーバサイドスクリプトの扱いとしてカスタムタイプで<script type="">メカニズムを使用した埋め込みを使用することが可能です。 �Fプラグイン作成と埋め込み要素を使用したプラグインの呼び出しを使用することができます。 �GJavaScriptプロトタイピングメカニズムを使用することでAPIを拡張することができます。 これはスクリプトライブラリによって広く使用されます。 �H他のアプリケーションやサイトと共有するために組み込まれた名前のデータを埋め込みとして「the itemscope="" and itemprop="" attributes」などのmicrodata機能を使用できます。

　このセクションは未標準文書です。この仕様は、ドキュメントとアプリケーションについて説明するために抽象的な言語とメモリ上での言語に使用するリソース表現と相互作用するためのいくつかのAPIを定義します。 　メモリにおける表現は「DOM HTML」、または略して「DOM」として知られています。この仕様に基づきこの抽象的な言語を使用するリソースを伝えるのに定義される様々な具体的な構文があります。一つ目の具体的な構文はHTML構文です。これはほとんどの作者のために示された定例書式です。それはほとんどの従来のウェブブラウザと互換性があります。ドキュメントがtext/html MIME タイプで伝えられると、それはウェブブラウザによってHTMLドキュメントとして処理されるでしょう。この仕様は単に「HTML」として知られている最新のHTML構文を定義します。2番目の具象構文はXHTML構文です。(その構文はXMLのアプリケーションです)。ドキュメントがapplication/xhtml+xmlなどのXML MIMEの種類で伝えられると、XMLプロセッサによって解析されるように、それはウェブブラウザによってXMLドキュメントとして扱われます。 　ここで創作者はXMLとHTMLのための処理が異なるのを考えなければなりません。構文誤りがあったとしてもXMLとして分類されたドキュメントが完全に表示されるないことはありますが、それはHTML構文としては認識されません。この仕様は単に"XHTML"として知られている最新のXHTML構文を定義します。 　またDOM、HTML構文、およびXHTML構文は同じコンテンツにすべての構文を表現することはできません。例えば、HTML構文を使用して名前空間を表示することはできませんがDOMとXHTML構文でサポートされます。同様に、noscriptの機能を使用するドキュメントはHTML構文を使用することで表すことができますが、DOMかXHTML構文で示すことはできません。 ストリングを含むコメントとしての「-->」は HTMLとXHTML構文に表現することはできませんが、DOMでは表現することができます。

　このセクションは未標準文書です。この仕様は以下の主要なセクションに分割されます。 �@Introduction 　HTML規格のため文章を提供する未標準リソース。 �A一般的なインフラストラクチャ 　順応のクラス、アルゴリズム、定義、その他の仕様の一般的な基礎。 �BHTMLドキュメント解釈、構造、およびAPI 　ドキュメントは要素から造られます。これらの要素は、DOMを使用することでツリーを形成します。 このセクションはすべての要素に共通の特徴、および要素を定義する際に使用される概念を紹介することと同様にこのDOMの特徴を定義します。このセクションはすべての要素に共通の特徴、および要素を定義する際に使用される概念と同様にこのDOMの特徴を定義します。 �Cユーザ相互作用 　HTMLドキュメントはユーザにドキュメント内容に相互作用してコンテンツを変更する多くのメカニズムを提供し マウスフォーカスによるコンテンツ変更、ドラッグ・アンド・ドロップでのコンテンツ変更などはこのセクションで説明されます。 �Dローディングウェブページ 　HTMLドキュメントは真空に存在していません。 このセクションはウェブアプリケーションのウェブブラウザやオフラインキャッシュのように複数のページを扱う環境に影響する多くの機能を定義します。 �EウェブアプリケーションAPI 　このセクションはHTMLにおけるアプリケーションスクリプティングの基本機能を紹介します。 �FHTML構文 �GXHTML構文 　このセクションはそれらの構文を使用することでどう内容を解釈するかといった規則と共にHTMLとXHTMLの構文を定義します。 �Hレンダリング 　このセクションはウェブブラウザのためにデフォルト表現規則を定義します。 cf その他、いくつかのインデックスリストをリストアップした定義済みの機能、IANAの考慮、付随する項目等