WHATWG FAQ

一部、直訳ではなく意訳した部分がございます。原文と表現が異なることがございますので、ご了承ください。この日本語訳は、私が理解を深めるために、自分なりに日本語化したものです。本日本語訳には、翻訳上の誤りがある可能性があります。したがって、内容について一切保証をするものではありません。正確さを求める場合には、必ず原文を参照してください。当方は、この文書によって利用者が被るいかなる損害の責任を負いません。もし誤りなどを見つけたら、当サイトのお問い合わせより連絡いただければ幸いです。

概要

WHATWGが公開しているHTML5のFAQです。HTML5の目的や存在意義といった大枠の話から、要素の記述方法といった細かい話まで、さまざまな方面の疑問に答えています。

Contents

WHATWG

WHATWG とは何ですか？

ウェブ・ハイパーテキスト・アプリケーション・テクノロジー・ワーキング・グループ（WHATWG）は、ウェブの発展に関心を持った人々の成長中のコミュニティーです。主に HTML と Web アプリケーションに必要な API の開発にフォーカスしています。

WHATWG は 2004 年に W3C ワークショップの後に、Apple、Mozilla Foundation、Opera Software の個人によって設立されました。Apple、Mozilla、Opera は、W3C の XHTML の方向性、HTML への関心の欠如、現実のウェブ制作者のニーズに対する明らかな無関心について、ますます憂慮するに至りました。そのため、3 社はこれらの憂慮を解決するミッションに乗り出しました。そして、the Web Hypertext Application Technology Working Group が誕生しました。

WHATWG は何に取り組んでいるのですか？

WHATWG は主に HTML 標準にフォーカスしています。WHATWG は Web Workers、Web Storage、Web Sockets API、Server-Sent Events にも取り組んでいます。時には、WHATWG の領域外の仕様が、WHATWG メーリングリストで議論されることもありますが、適切なところがあれば、転送することもあります。

以前は、Web Forms 2.0 と Web Controls 1.0 にも取り組んでいました。Web Forms 2.0 は HTML5 に統合されました。Web Controls 1.0 は今のところは中断され、XBL 2.0 が 我々に何をもたらすかを待つこととなりました。

どうやったら参加できますか？

多くの参加方法があります。What you can do をご覧ください！

無料で参加できますか？

はい。誰でも貢献することができます。参加にあたり、会員費用は必要はなく、手続きが公開されています。簡単に WHATWG メーリングリスト に申し込むことができます。また、やや長い申込手続にはなりますが、W3C の新たな HTMLWG に参加することもできます。

WHATWG のプロセス

WHATWG はどうやって活動しているのですか？

メーリングリストにメールを送ります。エディタは、そのフィードバックを読み、調査や研究を行い、多くの他のリソース（ブログ、フォーラム、IRC など）からのフィードバックをもとに検討し、言語一貫性を保ちつつ、可能な限りみんなのニーズをくみ取りながら言語設計を決断します。

これは、フィードバックが送信されるたびに繰り返されます。そしてエディタがもう仕様を変更する必要がないと納得するまで続きます（たとえば、二人が相反することを求めると、エディタは入手可能なすべての情報を考慮し、二つの提案のどちらが良いかを決定します）。

これは大多数の合意に基づくアプローチではありません。みんながハッピー！となる保証はまたくありません。また投票もありません。

もしエディタが悪い決定を下し始めたら、そのエディタを失効、交代させる権限を持った小さな監視委員会（"WHATWG members"として知られています。charter をご覧ください。）があります。

現在のエディタは Ian Hickson です。

ツール開発者、スクリーン・リーダー開発者、ブラウザ・ベンダー、検索エンジン・ベンダー、そのほかの実装者は、どのようにWHATWGとかかわるべきですか？

機能に関するフィードバックは、whatwg@whatwg.org （事前にメーリングリストに参加しなければいけません。）または ian@hixie.ch に送ってください。すべてのフィードバックはしばらくすると返信されます。

たとえば、あなたがその機能に取り組もうとしており、以前のすべてのフィードバックを考慮するために仕様をアップデートする必要があるといった理由から、"しばらく" たってからではなく、できる限り早く取り扱ってもらいたい場合は、エディタ（ian@hixie.ch）にもメールを送って知らせるか、または IRC （Freenode では Hixie）で彼にコンタクトしてください。優先的なフィードバックの取り扱いのリクエストは、内密に扱われます。あなたがその機能に取り組んでいることを、他のブラウザベンダーが知ることはありません。

明確化のための質問やリクエストは、メーリングリストや IRC （Freenode の #whatwg チャンネル）で訪ねてください。

仕様から悪いアイデアを削除するプロセスはありますか？

仕様から雑草を引っこ抜くプロセスがいくつかあります。

  • 日頃から、特にはっきりとコメントが求められれば、我々はすべてのセクションをくまなく調べ、削除の必要があるものとして印を付けます。これは、たとえば、2008 年のはじめに、データ・テンプレート、反復ブロック、DFN要素の相互参照で、起こりました。そのような機能を保ち続けるべき強力な理由を我々に与えるようなフィードバックがなければ、それらは最終的にまとめて削除されます。
  • 誰でも機能の削除を要求することができます。：そのようなフィードバックは、他のすべてのフィードバックのように扱われます。そして、提出された根拠のメリットに基づきます。
  • ブラウザが広く機能を実装していないなら、または、ウェブ制作者が機能を使わないなら、または、その機能の利用が論理的ではなく、根本的に間違っており、損害を与えるようであれば、検討の上、その機能は削除されます。

機能の削除は、仕様の開発では重要な部分です。

仕様に新たな機能を追加するプロセスはありますか？

このプロセスはかなり変則的ですが、基本的には、要約すると以下の通りです：

  1. ウェブ制作者や実装者とその問題を議論して、利用事例と要件を調査してください。
  2. 解決すべき問題の明確な説明を考えてください。
  3. あなたの提案を、ウェブ制作者や実装者と議論してください。返信を読み、フィードバックに耳を傾けてください。あなたのアイデアが、利用事例や要件にとって良い解決方法なのかを検討してください。ここでの議論は、公開で行うべきです。たとえば、アーカイブされる公開メーリングリストや、ブログで明文化するなど。
  4. 実装者に、その機能を実装することをコミットしてもらってください。もしあなたが複数の実装者にその機能を実装してもらうことができないなら、実験的に最低でも一つのユーザーエージェントに実装してもらうようにしてください。実験的な実装は、公式に利用可能でなければいけません。
  5. その実験的な実装が、この仕様のエディタに注目してもらうようにしてください。その経験から得た情報を文書化して、あらゆる実装者に分かるようにしてください。利用事例、初期段階で発見された要件、その設計が拠り所にしているデータです。
  6. その問題の重要性をデモンストレーションしてください。その解決策が、当初の問題を解決するのに十分に正しく、そして広く使われるものとなることを、デモンストレーションしてください。
  7. その後も引き続き、その提案のすべてを慎重に検討して、その設計の議論に加わってください。通常は、この段階で、当初の設計は破棄され、本当により良い設計が開発されます。以前の調査、最新の調査、実装、実験的な実装を使ったウェブ制作者の経験によって、通知されます。場合よっては、そのアイデアはこの段階で破棄されることもあります。

アイデアが前述のプロセスを経て残ったなら、最終的に、仕様は、新たな設計を反映するようアップデートされます。その時点で、実装は新設計を反映するようアップデートされるでしょう（もしそうでなければ、それは、新設計が良くないことを意味しますので、その新設計は修正されるか、削除されるでしょう）。仕様は、ウェブ制作者や実装者によって発見された多くの問題を修正するようアップデートされます。何年もの期間をかけ、もっと多くのウェブ制作者や実装者がその設計を吟味することになります。最終的に、多くの実装が広まっていきます。この時点で、その機能の開発は、とりあえず、終了となります。

包括的なテスト・スイートを書くのも、とても重要なステップです。それは、仕様に書かれていることが実装される少し前に始めなければいけません。（テスト・スイートは、通常は、彼らが仕様を使ってするのと同じく、実装を使った多くの問題を見つけます。）わたしたちは、テスト・スイートに関して、いまだ、良い話を聞いたことがありません。あなたが私たちを助けてくれるなら、メーリングリストに知らせてほしい！けれども、それは多くの作業となるので、あしからず。

"生きている標準" とはどういう意味ですか？

WHATWG の仕様は、生きている標準と言われています。これは、ウェブ・デザイナー、ブラウザー・ベンダー、ツール・ベンダー、関連の団体などからフィードバックを受けるたびに更新されていく標準ということになります。また、新しい機能が徐々に追加されていきますが、そのペースは実装の一歩先のレベルにとどめ、実装が追いつかないほどに仕様だけが突っ走ることはありません。

継続的なメンテナンスにもかかわらず、もしくは、継続的なメンテナンスの一部として言った方が良いかもしれませんが、多くの努力が、仕様と実装を収束させることに注がれています。成熟し安定した仕様の一部が有無を言わせずに変更されることはありません。メンテナンスとは、仕様が山から切り出され、仕様を永久不変にする日々のことです。たとえ、すべてのブラウザーが別のことをするようになったとしてもです。または、仕様のいくつかの詳細部分がほったらかしになり、すべてのブラウザーがその実装方法に関して賛成せず、結局それが無くなったとしてもです。その代わり、我々は、すべての実装者（もちろんブラウザーに限りません）が同じ事ができるに足りる詳細を仕様に記載していきます。ブラウザーが何をしているのかを無視するのではなく、ブラウザーがしていることに一致するよう、仕様を修正します。我々は、仕様に不明瞭な部分を残さず、どうやったら動作するのかを定義し、仕様を修正します。

"生きている仕様" と聞くと、まるで、いつ変更されるか分からない、いつまで経っても終わらない、と思えてしまうのですが...

正確に言えば、そういうことです。しかし、仕様は自由気ままに変更されるわけではありません。我々は最大限の注意を払っています！仕様が成熟し、実装が世に出ているような部分であれば、セキュリティー問題といったよほど重大な理由がない限り、その部分の変更は行いません。仕様が完成することはありません。なぜなら、ウェブは絶えず発達するものだからです。HTML が "完成" したと言われたのは、HTML4 が最後でしたが、その後、何年も開発は止まってしまい、停滞を招いてしまいました。

仕様のどの部分が安定し、どの部分がそうでないかは、仕様の左側の余白のステータス注釈を見れば分かります。

ブラウザーは実装のゴールを持たなくても良いのですか？たとえ、それが勝手に決めたスナップショットだとしてもです。

実際に、すべての実装は、最新のスナップショットではなく、最新の仕様の草案に従ってきました。スナップショットに追随することの問題は、すでに間違っていると分かっていることまで従ってしまうという点です。これは明らかに相互運用性を損ないます。これは、実際に、W3C で本当に起こってきたことなのです！ミスが見つかり、仕様の editor's draft では修正されるのですが、このプロセスに深く関わっていない実装者は、廃止となったスナップショットを実装してしまい、そのバグを抱えてしまうのですが、その問題に気づくこともなく、他のブラウザーと異る結果となってしまうのです。

公式なステートメントに基づいて安全に仕様を実装できるのはいつになりそうですか？

本当の意味で安全になることはありません。例えば、もしあなたが HTML4 仕様に基づいて HTML4 を実装しようとしたとしても、HTML4 時代のドキュメントと互換性を持った実装にすることはできないでしょう。しかし、あなたが例えば、セキュリティー・アップデートや errata レベルの変更などのちょっとした変更を扱うことができるのであれば、仕様のどの部分が安定し、どの部分が安定していないかについては、仕様の左側の余白にあるステータス注釈を見れば分かります。

とはいえ、この開発の努力に参加することを強く進めます。実装者向けメーリングリストが役に立つでしょう。

ブラウザーが目指すことができる、そして、開発者が評価することができるスナップショットが無いのに、私たちは何を使うべきかをどうやって知るのですか？

スナップショットでやってきたのと同じです。ブラウザー・ベンダーは、最新のスナップショットを見ているのではなく、進展し続ける最新のテキストを見ているのです。

例えば、HTML4 のすべてを実装したブラウザーはありません。公式に勧告になってから何年も経っているというのに。HTML3.2 のすべてを実装を待ってから HTML4 の実装に取り掛かったわけでもありません。彼らは皆、役に立つと思ったものだけを取り上げたのです。生きている標準というアプローチでは、我々は、役に立たないと彼らみんなが賛成すれば削除し、追加すべきとみんなが賛成するなら新機能を追加するのです（彼らが自分の解決策を捨てたり発明する前にです！）。

仕様の本質とは、着地点を確立して、標準を実装するすべての関係者が確実に共通の互換性基準を持つことではないのですか？

いえ、仕様の要は、すべての団体が実装すべきことを正確に記述できていることです。エラーがこの記述に見つかったとき、それを放置するのでなく修正したほうが良いに決まっています。

HTML4 に例があります。HTML4 は、"media" 属性のデフォルト値は "screen" だと言っていますが、これはおかしくて、そのデフォルト値は "all" であるべき、ということは何年も前から言われています。すべてのブラウザーは "all" で実装しています。既知のバグがあるスナップショットは、生きている標準の有用性には及ばないのです。

この "生きている" HTML 標準の前のバージョンを、ブラウザーの中にサポートするのはどうですか？

ブラウザーに必要なのは最新の仕様を実装することです。この最新の仕様は、多くの過去のコンテンツと互換性を保ちます。それは、WHATWG の一貫した努力の根底にある理念です。

はっきりいうと、今日のブラウザー、HTML2、HTML3.2、HTML4 ごとにモードを分けて実装しているわけではありません。ひとつのバージョンの HTML を実装しているだけなのです。それで全てうまくいきます（我々は これを "後方互換性" と呼んでいます）。これは、HTML 仕様と同じモデルなのです。そう言う理由で、もう廃止された多くの古い機能に対するブラウザー要件まで定義しているのです。例えば、"font" 要素はすでに非準拠です（ウェブ制作者はページでそれを使ってはいけないことになっています）が、仕様ではまだそれの動作方法を定義してます。そのため、古いページでも問題がないのです。

ブラウザーは今後も古い HTML ドキュメントを理解してくれるのでしょうか？

ブラウザーは、HTML+、HTML2、HTML3.2、HTML4、HTML4.01 などのバージョンを分けて実装しているわけではありません。どのブラウザーでも、同時にすべてのバージョンをカバーできるような実装がひとつあるだけなのです。WHATWG HTML 仕様が定義していることは、まさにこれなのです。以前のすべてのバージョンの HTML を扱うブラウザー（他の実装も含めて）をどうやって書くのか、についてです。もちろん、最新の機能についてもすべてが対象です。

HTML 仕様と WHATWG の努力の目標のひとつは、今から何百年も後の考古学者が、この仕様がいつ書かれたかにかかわらず、ブラウザーを書き、HTML コンテンツを見ることができるようにすることなのです。我々があらゆるドキュメントを確実に扱えるようにすることが、我々の最重要目標のひとつなのです。バージョンがないからといって、これが妨げられることはありません。

これは、仕様に追加することだけできるが再定義できない、ということを意味しているのでしょうか？

はい。これは WHATWG の設立当初からの理念です。我々のチャーターにも書かれています。

ウェブ開発者は、どの機能なら安全に使えるのかを、どうやって知ることができますか？

"いつになったら、新機能を使うことができるようになりますか？" をご覧ください。

ブラウザーは、今のところは、HTML 4.01 を実装しており、期待すべき事を知っている、と言うことができるのですが。

実質的には、そのようなことは実際に起こっていません。ブラウザーは一度にひとつの仕様をアトミックに実装しているわけではありません。彼らは良いと思った機能を仕様から選択して取り上げているのです。例えば、過去を振り返ると、ブラウザーは CSS2 の絶対位置を実装しましたが、'display:run-in' を実装しませんでした。にもかかわらず、CSS2 を実装したとうたっています。そして、彼らは CSS3 の一部も実装していますが、CSS3 モジュールのいくつかは実装していません。ブラウザーは HTML4 を実装したとうたっていますが、そのすべてが実装されているわけではありません。ブラウザーは、HTML 3.2 のすべてを実装する前から HTML4 の機能に移ってしまいました。その他にもいろいろあります。

さらに、バグという問題があります。ブラウザーごとに異なるバグがありますが、ブラウザーがどんなバグを持っているのかを教えてくれるような仕様はありません。

従って、実際には、ベンダーの広報がサポートしていると言っているとしても、どの仕様のどのバージョンに基づいて何が実装されているのかは全く分かりません。だから、バージョン番号がなくても問題はないのです。どちらかといえば、結果的に意味がない比較を行わなければ大丈夫です。つまり、ブラウザーがどのバージョンをサポートしているとうたっているのか、ではなく、ブラウザーが本当は何をしているのか、を比較しなければいけない（テスト・スイートを使います）、ということなのです。

開発者は、自分のページの特定の部分がいつ妥当でなくなるのかを、どうやって見つけ出せば良いのですか？

古いページが妥当でなくなるのかどうか、また、それはいつなのかが問題になることはありません。

妥当性（WHATWG ではドキュメントの適合性という意味で使われます）とは、品質を保証する道具のひとつで、ウェブ制作者にミスを防ぐ役割があります。我々は、そういう意味で、非適合（妥当でない）にすることはありません。我々は、開発者が間違った使い方やミス（typo など）を避けることができるよう、開発者向けのガイドとして、適合性を使っています。そのため、古いページが適合しているかどうかについて心配する必要はまったくありません。最新のアドバイスが得られるのは、常に最良の助けとなります。例えば、先週の規則に対して準拠しているかをチェックすることに意味はありません。結局、我々は、それらのルールにミスがあれば、それを今週修正するのですから。

バージョン番号がなくなったら、何かが廃止や削除されるとき、どうなるのですか？

バージョン番号があったとしても、我々は機能を削除を止めるわけではありません。前述の "仕様から悪いアイデアを削除するプロセスはありますか？" の通り、我々は手続きに従ってそれを行います。

バージョン番号が無くなったら、HTML は、以前のように実装されない機能がどんどん膨れあがってしまい、面倒なことになってしまうのでしょうか？

いいえ。我々は HTML を実装されないものにならないよう努めています。もし実装されなかったら、仕様の意味がないということになります。実際に、HTML が実装されるということが、この仕様の主たる目標です。確かに、HTML は時間とともに複雑さを増していくでしょう。しかし、我々がバージョン番号を持つかどうかとは、関係がありません。

バージョン番号が無くなったら、HTML は、機能が削除され、以前は問題なかったドキュメントが突然にダメになってしまうような事態になってしまうのでしょうか？

いいえ。

機能が妥当でなくなったとしても、それが動作しなくなることはありません。ブラウザーは古い機能もサポートしなければいけないことにしているからです。"inindex"、フレームセット、"font" などのようなことですら、ウェブ制作者は使わないことになっていますが、HTML 仕様には今もなお規定されているのです。古いドキュメントは必ず妥当でなくなります。例えば、"font" 要素を使っている HTML 3.2 のドキュメントは、妥当な HTML4 Strict ドキュメントではありません。なぜなら、"font" は妥当でなくなったからです（大きな理由として、例えば、アクセシビリティを妨げる書き方になりやすいからです）。我々が特定の機能を無効にし続けたとしても、それが "ダメになってしまう事態" となることはありません。

もう今後はスナップショットを出さないということは、過去の過ちを現在と未来においても繰り返すという役割を認識しているわけですから、そう言う意味で、あなた方は全体主義的だ。

そんなことはありません。我々のブログでそれを言った人がいます。

この仕様のテキストは、バージョン・コントロールされており、無くなったわけではありません。実際に、バージョン・コントロールという考え方は、いつ変わったのか、なぜ変わったのかなどを把握するために、仕様開発の一部として良く使われています。これは、任意に日付けが付けられるスナップショットよりは、かなり役に立ちます。とはいえ、実際のところ、任意に日付が付けられるスナップショットについては、同じようには研究されていません。なぜなら、答えが良く分からないからです。スナップショットをどうやって発行するのかにもよりますが、バージョン・コントロールを使えば、特定の日時に発生した議論に範囲を絞ることができ、スナップショットを使えば、年月ごとの決議に限定されます。

http://html5.org/tools/web-apps-tracker (Web インタフェース) や http://svn.whatwg.org/webapps/ (SVN インタフェース)で、WHATWG 仕様のバージョン・コントロール・リポジトリを見ることができます。しかし、すべてのリビジョンやマイナーは、別々にチェックインされています。これを書いている時点（2011 年 1 月）では、このリポジトリはすでに 5700 以上ものリビジョンがあります。

（見方を変えれば、我々はすべての変更ごとに新たなスナップショットを作っている、と言うこともできます！ 彼らが言うように、早く、しかも、頻繁に発行します。）

HTML5

HTML5 とは何ですか？

HTML とは、WHATWG コミュニティーがメインでフォーカスしているものです。HTML5 とは、HTML のスナップショットです。これは、WHATWG コミュニティーと W3C HTML ワーキング・グループで作業されています。

HTML5 は、HTML4 と XHTML1 と DOM Level 2 HTML の新バージョンです。これらの仕様の多くの問題の解決に向け取り組んでいます。あわせて、Web アプリケーションをより適切に扱うことができるよう、(X)HTML を拡張しています。HTML と XML (XHTML5) のどちらでも書くことができるマークアップ言語を定義するだけでなく、Web アーキテクチャの基本的なところから多くの API も定義しています。これらの API のいくつかは "DOM Level 0" として知られているものですが、これまで一度も文書化されませんでした。いまだにそれらは、ブラウザベンダーが現存の Web コンテンツをサポートし、Web 制作者が Web アプリケーションを構築できるようにする上では、極めて重要です。

いずれは、WHATWG は、バージョン番号を付けない "HTML" について作業を行うことになります。WHATWG という文脈の中で HTML5 について話すなら、通常は、"HTML の最新版" という意味になり、必ずしも特定のバージョンを指すものではありません。詳細については、この仕様に書かれている "Is this HTML5?" の章をご覧ください。

どうやったら仕様の変更を追跡し続けられますか？

仕様の変更を追跡する方法はいくつかあります。

  • オンラインの HTML5 Tracker を使うことができます。このツールは、仕様のリビジョンを選択し比較できるオンライン・インタフェースを提供します。
  • この仕様は、subversion repository で利用可能です。SVN クライアントを使って最新バージョンを確認したり、クライアントの diff ツールを使ってリビジョンを比較したり、何が変更されたのかを調べることができます。
  • 広い領域では、Anne が、最新の HTML の変更点の全体像が記載されたドキュメントを管理しており、数ヶ月おきの変更点の一覧も掲載されています： http://dev.w3.org/html5/html4-differences/

いくつも仕様がありますが、これらは何ですか？

WHATWG における全ての活動は、Web Applications 1.0 に集約されています。単一ページ版（とても大きいです）と分割ページ版マルチ・ページが利用できます。

WHATWG HTML 標準は、HTML に特化した素材のみを含んだサブセットです。単一ページ版と分割ページ版、そして、A4 と Letter サイズの PDF も用意されています。

W3C HTML5 仕様は、WHATWG HTML 標準のサブセットで、安定した機能に絞られています。

下表は、個々の仕様に何が入れられているかを示したものです。

WHATWG Specifications
(and sections therein) 		Section links for
Web Applications 1.0 		W3C/IETF Specifications
HTML5 only (excluding newer features) n/a n/a Single-page, multi-page (HTML WG)
HTML (including newer features) WHATWG HTML Everything not listed below!
Microdata In WHATWG HTML Microdata Microdata (HTML WG)
Canvas 2D Context In WHATWG HTML 2D Context 2D Context (HTML WG)
Communications - Cross-document messaging In WHATWG HTML Cross-document messaging HTML5 Web Messaging (HTML WG)
Communications - Channel messaging In WHATWG HTML Channel messaging
Web Workers Web Workers specification Web Workers Web Workers (WebApps WG)
Web Storage only in WA1 Web Storage Web Storage (WebApps WG)
Web Sockets API only in WA1 Web Sockets API Web Sockets API (WebApps WG)
Server-Sent Events only in WA1 Server-sent Events Server-sent Events (WebApps WG)
WebVTT In WHATWG HTML and informally as WebVTT WebVTT


上記のいずれも、ひとつのソース・ドキュメントから生成されています。

ウェブ制作者や実装者に特化した仕様はありますか？

まだありません。しかし、我々はこれに取り組んでいますので、もう少し待ってください。

当面は、WHATWG HTML 仕様（分割ページ版も含む）は、ユーザーエージェントに特化した素材を非表示にしたり強調させるようカスタマイズすることが可能です。このモードは、ドキュメントの右上にあるラジオボタンを使って選択することができます。

URL を変えることでモードを切り替えることもできます。ここでは、分割ページ版の WHATWG HTML 仕様の例を紹介します。

いつになったら、新機能を使うことができるようになりますか？

もういくつかは使うことができます。そのほかも、何年か経てば、広く実装されるようになっているでしょう。ここでは、何が利用できるのかを調べるのに役立つサイトを紹介しましょう。

他に知っていたら（または、ご自分で持っているなら）、リストに追加してください。他のものと比較してさほど役に立たないのがあればリストから削除してください！

HTML5 はいつ完成するのですか？

WHATWG は、HTML5 に関してはもう特に作業を行うことはありません。そのため、この質問は今となっては適切な質問とはいえません。"HTML5 とは何ですか？" をご覧ください。現実的な質問は、いつ新機能を使えるのか？です。その質問の答えなら、"いつになったら、新機能を使うことができるようになりますか？" をご覧ください。

この仕様は場所によって完成度が異なります。相対的にもう安定し、完成にかなり近い実装があり、今でも使うことができる部分（<canvas> など）があります。一方、今なお活発に作業が行われ、定期的に変更される部分もあります。中には、未だに策定すらされていない部分もあります。

各セクションのおおよその安定度は、余白部分に掲載された注釈に書かれています。

次の状態のいずれかになります：

  • Idea; まだ仕様になっていない -- そのセクションはプレースホルダーです。
  • First draft -- 初期段階.
  • Working draft -- 初期段階だが、"first draft" よりは完成度が高い。
  • Last call for comments -- そのセクションは完成間近ですが、まだ進行中のフィードバックがあるかもしれません。すぐにでもフィードバックを送ってください。でないと間に合わないかもしれません。
  • Awaiting implementation feedback -- そのセクションは基本的には完了ですが、実装者からのフィードバックの対応で変更するかもしれません。もしその機能が仕様化されてしまうと本当にうまく機能しないことが発見されない限り、この時点以降に大きな変更が行われることはありません。
  • Implemented and widely deployed -- その機能は仕様化され完了です。一度そのセクションが相互利用可能に実装されれば、それはかなり安定しており、大きく変更されることはありません。とりわけ、もしその機能の利用がすでに広まっているのであれば、仮にそのようなセクションに変更があったとしても、実際には、編集上の変更しかないでしょう。

さらに 2 つの特別な状態があります：

  • Being edited right now -- そのセクションはとても不安定で、活発に編集されています。もしフィードバックがあれば、IRC で Hixie にコンタクトしてください。
  • Being considered for removal -- 何かしらの理由で、そのセクションは廃止が検討されています。決定の助けになれば、すぐにフィードバックを送ってください。

こで言っておきたいのは、あなたは、全体的な仕様の状態にウェイトをかけすぎるべきではないということです。あなたは各セクション個別の安定度と完成度を考慮すれば良いのです。

2022 年と聞きましたが、どういうことですか？

WHATWG が HTML にバージョンを付けないモデルに移行する前、つまり、我々がまだ HTML5 に取り組んでおり、セクションごとではなく全体としてのマイルストーンに到達するスナップショットの草案という視点で考えていたとき、エディタは、2009 年 10 月に最終草案に、2012 年に勧告候補に、2022 年以降に勧告に到達すると見積もっていました。これは 18 年から 20 年もの開発になるはずでした。2004 年の中盤から始めて、同じようなサイズの同じような成熟度の仕様が同じレベルの品質に達するのに費やした作業量と同じくらいと想定したからです。例えば、CSS2/2.1 のタイムラインと同じです。HTML4 のタイムテーブルと比較すると、この仕様は大きすぎます。HTML4 の作業は 90 年代中頃に開始されました。HTML4 は今もなお、10 年以上経っているというのに、我々が HTML5 で目指すレベルに達していません。テスト・スイートはなく、その仕様の多くの部分が実際に実装されていませんし、相互互換性がない部分も多く、まだ修正されていない既知のエラーが 1000 と言わないまでも数百はあります。HTML4 が出てきたとき、REC は、今と比べてさほどエキサイティングなものではありませんでした。今日になって仕様が REC になるためには、2 つの 100% の完全実装と完全な相互互換性が求められます。これは、文字通り、何千ものテスト・ケース（仕様全体では、控えめに見積もっても、20,000 テストになると言われています）に合格しないといけません。こんなに多くのテスト・ケースを書くのにどれくらい時間がかかるのか、各機能の実装にどれくらい時間がかかるのかを考えれば、なぜ、そんなに長い時間がかかるのかをご理解頂けるのではないでしょうか。

今はもう、我々は、マクロ・レベルのマイルストーンを持たない、より漸進的なモデルに移行しました。2022 年という日程はもはや関係がないのです。

Microsoft と Internet Explorer についてはどうですか？

Microsoft はすでに IE8 に HTML5 の一部を実装し始めています。IE9 ではさらに追加されています。

しかし、（IE も含め）HTML5 は現存のブラウザと互換性が保たれるよう配慮して開発されているところです。多くの機能は JavaScript を使ってシュミレートすることが可能です。

設計の論拠は文書化されますか？

ある程度は。メーリングリストや IRC チャンネルのアーカイブでドキュメントを見ることができます。公式に問題が提起され、その解決方法が issue tracker に記録されることもあります。場合によっては例外もありますが、何でもかんでも文書化してしまったら、仕様がどんどん巨大になってしまいます。

誰かが時間をかけて文書化したいくつかの情報を、次の場所で見ることができます：

下記の HTML 機能の提案もご覧ください。

HTML 構文について

HTML は、XHTML の text/html 論争に終止符を打つのですか？

はい。HTML4 や XHTML1 とは異なり、HTML か XHTML の選択は、DOCTYPE ではなく、MIME タイプの選択のみに依存します。HTML vs. XHTML をご覧ください。

DOCTYPE はどうなるのですか？

HTML の場合：

<!DOCTYPE html>

XHTML の場合： DOCTYPE は必須ではありません。通常は不要です。入れたければ入れても構いません（次の質問をご覧ください）。上記は、整形式 XML です。そのため、これは XHTML 文書に入れることができます。

HTML の出力のために設計された旧来のジェネレータとの互換性のため、それは、前述の DOCTYPE を簡単に出力することはできませんが、この代替の後方互換バージョンを使うことができます。

<!DOCTYPE html SYSTEM "about:legacy-compat">

これは、旧来のブラウザーに関する互換性問題を扱うことを想定したものではありません。旧来のオーサリング・ツールに対してのみです。

文字列 "about:legacy-compat" を除いて、DOCTYPE は HTML においては大文字・小文字を区別しません。XHTML では区別されますので、前述のいずれかの通りとしなければいけません。そのため、<!DOCTYPE HTML> や <!doctype html> のような形式を使うよりは、前述の DOCTYPE を推奨しています。

上記の選択肢が採択されたのは、次に挙げる基準を満たすためでした：

  • 現行のブラウザーも旧来のブラウザーもすべて、これらによって、標準モードとなる。
  • これらは XML においては整形式であり、XHTML 文書に入れることができる。
  • 現存のマークアップ・ジェネレータを使って、両方は無理だとしても、これらのうち少なくともひとつを出力することが可能である。
  • これらは、意図的に、言語バージョン識別子を含めていない。この DOCTYPE は HTML の将来のバージョンでも利用できるようにしている。
  • 前者は短くて、覚えやすく、利用が促進される。
  • 下位互換 DOCTYPE は、意図的に、魅力のないものとし、不必要なところで使われることがないよう自己記述式にした。

XHTML では、DOCTYPE がどの条件下で使われるべきですか？

一般的に、XHTML で DOCTYPE を使う必要はありません。しかし、DOCTYPE が必要となる場合があります：

  1. 該当のドキュメントが、HTML と XHTML のどちらのタイプでも提供できるようなハイブリッドなドキュメントとなるよう想定されている場合。
  2. ドキュメント内での利用のためにエンティティ参照を宣言したい場合。ほとんどのブラウザーは、内部サブセットしか読まず、外部エンティティを取り出さない点に注意してください。（これは、HTML とは互換性がありません。ゆえに、ハイブリッドなドキュメントに対しては適切ではありません。）
  3. DTD ベースのバリデーションに対して、カスタムの DTD を使いたい場合。ただし、DTD はなぜ良くないのかについて注意してください。

基本的に、これは XML の問題であり、XHTML の話ではありません。

HTML4 やそれ以前のバージョンのドキュメントはどのようにパースされるのですか？

text/html メディアタイプを伴ったドキュメントすべて（つまり、DOCTYPE を伴わないドキュメントや、HTML 2.0, HTML 3.2, HTML4, XHTML1 の DOCTYPE を伴ったドキュメントを含みます）は、HTML 仕様 で定義されているのと同じパーサー・アルゴリズムを使ってパースされます。これは、ウェブブラウザーがこれまで HTML ドキュメントに対してしてきたことと一致します。そして、コードの複雑さを低減します。そして、それはセキュリティーにとっても良いことです。一般的に、バグが減り続けます。それゆえに、HTML 構文は新しいパーサーを必要とせず、例えば HTML4 DOCTYPE を持ったドキュメントは、新しい HTML 仕様で記述されているとおりにパースされるでしょう。

バリデーターは、以前のレベルの HTML に対して、異なるコード・パスを持つことができます。

DTD がないなら、どうやって自分のページをバリデートできるのですか？

HTML バリデータ を使ってください。最新の仕様に対応しています。

HTML シリアライゼーションとは何ですか？

HTML シリアライゼーションとは、HTML 仕様で規定された HTML 文書の構文を指します。その構文は、以前のバージョンの HTML から SGML 構文、そして少しだけですが XML、そして、ウェブ上にすでに広まっている実際のコンテンツによって、インスパイアされたものです（たとえば、空の要素に終了タグを表すスラッシュを入れることができたり、xmlns 属性など）。

MIME タイプが text/html と判定される文書は、HTML シリアライゼーションだとみなされ、HTML パーサーを使ってパースされなければいけません。

XML（または XHTML）シリアライゼーションとは何ですか？

XML シリアライゼーションとは、XML 1.0 で規定された構文と、XML 1.0 の名前空間を指します。application/xhtml+xml や application/xml といった XML の MIMEタイプを持ったリソースは XML 文書です。もし HTML 名前空間の要素を使うと、それは XHTML を含んだものとなります。もしルート要素が HTML 名前空間の "html" であれば、その文書は XHTML 文書として参照されます。

HTML ではどんな MIME タイプを使うのですか？

HTML シリアライゼーションは、MIME タイプに text/html を使って提供されなければいけません。

XHTML シリアライゼーションは、application/xhtml+xml や application/xml といった XML の MIME タイプを使って提供されなければいけません。XHTML1 とは異なり、HTML 仕様においては、XHTML は text/html として提供してはいけません。

XHTML に間違った MIME タイプ（text/html）を使うと、その文書は HTML 用の解析要件に従って解析されてしまうでしょう。言い換えると、それはタグスープとして扱われるでしょう。確実にブラウザに XML として処理させたいのであれば、確実に XML の MIME タイプを使うしかありません。

空要素は /> で閉じるのですか？ それとも > で閉じるのですか？

HTML の空要素（たとえば、br, img, input 要素）に終端スラッシュをいれる必要はありません。<br /> の代わりに <br> と書けば良いだけです。これは HTML4 と同じです。しかし、XHTML1 の利用が広まっているため、かなり多くのページで、終端スラッシュが使われています。そのため、XHTML1 から HTML への移行を容易にするために、終端スラッシュの構文を HTML の空要素で使うことができるようになりました。

この新 HTML 仕様では、MathML 要素も組み込めるようになっています。math 要素の中にある要素に終端スラッシュを入れれば、それは XML の中で使われているのと同様の意味を持ちます。つまり、それは要素を閉じます。しかし、これはそのコンテキストの中だけに適用され、通常の HTML 要素では機能しません。

HTML 文書で使う構文に注意すれば、XML パーサーで処理することはできますか？

はい。HTML vs. XHTML と Polyglot Markup: HTML-Compatible XHTML Documents のガイダンスをご覧ください。

ここでひとつ注意があります。もしそうしたいなら十分に注意を払う必要がありますが、そうすることにあまり意味はありません。HTML-to-XML パーサーを使うだけにしたほうが良いでしょう。そうすれば、XML パイプライン・ツールを使っていたとしても、普通に HTML だけを使えば良いことになります。

名前空間宣言は何ですか？

XHTML では、名前空間を指定しなければいけません。

<html xmlns="http://www.w3.org/1999/xhtml">

HTML では、現在の所、xmlns 属性をどの HTML 要素にでも使うことができますが、その値は "http://www.w3.org/1999/xhtml" のみです。これは、まったく何もしません。XHTML1 からの移行を簡単にする程度でしかありません。実際には、これは HTML における名前空間宣言ではありません。なぜなら、HTML はまだ名前空間をサポートしていないからです。質問 HTML に名前空間のサポートはありますか？ をご覧ください。

HTML に名前空間のサポートはありますか？

HTML 5 は DOM に関して規定されており、text/html のパースでは、すべての HTML 要素は自動的に HTML 名前空間 http://www.w3.org/1999/xhtml に入れられることになります。しかし、XHTML シリアライゼーションとは違い、HTML シリアライゼーションでは利用できる本当の意味の名前空間構文はありません（前の質問をご覧ください。）。つまり、XHTML のように、HTML マークアップの中で名前空間を宣言する必要はありません。しかし、値は http://www.w3.org/1999/xhtml に限定されますが、それぞれの HTML 要素に xmlns 属性を入れることができます。

さらに、HTML 構文は、MathML や SVG の要素を組み込む方法も提供しています。math や svg のコンテナ要素の中に入れられた要素は、パーサーによって自動的に、それぞれ、MathML 名前空間や SVG 名前空間に入れられることになります。名前空間の構文は必須ではありませんが、値が適切な名前空間であれば、xmlns 属性を再度使っても構いません。

結論として、HTML では XML 名前空間構文を使うことはできませんが、MathML や SVG を組み込む方法があり、xmlns 属性をどの要素でも使うことができます。ただし、指定の制約のもとで、それが DOM レベルにおいて不整合がないことが条件です。

どうやって文字エンコーディングを指定すればよいのですか？

HTML では、HTTP の Content-Type ヘッダーを使ってエンコーディングを指定することが強く推奨されます。適切なヘッダーを送信するようサーバーを設定することができない場合は、meta 要素を使うことができます：

<meta charset="UTF-8">

文字エンコーディング宣言には、次の制限が適用されます：

  • 指定する文字エンコーディング名は、そのファイルをシリアライズするのに使われる文字エンコーディングの名前でなければいけません。
  • その値は、妥当な文字エンコーディング名でなければならず、そのエンコーディングに対する推奨名でなければいけません。
  • 文字エンコーディング宣言は、文字参照や文字エスケープといった類を使わずにシリアライズされなければいけません。
  • この目的のために使われる meta 要素は、そのファイルの先頭から 512 バイト以内に現れなければいけません。この要素を head 要素の最初の子にして、できる限りファイルの先頭の方に近づけるようにするのが良いでしょう。

この meta 要素は、HTML 4 とは違いますので、注意してください。しかし、多くのブラウザーでは互換性があります。なぜなら、エンコーディング検知の方法がすでに実装されているからです。

HTML および XHTML のどちらでも提供できるようにしたハイブリッドのドキュメントに対しては、XHTML ドキュメントにもそれを入れることができます。しかし、そのエンコーディングは "UTF-8" の場合のみです。

先ほど示したものが推奨される構文ではありますが、HTML4 から最新の HTML 仕様へ簡単に移行できるように、次のようにすることもできます。（これは、XHTML や ハイブリッドなドキュメントには使えません。）

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

XHTML では、XML の文字エンコーディング決定のルールが適用されます。meta 要素を、XHTML ドキュメントのエンコーディングを決定するために決して使ってはいけません（しかし、それを、UTF-8 でエンコードされた XHTML ドキュメントに入れることは可能です）。あなたは、HTTP の Content-Type ヘッダーか、もしくは、エンコーディングを指定する XML 宣言のいずれかを使うべきです。

<?xml version="1.0" encoding="UTF-8"?>

そうでなければ、あなたは、デフォルトの UTF-8 または UTF-16 を使わなければいけません。推奨は、UTF-8 です。

HTML と XHTML の違いは何ですか？

wiki にある differences between HTML and XHTML の一覧をご覧ください。

HTML DOM と XHTML DOM を両立するベスト・プラクティクスは何ですか？

HTML と XHTML とで同等の DOM が生成されるよう考えられてはいるのですが、HTML DOM と XHTML DOM とでは動作に若干の違いがあります。

大文字・小文字の違い：

  • できる限り、Element.tagName と Node.nodeName の比較評価は避けてください（または、比較評価の前に、toLowerCase() を使ってください）。

名前空間:

  • 名前空間を指定して要素を生成しなければいけない点： Document.createElementNS(ns, elementName)

なぜ HTML5 はタグ・スープを容認するのですか？

実際は容認していません。それは文書の適合性要件とユーザエージェントの要件とを混同して出てきた誤解です。

現存のコンテンツをサポートするという基本設計の原則の結果、文書が適合しているか否かにかかわらず、HTMLを処理する方法を仕様で規定しなければいけません。それゆえに、仕様では処理方法や、タグスープとみなされるような間違ったマークアップを回復する方法を正確に規定しています（または、するでしょう）。

例えば、仕様では、正しくネストされていないタグのような構文エラーを処理するためのアルゴリズムを規定しており、間違いなく、うまく構成された DOM ツリーが生成できるでしょう。

ブラウザ間の相互運用性を達成し、お互いのリバース・エンジニアリングへの依存を低減できる日を迎えるためにも、それを規定することは不可欠なのです。

しかし、ウェブ制作者向けの適合性要件は、処理要件とは分けて規定されています。ブラウザは間違ったコンテンツを処理することが要求されますので、そのようなマークアップの適合正をチェックしません。

例えば、ユーザエージェントは marquee 要素をサポートしなければならないでしょう。しかし、ウェブ制作者は、適合した文書内で marquee 要素を使ってはいけません。

ユーザエージェントに適用されるルールと、適合文書を作成する際のウェブ制作者に適用されるルールとを区別をすることが大事です。これらは、まったく違うことなのです。

HTML 機能の提案

HTML は、あらゆる要素で href をサポートするべきだ！

仕様では、<a> にブロックを入れることができます。しかし、あらゆる要素に href="" を入れることはサポートしてません。

あらゆる要素に href をサポートしてしまうと、それに起因する問題がいろいろ出てきてしまい、HTML でのサポートは難しくなります。HTML ではないところで、その大きな理由としては、その実装がものすごく複雑になるとブラウザー・ベンダーが報告してきたからです。ブラウザー・ベンダーが何を実装するのかを決めます。彼らがやるつもりがないことを実装するよう言っても意味はありません。さらに：

  • 既存のブラウザーとの後方互換性がない。
  • a 要素とちょっとしたスクリプトを使ってもできないような新たな機能性が加わることがない。
  • すべての要素でサポートされる意味がない。input や button のようなインタラクティブ要素などが該当するのですが、href を利用することで、それらの本来の機能を妨げてしまうかもしれません。

場合によってはウェブ制作者のタイピングが減るという程度のメリットしかないように思われます。しかし、この程度では、他の理由を考えると、それをサポートする理由としてはまったく十分とはいえません。

ブロックを <a> 要素で囲めば、ほとんどの利用例では解決します。ただし、テーブルの行をリンクの中に入れることはできませんが、こうすれば解決します： 

 <tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>

HTML は、リスト・ヘッダーをサポートするべきだ！

<figure> と <figcaption> 要素を使えば、リストにヘッダーを与えることができます： 

 <figure>
  <figcaption>Apples</figcaption>
  <ul>
   <li>Granny Smith</li>
   <li>Evil Apple of Knowledge</li>
   <li>Apple, Inc</li>
  </ul>
 </figure>

定義リストを使って、リストのグループをラベリングすることもできます：

 <dl>
  <dt>Dry:</dt>
  <dd>
   <ul>  
    <li>1c flour</li>  
    <li>1/4c sugar</li>
    <li>1tsp baking soda</li>
   </ul>
  </dd>
  <dt>Wet:</dt>
  <dd>
   <ul>  
    <li>1 egg </li>
    <li>1/2c milk</li>
    <li>1tsp vanilla extract</li>
   </ul>
  </dd>
 </dl>

れらのテクニックは、過去に HTML3 仕様で提案された <lh> 要素に置き換わるものです。<li> 要素の直近でパースするというのは、やっかいな問題があるからです。

HTML は、誰でも新要素を考案できるようにするべきだ！

実際には、自分で HTML の拡張を考案する方法がいろいろあります：

  • ウェブ制作者は、もっとも相応しい既存の "実際" の HTML 要素を使いながらも、class 属性を使って要素を拡張することができます。そうすることで、その拡張を知らないブラウザーやそのほかのツールでも、なんとかその要素をサポートすることができます。例えば、これは Microformat で採用されている取り組みです。
  • ウェブ制作者は、data-*="" 属性を使って、スクリプト向けのデータを入れることができます。ブラウザーは、これらには一切触れることはありません。そのため、スクリプトから HTML 要素にデータを入れ、後からそれを探して処理することができるようになります。
  • ウェブ制作者は、<meta name="" content=""> メカニズムを使って、ページ全体のメタデータを入れることができます。名前は、wiki の MetaExtensions ページで登録してください。
  • ウェブ制作者は、rel="" メカニズムを使って、リンクに特定の意味を注釈することができます。これは Microformat でも利用されています。名前は wiki の RelExtensions ページで登録してください。
  • ウェブ制作者は、<script type=""> メカニズムを使って、独自のタイプを指定することで raw データを組み込むことができます。さらに、スクリプトから扱うこともできます。
  • ウェブ制作者はプラグインを生成し、<embed> 要素を使ってそれを呼び出すことができます。Flash はこうやって動作させることができます。
  • ウェブ制作者は、JS prototyping メカニズムを使って、API を拡張することができます。これはよくスクリプトのライブラリなどで使われています。
  • ウェブ制作者は、microdata 機能を使うことができます。（item="" と itemprop="" 属性）。これを使って、ネストした name-value ペアのデータを組み込んで、他のアプリケーションやサイトと共有することができるようになります。
  • ウェブ制作者は、新要素や新属性をワーキング・グループに提案することができます。もしコミュニティーが広く努力の価値がある提案だと賛成すれば、その提案が言語に追加されます。（もしその追加が緊急なのであれば、提案時に我々にその旨を知らせてください。我々は早めにそれに対処してみるでしょう）

現在のところ、ユーザーエージェントのベンダーやウェブコミュニティーとその拡張について議論もせずに、HTML ドキュメントに独自の機能（新要素や新属性）を導入するメカニズムを入れることはありません。これは意図的にそうしています。我々は、"古き悪しき時代" のときのように、関係グループと良い設計となるよう、議論もせずに独断でユーザーエージェントに独自の要素や属性を考案してもらいたくはありません。

我々は、ワーキング・グループにも相談せず、その提案を関連のグループと議論することもせずに、新要素や新属性を考案して追加しないようお願いしています。

HTML は、<dt> と <dd> を <di> でグループ化するべきだ！

これは、スタイリングの問題で、CSS で対処するべきです。HTML にグループ化の要素を追加する理由はありません。セマンティクスが曖昧だからです。

<di> のようなものを追加してしまうと、いくつか問題が出てきてしまいます：

  • パースを変更する必要が出てしまいます。それは比較的大変なことです。
  • パーサーがすべてアップデートされるまで、後方互換性という残念な話が持ち上がってしまう。
  • <dl> を扱った古いコードでは、後方互換性という残念な話が持ち上がってしまう。なぜなら、それらは <di> を必要としていなかったのだから。

これは、コストに見合うとは言えないでしょう。CSS でも問題の多くは解決するでしょうから（スタイリングが問題なのであれば）。

なぜ、<b>, <i>, <small> のようなプレゼンテーショナルな要素を未だに入れているのですか？

これらの要素は、主として、すでに広く使われているという状況、そして、他の要素ではカバーできない利用ケースにおいて役に立つ、という点を鑑みて、仕様に入れることを決めました。

強調（em）、引証（cite）、定義（dfn）、変数（var）などのように、特定の要素で扱えるイタリック向けの一般的な利用ケースが数多くある一方で、これらの要素ではうまく扱えない利用ケースも数多くあります。例えば、分類名称、技術用語、別の言語からの慣用句、思考、船の名前です。

同様に、重要性（strong）、見出し（h1-h6）、テーブルヘッダー（th）のような特定の要素で扱えるボールドのテキスト向けの一般的な利用ケースが数多くありますが、そうでないものもあります。例えば、ドキュメントの概要に使われるキーワードや、レビューの中で使われる商品名です。

このようなケースでは、span 要素に適切な class 名を与えてスタイルシートに関連づけて使うべきだと主張する人もいます。しかし、b 要素や i 要素は、ある環境において、それ相応のフォールバック・スタイリングを提供するものです。その環境とは、スタイルシートをサポートできない環境や、ビジュアルでレンダリングできない環境です。例えば、スクリーン・リーダーなどです。また、これだけでなく、これらの要素は、そのテキストはその前後のコンテンツとは何かしら区別されている、ということを表しているのです。

基本的に、これらの要素は区別を伝えるものですが、特定のセマンティクスを持ちません。そのセマンティクスは、読者が文脈から判断して決めることになります。言い換えると、これらの要素はそれ自身では特定のセマンティクスを伝えることはありませんが、そのコンテンツは前後とは何かしらの区別がされており、読者にそのセマンティクスの解釈が委ねられるということになります。

これについては、この記事に詳しく説明されています。 The <b> and <i> Elements

同様に、small 要素は、一般的に印刷表現上で小さい文字でレンダリングされるようなコンテンツに対して定義されたものです。これは、ファイン・プリントとして知られているものです。これは、通常はドキュメントの最後の方に掲載されるような著作権表示や免責条項や法律的なテキストなどを含みます。

でも、やっぱり、これらはプレゼンテーショナルだ！

<font> のような要素が抱える問題は、その要素そのものがプレゼンテーショナルであるということではありません。それらがメディアに依存しているということが問題なのです（これらの要素は、ビジュアル・ブラウザーで適用できたとしても、音声ブラウザーでは適用できません）。歴史的には、<b>, <i>, <small> はプレゼンテーショナルなものでしたが、HTML5 では、メディアに依存しない形で定義されています。例えば、<small> は、ラジオ広告でいえば、その最後でほんのちょっとだけ話されるような部分に相当します。

<cite> 要素で人の名前をマークアップできるようにするべきだ！

見てきた限り、ほとんど常に、<cite> は "イタリック" を意味して使われています。慎重なウェブ制作者は、この要素を名前やタイトルをマークアップするのに使っているが、中には引証をマークアップするのとはかけ離れた使い方をしている人もいます。

そのため、さすがに、この要素を、我々がこれまでしてきたような過去の実践をベースにすることはできません。

もし我々がそうし続けるなら、これは、この要素のもっとも有用な使い方は何かという課題から逸れてしまいます。今のところ、<cite> のもっとも有用な利用とは、タイトルという意味を超えて、印刷表現コントロールを許すことだという結論に達しています。なぜなら、それらは、よくイタリックにしたり、そのセマンティックは、それが以前のバージョンで意味していたものに概ね近く、その要素の一般的な使われ方の少なくともひとつに一致することになるからです。しかし、一般的に、名前とタイトルは同じようなタイプセットではありません。そのため、この要素をどちらにも適用するということは、印刷表現において混乱を招いてしまいます。

もし本当に名前が必要なのであれば、すでにそれをマークアップする方法はたくさんあります（たとえば、hCard microformat, microdata vCard vocabulary, <span>, class 名, など）。

<time> 要素で曖昧な時間（"March"）や古代史の時間をマークアップできるようにするべきだ

これについては、何回も議論を重ねてきました。このトピックの概要は、次の e-mail をご覧ください：

現在のところ、2 つ目の e-mail で議論されているとおり、前進のためのベストな方法とは、この問題を解決することに興味を持ったコミュニティがあることを示すことです。その解決のために、microdata などの既存のテクニックを使うのです。もし、ひとつの解決策が高い普及率を達成するなら、それは、提案の強さを大幅に増強することになるでしょう。

（将来的には、<time> 要素は西暦や西暦+月をサポートできるよう拡張されるでしょうが、まずは現在の仕様に基づいた実装を待っているところです。）

<input type="text"> には minlength="" 属性が必要だ

これについては議論してきましたが、我々はブラウザーが多くの新しいフォーム機能をキャッチアップしてくれるのを待っているところです。minlength="" のような新機能を加えるのはその後です。

WHATWG と W3C HTML WG

グループを統合する計画はありますか？

ありません。いろいろな理由で W3C に参加できない人がいます。そして、WHATWG に参加できない人もいます。エディタはいずれのグループにも参加しており、すべての情報を考慮に入れています。さらに、これらのメーリングリスト以外にも HTML5 に関する情報が送られてくるところが数多くあります（例えば、ブログ、www-html@w3.org、フォーラム、直接送られてくるメール、ミーティングなど）。

どちらのグループが議論において権限を持っているのですか？

エディタはみんなからのフィードバックを取り入れています。技術的な議論のために話の出所を見ることはありません。

W3C HTML ワーキング・グループには、エスカレーション・プロセスというものがあります。これは、場合によっては、あるトピックに関してエディタの当初の決定とは違う決断を下すことになります。今のところ、これが起きるときはいつも、WHATWG は W3C のリクエストを受け入れてきました。とはいえ、今のところ、重要性が高いことに関して、この方法で変更されたことはありません（ほとんどは編集上の問題や些末な技術的問題ばかりです）。通常は、W3C グループが深刻な判断ミスを立証できない限り、WHATWG は仕様の規定に該当する内容（ウェブ制作者と実装者の要件）が同じになるようにしています。

HTML の経緯はどうなっていますか？

HTML の経緯の詳細を知りたければ、こららのドキュメントをご覧ください：

メーリングリスト

トップポスティングにするべきですか？それともインラインで返信するべきですか？

インラインで返信するか、自己完結する形式で返信してください。。そして、もとのメールの引用では、無関係な部分を除いてください。

基本的には、あなたが書いた最後の行の後ろには何も入れないでください。そうすることで、あなたが書いた部分を見つけ出すためにスクロールしなくてもよくなりますし、あなたの e-mail が分かりやすくなります。そうしないと、何年か経ってから、文脈が分からなくなってしまうかもしれないからです。

つまり、このように返信してください： 

Ian wrote:
> What do you want? 

I want cats!

> When do you want it?

Now!

絶対に次のように返信してはいけません（あなたの e-mail をさかのぼって読まなければいけなくなるからです）： 

No

Ian wrote:
> Is this a good example of how to post e-mails?

また、次のように返信するのもやめてください（あなたが書いた箇所より下にも何かあるのではないかと思わせるからです）： 

This is a bad way to write e-mail.

Ian wrote:
> Is this a good way to write e-mail?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text

また、次のように返信するのもやめてください（まったく文脈がない）。読者が、あなたが何について言及しているのか分からないからです： 

No, I think that's a bad idea. It wouldn't be good for the readers, for instance.

オリジナルのテキストをしっかりと引用してください。もしくは、あなた自身で概要を説明してください。

もし、あなたが、Outlook や Outlook Express を使っているなら、 Outlook-QuoteFix や OE-QuoteFixを使うことができます。これらのプラグインは、Outlook の問題のいくつかを修正して、email を適切にフォーマットした上で送信してくれます。