この文書「HTML 設計原則」は、W3C の HTML ワーキンググループ による「HTML Design Principles (W3C Working Draft 26 November 2007)」の日本語訳です。
規範的な文書は原文のみとなっています。この日本語訳は参考情報であり、正式な文書ではないことにご注意ください。また、翻訳において生じた誤りが含まれる可能性があります。
原文が勧告 (Recommendation) ではなく、策定途中の草案 (Working Draft) であることにご注意ください。
原文の最新版 は、この日本語訳が参照した版から更新されている可能性があります。また、この日本語訳自身も更新されている可能性があります。日本語訳の最新版は、W3C 仕様書 日本語訳一覧 から参照することができます。
Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
HTML 5 は World Wide Web の中核となる言語、HTML の 5 度目となる改正版です。この文書は HTML ワーキンググループにて使用される、HTML5 の策定について指針となる理念を説明したものです。これらの理念は、互換性、有用性、相互運用性の観点から、HTML のデザインを指導する役割を担っています。
この章は、この文書の公開時におけるステータスについて説明しています。このため、他の仕様がこの文書を上書きしている可能性があります。W3C による他の出版物およびこの技術レポートの最新版は W3C 技術レポートインデックス (http://www.w3.org/TR/) で探すことができます。
この文書は "HTML 設計原則" の最初の公開草案 (First Public Working Draft) です。HTML Activity の HTML ワーキンググループ により作成されました。HTML ワーキンググループはこの文書を 部会ノート (Working Group Note) として公開する予定です。ワーキンググループが策定している新しいバージョンの HTML は、まだ TR の下に公開されていません。現在は HTML 5 編集者ドラフト (HTML 5 Editor's draft) にアクセスすることができます。コメントを寄せるにあたり適切なフォーラムは [email protected] です。公開アーカイブ も存在しています。
この文書を公開するにあたって、HTML ワーキンググループのメンバーによる投票 が行われました。その結果は 51 の "Yes" と 2 つの "No"、そして 1 つの "Formally Object" というものでした。
反対票については、将来の草案において解決されるであろう問題に対してのコメントであるという判断がなされました。つまり、草案の公開を延期する理由ではないということです。HTML ワーキンググループが文書を公開する目的は、コミュニティに対し仕様の評価を行い始めるよう求め、W3C の内外を問わず幅広いコメントを集めるというものであることから、完全な合意 (full consensus) が文書の公開における前提条件ではないと判断しています。
部会ノートとしての仕様書公開は、W3C メンバーによる支持を意味するものではありません。この文書は更新されたり他の文書と置き換えられたり、また破棄される可能性もある草稿段階の仕様書です。策定中ということを明記せずに、この文書を引用することは適当でありません。
この文書は 5 February 2004 W3C Patent Policy の下で活動するグループにより作成されました。W3C は 特許情報の開示に関する公開リスト を関連する団体と共に、その成果物とあわせて管理しています。リストには情報開示に関する説明もありますので、ご参照ください。特許について十分に知識のある人物が、当該仕様に関し Essential Claim(s) が認められると判断した場合は、W3C 特許方針の第 6 章 に従い情報を開示する必要があります。
HTML ワーキンググループには、WHATWG や他の W3C ワーキンググループ、その他多くのコミュニティから参加者が集まっています。WHATWG による HTML 5 の動きと、長年 W3C が行ってきた標準化活動は、仕様のデザインに対しそれぞれ異なる考え方や目標を設けていました。策定プロセスを都合の良いものにするため、そのゴールにおいていくつかの取り決めが必要となります。
この設計原則は、仕様のデザインにおけるコンセンサスをつかむためのものです。これらは実利的な経験則であり、一方が絶対なものとならないようバランスがとられる必要があります。TAG の Architecture of the World Wide Web に関する調査結果と思想が似ていますが、あくまでも HTML ワーキンググループに特化したものです。
多くの言語仕様は、妥当な文書のための適合性要件と、妥当な文書を検証する、実装のための適合性要件を規定しています。HTML 5 はすこし特殊であり、これらの要件のほか、適合する文書において認められない概念に対しても、実装の適合性要件を定義しています。
仕様が持つこの二重性により、コンテンツ制作者には相対的に簡潔で理解しやすい言語を提供することができます。同時に、古い文書や標準ではない文書についてもサポートが可能であり、またエラー処理における相互運用性の向上も見込まれます。
次に記す設計原則は、文書内容 ("適合する言語") への適合性要件に近いものと、実装 ("サポートされる言語") への適合性要件に近いものがあります。サポートされる言語は、適合する言語の厳密なスーパーセットであるため、これらが部分的にオーバーラップする場合もあります。しかし、この文書はどちらの要件が当てはまるのかを明確にしようと最大限の努力を行っています。
互換性という言葉には多くの解釈が存在します。「後方互換性」や「前方互換性」という言葉は良く使われますが、その定義が明瞭ではないときがあります。このセクションでは、いくつかの側面から互換性について解説します。
この原則は、主にサポートされる言語に当てはまるものです。
現在の Web コンテンツは、ユーザーエージェントの処理や、期待される処理方法に頼ったものとなっています。このため、どのように処理を行うかを用件として定義し、この仕様を実装するユーザーエージェントが現在の Web コンテンツも取り扱えるようにするべきです。特に、現在の HTML 文書を HTML 5 として処理し、その結果がユーザーやコンテンツ制作者の期待する現在のブラウザの挙動と互換性を持ったものとなる事が望ましいでしょう。また、必須ではありませんが、モードスイッチを利用せず、これを実現することが望ましいでしょう。
現在のブラウザの処理方法に頼った Web コンテンツとは、いろいろなかたちで存在しています。ある要素に頼ったもの、や、HTML 5 ではなく前の HTML 仕様にあった属性や APIに頼ったもの、独自拡張を利用したものなどです。また、特定のエラー処理規則に頼ったものもあるかもしれません。まれですが、仕様の定義通りに実装されていない、以前の HTML にあった機能に頼っているものもあります。
さて、現在の実装やコンテンツ制作者の期待による、これらのレガシーな機能やビヘイビアに対し変更を行うときには、次のような疑問を持つことが推奨されます。
これらの基準をもとに、提案された変更により享受できるメリットと、現在の Web コンテンツを壊すことのコストを天秤にかけることが推奨されます。いくつかのケースにおいて、そのユースケースが妥当である場合、標準ではない機能やビヘイビアを適合する言語に組み込むことが望ましいことがあります。しかし、機能がサポートされる言語の一部である場合は異なります。サポートされているからとはいえ、その機能が推奨されたり、許可されているわけではありません。
多くのサイトにおいて、マークアップの不備を見つけることができます。たとえば <b>a<i>b</b>c</i> など、間違った要素のネストです。このような問題に対し、ページ作成者やユーザーは、レガシーなユーザーエージェントが行っているエラーハンドリングを期待します。このため、現在の処理方法に対し互換性を保持しながら、処理に関する要件を定義する必要があります。
いくつかのサイトでは、下線を引くという視覚的効果を与えるために、<u> 要素に頼っています。
この原則は、主に適合する言語に当てはまるものです。
World Wide Web において、コンテンツ制作者は新しい機能の利用をためらいがちです。これはその機能が古いユーザーエージェントで問題を起こすものである、またはその機能に適切なフォールバック (代替となる内容) が提供されていないことが原因です。このため、Web コンテンツが古い、または能力の劣るユーザーエージェントにおいても、優雅なデグレーションを行うように、HTML 5 文書の適合性要件を定義すべきです。これは新しい要素や属性、API や内容モデルの利用においても当てはまります。
とても古いブラウザや、ニッチなマーケットにおいてまったく人気のないツールなどを含めた、すべての Web ユーザーエージェントを考慮することは適切ではありません。しかし、次のカテゴリに属するユーザーエージェントに対しては充分な考慮がなされるべきです。なぜなら、Web コンテンツ制作者は、次のカテゴリに属するようなユーザーエージェントを重視する傾向にあるからです。
いくつかのケースにおいて、新しい機能があるタイプのユーザーエージェントに簡単に適用できない場合、または、デグレーションを行うような設計が現実的ではない場合に直面するかもしれません。たとえば、新しいスクリプティング API がスクリプトを搭載しないユーザーエージェントにおいては動作しないなどです。しかし多くの場合において、次のようなアプローチが利用できるでしょう。
これらはほんの一部です。いくつかのケースにおいては、これらより少し複雑なアプローチの方が効果的である場合があります。
提案されている irrelevant 属性のデフォルトレンダリングは、[irrelevant] { display: none; } という CSS ルールを適用することによりエミュレートできます。
提案されている新しいマルチメディア関連要素、たとえば <canvas> fallback </canvas> や <video> fallback </video> はフォールバックを持つことができます。canvas や video をサポートするユーザーエージェントは、マルチメディア内容を表示し、古いユーザーエージェントは "fallback" を表示することになります。
提案されている getElementsByClassName() メソッドは、巷のライブラリで定義される ECMAScript 実装よりも大幅に速いものになるでしょう。しかし、ネイティブの実装が利用できない場合においても、このようなスクリプトベースの実装を利用することができます。
<datalist> 要素は <input> 要素と対応させることができ、また隠された <select> を持つこともできます。この場合、意図された "コンボボックス" コントロールのフォールバックは、現在の主要なブラウザにおいて、テキストフィールドまたは、テキストフィールドとポップアップメニューの組み合わせとして表現されるでしょう。
すでに実装され広く使われている技術があるならば、それをきちんと定義し、再発明をしないようにしましょう。しかし、時には新しいユースケースが、古いものの拡張ではない新しいアプローチを生むこともあります。
contenteditable="" は広く使われ、またユーザーエージェントでサポートされています。同じ機能を新しい構文で定義する必要性はありません。
あるユースケースがすでに広く普及したとき、それを禁止したり新しいものを作るよりも、仕様に組み込むことを考えましょう。
作成者は <br/> という、本来ならば <br> である構文を HTML にて用いています。しかし、これを HTML の構文として受け入れることに害はなにもありません。
革命 (Revolutions) は時に世界を良い方向に変えてくれます。しかしほとんどの場合において、現状のデザインを無駄にするのではなく、発展させる (evolve) ことのほうが良い結果をもたらします。この方法では、作成者は新しいモデルを覚える必要がなくなり、また Web 上の文書を存えさせることにもなります。わかりやすく言えば、無関係な変更を行う必要なく、古いWebページが新しい機能の恩恵を受けられることを、人は好むということです。また、実装も別に新しいモードを用意することなく、現在のコードに新しい機能を追加していけることも意味します。
XML 構文への以降はグローバルな変更を必要とします。そのため、クラシックな HTML 構文のサポートも継続します。
次に述べるのは、HTML を多様な範囲で効果的に利用できるようにするための設計原則です。
仕様を変更することで、実際の問題を解決するようにしなければなりません。これは既存のニーズに応えるものではない抽象的なアーキテクチャよりも、Web サイトが直面している問題への解決策のほうが好まれることにあります。また、それらの広く知られる問題は、可能な限り解決されるべきであるからです。
意見の不一致や対立が起こった場合、ユーザー、作成者、実装者、仕様書、理論上の純粋さという順番で考慮してください。これは、「ユーザーにかかる困難やコストは、作成者にかかるものよりも重要であり、また作成者のコストは実装者より、さらに実装者は仕様書より、そして仕様書は理論的な理由より…」と、考慮において優先度があるということです。もちろん、これらの対象を一度に考慮できるのであれば、それはより好ましいことです。
機能が Web のセキュリティモデルに沿って動作するのかをきちんと確認します。望ましいのは、仕様書でセキュリティに関する考察を提供することです。
さまざまなサイト間で文書を通信することは便利ですが、無制限に行えばユーザーデータを危険にさらすこととなります。クロスドキュメントメッセージングを用意することで、セキュリティの制約を破ることなく、安全な通信を可能とすることを目指しています。
HTML は内容と装飾の分離を行うことができるようになっています。このため、構造的なマークアップはプレゼンテーショナルなマークアップよりも推奨されます。しかし、構造的なマークアップはたとえば メディアに依存しない文書 の作成など、ある目的に対する手段のひとつでしかありません。他の方法でその目的が達成できるのであれば、詳細で意味深いマークアップは必ずしも必要ではありません。たとえば、メディアごとに理にかなった表示を規定することなどで充分でしょう。HTML は意味の表現性と実用性のバランスを取るべき仕様です。たとえば、要素や属性には、その歴史や短さ、簡潔さなどの理由から、正確というよりは実用的な名前を持つものがあります。
article 要素はひとつの記事を表すと定義されていますが、どのように表示されるかは決められていません。たとえば雑誌の記事はページにひとつのみで、段組になっているかもしれません。一方で、blog では他のエントリーも同じページに表示され、また枠がつけられているかもしれません。
b 要素と i 要素は広く使われています。このため、これらの要素を禁止するよりも、描画方法を (音声メディアも含め) 規定するほうがよいでしょう。
二つの構文は、それぞれのパーサによって生成された DOM ツリーが一貫性をもち、またスクリプトや文書ツリー上に影響するコードで処理可能となるようにデザインされるべきです。レガシーな実装と互換性を取るための不一致は許可されますが、しかしその差異は可能な限り小さく抑えるべきです。
レガシーな実装や、現在の Web コンテンツとの互換性を確保する必要のない場合、不必要な構文の違いは避けるべきです。
HTML 5 の XML 構文と互換性を持たせるため、HTML (text/html) パーサは DOM 内で要素を http://www.w3.org/1999/xhtml 名前空間に配置します。
次の指針は、相互運用が完全に可能な HTML の実装を促すことを目的として書かれたものです。
曖昧であったり、実装で定義された挙動よりも、明確で作成者が信頼することのできる挙動を定義することを考えてください。挙動の定義がなされれば、多くのユーザーエージェントで動作するページを作成することができます。それでも実装は、ユーザーインターフェースや描画の質などを問題なく改善することができるでしょう。
できる限り簡潔な定義のほうが、複雑なものよりも好まれます。簡単な機能はユーザーエージェントの実装も容易であり、その結果相互運用性の向上が見込まれます。また、作成者にとっても分かりやすいでしょう。しかし、この考え方は他の要件を満たさないときの言い訳として使うものではありません。
エラー処理は、実装の相互運用を実現するために定義されるべきものです。エラー処理を行うことにより、ユーザーが深刻なエラーの影響を受けることがありません。
機能はユニバーサルアクセスを考えた上で設計されることが推奨されます。このカテゴリでは、ユニバーサルアクセスに関連する項目について説明します。
機能はできる限り、異なるプラットフォームやデバイス、メディアにおいて動くようにならなければなりません。しかし、これは「この機能はサポートできないメディアやプラットフォームがあるので削除する」という意味ではないことに注意してください。たとえば、インタラクティブな機能は印刷用の文書において表現できませんが、だからといってそれを削除すべきではありません。
文字を組版の様に固定して表示させるよりも、HTML の持つ折り返し機能のほうがさまざまな画面サイズに対応できます。
ハイパーリンクは印刷された文章において機能することはありません。しかし、だからといって a 要素を削除する理由はありません。
世界中の言語で情報発信を行うことができるようにしましょう。しかし、これは「すべての言語においてあてはまらない特徴を除外し、書き方を統一する」という意味ではないことに注意してください。また、ひとつの Web ページを多言語で提供するという機能については HTML の範疇ではないことにも注意してください。
Unicode をサポートすることにより、世界中の言語ほとんどすべてが記述可能になります。また、異なる言語を混ぜて書くことも可能です。
斜体は大文字と小文字を持つ言語の多くで有効ですが、いくつかの言語には斜体の概念と言うものがありません。同様に、ルビは多くの文字種を持つ言語においてとても有効ですが、その対象は CJK (Chinese、Japanese、Korean) に焦点が当たったものとなるでしょう。
要素内容のテキストは属性の内容よりも良いサポートを得ることができます。たとえば、ルビを挿入することができます。また dir 属性や bdo 要素は、書字方向の異なる言語が混ざった文書、つまり Unicode の双方向アルゴリズムを用いにくい場合において有効です。
機能を障害のあるユーザーに対し、アクセシブルなものとなるように設計しましょう。能力に関係なく誰もがアクセスできることが重要です。しかしこれは「すべてのユーザーがフルに使いこなせない機能は削除すべき」という意味ではありません。このような場合は、代替手段を提供することが推奨されます。
img 要素の画像は盲目のユーザーに見ることはできません。しかし、代替テキストを指定すれば、画像を取り除く必要はありません。
progress 要素は曖昧でないプログレスバーのセマンティクスを持っています。このことにより、進歩情報に対応するアクセシビリティ API にマッピングすることが可能となります。というわけで、この要素は本質的にアクセシブルであるといえます。
編集者はこの文書の執筆にあたり貢献してくれた Charles McCathieNevile、Chris Wilson、Dan Connolly、Henri Sivonen、Ian Hickson、Jirka Kosek、Lachlan Hunt、Nik Thierry、Philip Taylor、Richard Ishida、Stephen Stewart、Steven Faulkner、そして長年 HTML 5 に関わり、Web の向上につとめた方に感謝します。
この文書に協力した方で、もし名前が上のリストにない場合は編集者に申し出てください。追加を行います。