一覧に戻る

HTML Design Principles W3C Working Draft 26 November 2007 について

Open2026/04/07 13:01#W3C#Web

https://www.w3.org/TR/html-design-principles/

各セクションごとに、重要そうなことと気づきをメモする。

2026/03/04 09:34

Abstract

HTML 5 defines the fifth major revision of the core language of the World Wide Web, HTML. This document describes the set of guiding principles used by the HTML Working Group for the development of HTML5. The principles offer guidance for the design of HTML in the areas of compatibility, utility and interoperability.

HTML5 はWorld Wide Webのコア言語であるHTMLの5番目のメジャーリビジョンとして定義されています。このドキュメントにはHTML5の開発のためのHTMLワーキンググループで使われているガイドとなる原則を記載しています。原則は互換性、使いやすさ、相互運用性に関するHTMLのデザインのガイダンスを提供しています。

2026/03/04 09:36

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

このセクションは発行時のこのドキュメントのステータスを記述しています。他のドキュメントがこのドキュメントに優先する場合があります。W3Cの公開資料のリストやこの技術報告書の最新版はW3C technical reports indexで見つかります。

(略)

2026/03/04 09:37

1. Introduction

HTMLワーキンググループには、WHATWGやその他のW3Cワーキンググループを含む、さまざまなコミュニティからの代表者が参加している。

WHATWGによるHTML5の取り組みや、ここ数年のW3Cの各種標準に関する作業の多くは、異なる目標や優れたデザインとは何かという異なる考え方に基づいて行われてきた。有意義な進展を図るためにはこのグループの目標について基本的な合意を 形成する必要がある。

つまり、WHATWGができてHTMLの改善が加速したのは良いが、WHATWGとW3Cでそれぞれ異なるポリシーで改善されてきたので、同じ目標を持って改善していきましょうねということ。

2026/03/04 09:38

1.1. Conformance for Documents and Implementations

多くの言語仕様では、適合要件と有効な文書を処理する実装に対する適合要件が定義されている。しかし、HTML5では適合文書として許可されていない構文についても、実装の適合要件を定義しているので他の言語仕様とは少し毛色が異なる。

こうすることで、HTMLでWebサイトを作る作成者にとっては比較的明確で理解しやすい言語として維持できている。さらに、古い構文や非標準の構文を使用している既存の文書もサポートできるので、エラー処理における相互運用性を高めることが可能になる。

2026/04/07 12:14

2. Compatibility

互換性(compatibility)の解釈はいくつかある。それはときに、後方互換性(backwards compatibility)1、前方互換性(forwards compatibility)2を意味している。しかし、ときに不明確に使われることもある。このセクションでは互換性を明確に定義する。

Footnotes

  1. 新しいブラウザでも古いバージョンのHTMLが使えること

  2. 古いブラウザでも新しいバージョンのHTMLを表示できること(新しい機能は使えなくてもこれまでの機能は問題なく使える状態)

2026/04/07 12:24

2.1 Support Existing Content

既存のコンテンツはユーザーエージェントの処理や動作に依存していることがよくある。仕様を実装するユーザーエージェントが既存のコンテンツの大部分を処理できるようにするために処理要件を規定する必要がある。

稀なケースとして、以前のHTML仕様の機能が仕様通りに実装されていないことに依存しているケースもある。

レガシーな動作を変更する場合、実装(ユーザーエージェント)、作成者の期待を踏まえて以下のことに注意する。

  • 既存のコンテンツの相当量がその機能や動作に依存しているか?
  • 依存しているコンテンツの中に、特に人気のあるウェブサイトで使われているものはあるか?
  • 依存しているコンテンツは、単にテストケースや例として存在するのではなく、実際に閲覧されることを意図しているか?
  • 依存しているコンテンツは、ユーザーが管理された内部サイトのみではなく、一般公開されているWeb上にあるか?
  • 依存しているコンテンツは、特定のユーザーエージェントのみ、あるいは非常に古いものやあまり普及していないものだけを明示的に太陽としているのではなく、現在、複数の任意のあるユーザーエージェントで意図した通りに動作しているか?

提案された変更による利点は、コンテンツの互換性が失われる可能性のあるコストと照らし合わせて検討すべき。しかし、あるものが現状サポートされている言語の一部であるだけで、それに依存することが容認されたり推奨されたりするわけではない。

2.1.1 Examples

多くのサイトが<b>a<i>b</b>c</i>のように誤ってネストされた要素を使っている。作者とユーザーがユーザーエージェントのエラー処理に依存している。このような場合には、エラー処理を定義して互換性を定義する。

いくつかのサイトは下線を引くための<u>要素を使っているが、それもまたサポートする必要がある。

2026/04/07 12:56

Degrade Gracefully

この原則は、主に準拠言語に適用される。

World Wide Webにおいて、作成者は古いユーザーエージェントで問題を引き起こすような新しい言語機能や、何らかの適切なフォールバックを提供しない機能の仕様を躊躇する事が多い。

そのため、新しい機能を利用されている場合であっても古いユーザーエージェントにおいて適切に機能が制限された状態で閲覧できるようにするべきである。

これまでに作成されたすべてのユーザーエージェントや、例えば非常に古いバージョンのブラウザや、ニッチ市場でも普及していないツールまで考慮することが必ずしも適切とは限らない。しかし、以下のカテゴリのユーザーエージェントについては十分に考慮するべき。

  • 主要なWebブラウザの最新バージョン
  • 主要なWebブラウザの普及している旧バージョン
  • 支援技術、モバイルブラウザ、テキスト専用端末、印刷物といった一般的ではないメディアを対象とするユーザーエージェント、特定のニーズを満たすため、専門的な市場に対応するために設計された主要なユーザーエージェント

場合によっては、新機能が特定の種類のユーザーエージェントには適用できないことや、機能低下を許容する形で設計することが現実的でないこともある。例えば、新しいスクリプトAPIは、スクリプト非対応のユーザーエージェントでは動作させることができない。しかし多くの場合次のようなアプローチを採用できる。

  • 新しい要素や属性は、理解されない場合でも本質的な機能を損なうことなく、追加のセマンティクスを提供できる
  • 新しいスクリプトメソッドや属性は、ECMAScriptのイントロダクション機能を使って、スクリプト内で使用する前にテストできる
  • 新しい要素や属性は、CSSを使用して実現可能なセマンティクスとシンプルなデフォルトのレンダリングを提供できるため小さなスタイルシートを追加することでスムーズな機能低下を実現できる
  • 新しい要素、属性、またはスクリプトAPIは追加のスクリプトを使用することでその動作をエミュレートできる場合がありますが、すくりぷとによるアプローチでは、同じレベルのパフォーマンスや利便性が得られない可能性があります。
  • 新しい要素は高度に特殊化されたレンダリングを必要とする場合がありますが、その要素を理解しないユーザーエージェントに対しては代替として異なるコンテンツを提供できるようにします。

このリストは網羅的ではない。場合によってはもう少し複雑なアプローチのほうが効果的であることもあります。