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 は主に HTML5 にフォーカスしています。WHATWG は Web Workers にも取り組んでいます。時には、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. その後も引き続き、その提案のすべてを慎重に検討して、その設計の議論に加わってください。通常は、この段階で、当初の設計は破棄され、本当により良い設計が開発されます。以前の調査、最新の調査、実装、実験的な実装を使ったウェブ制作者の経験によって、通知されます。場合よっては、そのアイデアはこの段階で破棄されることもあります。

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

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

HTML5

HTML5 とは何ですか？

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

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

この仕様は、subversion repository で利用可能です。svn クライアントを使って最新バージョンを確認したり、クライアントの diff ツールを使ってリビジョンを比較したり、何が変更されたのかを調べることができます。また、オンラインの (X)HTML5 Tracking もご利用頂けます。このツールは、仕様のリビジョンを選択し比較できるオンライン・インタフェースを提供します。

HTML 5 はいつ完成するのですか？

"完成" というのは大変なことです...。あなたは、その時がくる前に HTML5 を使うことができます。これらの新しい機能はいつから使いはじめることができるのですか？をご覧ください。

HTML5 は 2012 年中に W3C 勧告候補の段階に達すると、エディタは見積もっています。これは、その時点に達するまで、それらの機能を使い始めることができないということではありません。仕様の部分ごとに完成度が異なります。あるセクションではすでに比較的に安定しているでしょうし、完成のため完全にクローズした実装もあります。これらの機能は今日でも利用することができます（たとえば <canvas>）。しかし、まだ活発に作業が続けられ、定期的に変更されるセクションや、未だ仕様が記述すらされていないものもあります。

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

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

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

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

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

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

再びですが、エディタによると、HTML5 は 2022 年以降に W3C 勧告に至ると見積もられています。これは、2004 年半ばに開始されてから、およそ足かけ 18～20 年の開発となります。しかし、これはそんなにおかしなことではありません。HTML4 の作業は 90 年代半ばに開始されましたが、HTML4 は 10 年以上経ったにもかかわらず、いまだに、我々が HTML5 で到達したいレベルに達していません。まともなテスト・スイートもなければ、実際の実装には足りない仕様が多くあり、相互運用可能でない大きな部分もあります。そして、何千とは言わないが何百もの既知のエラーが修正されていません。HTML4 が登場した当時は、勧告というものが、現在ほどエキサイティングなものではなかったのです。

今日、仕様が勧告に至るためには、100%の完成度と完全に相互運用可能な実装の二つが求められます。文字通り何千ものテスト・ケース（仕様全体では控えめに見積もっても 20,000 テスト）を成功裏にパスすることを証明しなければいけないのです。そのテスト・ケースを書くのにどれくらいの時間がかかるのか、各機能を実装するのにどれくらいの時間がかかるのかを考えてみれば、なぜ期間がそんなに長くなりそうなのかがお分かり頂けると思います。

（ぶっちゃけ言ってしまうと、W3C の 公式見解 では、HTML5 仕様は 2010 年後半に相互運用可能な実装をもって完成することになっています。しかし、そのスケジュールには公開草案初版（FPWD）の年月が掲載されていますが、それは 8 ヶ月早すぎました。そして、W3C の勧告候補（CR）は、3 つ目のマイルストーンに予定時期として書かれていますが、いまだ、2 つ目のマイルストーンである最終草案（LC）にすら達していません。W3C のスケジュールの信憑性については、あなたのご判断にお任せします。）

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

Microsoft はすでに IE8 で HTML5 の一部を実装し始めています。

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

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

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

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

• WhyNoNameSpaces
• WhyNoScriptImplements
• WhyNotReuseLegend -- or another mini-header element.

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

HTML5 構文について

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

はい。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 では区別されますので、前述のいずれかの通りとしなければいけません。For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <!DOCTYPE HTML> or <!doctype html>.

次に挙げる基準を満たすため、上記のいずれかが選択されました：

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

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

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

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

策定が終了していない HTML5 で作ったドキュメントをどうやってパースするのですか？

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

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

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

HTML5 validator を使ってください。

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

HTML シリアライゼーションとは、HTML5 で規定された 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 文書として参照されます。

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

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

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

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

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

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

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

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

できません。HTMLとXMLは、特に構文解析要において多くの重要な違いがあり、他方のために設計されたツールを使ったシリアライゼーションを処理することはできません。しかし、HTML5 は DOM に関して規定されていますので、ほとんどのケースでは、HTML と XHTML のシリアライゼーションの両方が利用可能となり、同じ文書を表すことができます。しかし、後ほど説明しますが、いくつかの違いがあります。正確に XHTML として表すことができない HTML もありますし、その逆もしかりです。

もし HTML 文書を XHTML として処理したいのであれば、まずそれを XHTML に変換する必要があります。XHTML を HTML として処理したい場合は、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 属性を再度使っても構いません。

結論として、HTML5 では 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 から HTML5 へ簡単に移行できるように、次のようにすることもできます。（これは、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 要素を使ってはいけません。

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

HTML5 機能の提案

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

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

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

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

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

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

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

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

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

 <figure>
  <legend>Apples</legend>
  <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> 要素の直近でパースするというのは、やっかいな問題があるからです。

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

実際には、自分で 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 ドキュメントに独自の機能（新要素や新属性）を導入するメカニズムを入れることはありません。これは意図的にそうしています。我々は、"古き悪しき時代" のときのように、関係グループと良い設計となるよう議論もせずに、独断でユーザーエージェントに独自の要素や属性を考案してもらいたくはありません。

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

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

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

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

これらの要素は、これまでの使い方を踏襲したような実用的な利用ケースや、特定の要素では扱えないような利用ケースを想定しています。

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

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

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

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

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

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

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

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

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

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

そのため、私たちは、この要素は、我々がこれまでしてきたような過去の実践に基づくべきだと決めることができません。

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

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

注意： 話者（例えば引用などの）の名前をマークアップするために <cite> 要素の利用をサポートするということについて、調査や意見が集めているところです。みなさんのご協力お願いします：

• cite element: examples in the wild of speakers marked up with cite
• cite element: opinions on use of cite to markup names of speakers

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

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

• http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/018888.html
• http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/021745.html

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

WHATWG と the W3C HTML WG

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

特にありません。いくつかの理由で W3C グループに参加できない人がいますし、また、WHATWG グループに参加できない人もいます。エディタはどちらのグループにも属しており、すべての提案を取り入れています。-- そして、これら二つのメーリングリストだけではなく、HTML5 に関する提案が送られる場所が他にもたくさんあります（たとえば、ブログ、www-html@w3.org、フォーラム、直接送られてくるメール、ミーティングなど）。

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

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

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

HTML の経緯の詳細が掲載されたドキュメントがいくつかありますのでご覧ください：

• HTML's timeline on the ESW wiki
• The history section in HTML5 itself

Web Workers

WHATWG は、HTML5 だけでなく、Web Workers の作業もしています。これは、W3C WebApps ワーキング・グループと一緒に作業しています。

メーリングリスト

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

インラインで返信するか、自己完結する形式で返信してください。

基本的には、あなたが書いた最後の行の後ろには何も入れないでください。そうすることで、あなたが書いた部分を見つけ出すためにスクロールしなくてもよくなりますし、あなたの 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 を適切にフォーマットした上で送信してくれます。H