XHTML 1.0: 拡張可能ハイパーテキストマークアップ言語 (original) (raw)

概要

この仕様書は、HTML 4 を XML 1.0 アプリケーションとして再定式化したXHTML 1.0 と、HTML 4 によって定義されているものに対応する3つのDTDとを定義するものである。要素やその属性の意味論は、HTML 4 についてのW3C勧告において定義されている。これらの意味論は、XHTMLの将来的な拡張性の基礎を提供する。既存のHTMLユーザエージェントとの互換性は、小さいガイドラインの集合に従うことにより可能である。

この文書の位置づけ

この節は、この文書の公開時における位置づけを説明したものである。他の文書がこの文書に取って代わるかもしれない。この文書シリーズの最新の位置づけは、W3Cにおいて維持管理されている。

この文書は、W3C会員及びその他の利害関係者によりレビューされ、ディレクターによってW3C勧告として公布されているものである。この文書は安定的な文書であって、参照素材として利用したり、他の文書から規範的リファレンスとしての引用に用いてもかまわない。勧告作成におけるW3Cの役割は、仕様に対する注意を引き、その広範な配備を推進することにある。このことはウェブの機能と相互運用性とを高める。

この文書は W3C HTMLアクティビティの一部として作成されているものである。HTMLワーキンググループ_(メンバー専用)の目標は、HTMLワーキンググループ憲章(メンバー専用)_に論じられている。

現行のW3C勧告及びその他の技術文書の一覧は http://www.w3.org/TR で見ることができる。

HTMLの機能に関する公開の議論は、メーリングリスト www-html@w3.org (アーカイブ)で行われている。

この文書[原文]のエラーは www-html-editor@w3.org までレポートいただきたい。

この文書[原文]の既知のエラーの一覧は http://www.w3.org/2000/01/REC-xhtml1-20000126-errata で入手できる。

目次

1. XHTMLとは何か

XHTMLは、HTML4 [HTML] を再生産し、サブセット化し、拡張する現在及び将来の文書型及びモジュールのファミリーである。XHTMLファミリーの文書型はXMLベースであり、究極的にはXMLベースのユーザエージェントと結びついて機能するよう設計されている。このファミリーやその進化の詳細は、将来的な方向性に関する節でさらに詳しく論じられる。

XHTML 1.0 (この仕様書) は、XHTMLファミリーにおける初めての文書型である。これは、3つのHTML4文書型を XML 1.0 [XML] のアプリケーションとして再定式化したものである。XHTML 1.0 は、XML適合でもあり、かつ、いくつかの単純なガイドラインに従えばHTML4適合ユーザエージェントでも機能するコンテンツのための言語として使われることが予定されている。コンテンツを XHTML 1.0 に移り住ませた開発者は、以下の利点を実感するであろう。

XHTMLファミリーは、インターネットの進化における次の一歩である。今日XHTMLに移り住むことにより、コンテンツ開発者は、コンテンツの後方互換性や将来的な互換性に自信をもちながら、XMLワールドに入り、その付随する利点のすべてを享受することができる。

1.1 HTML4とは何か

HTML4 [HTML] は、国際規格ISO 8879 に適合したSGML (Standard Generalized Markup Language) アプリケーションであり、広くワールド=ワイド=ウェブの標準的なパブリッシング言語とみなされている。

SGMLは、マークアップ言語、とりわけ電子文書の交換や文書管理、文書パブリッシングに使われるマークアップ言語を記述するための言語である。HTMLは、SGMLによって定義された言語の一例である。

SGMLは1980年代半ば以降普及し、きわめて安定性を保っている。この安定性の多くは、言語が機能に富み、かつ柔軟でもあるという事実によっている。しかしながら、この柔軟性は一定のコストによりもたらされるものであり、そのコストとは、ワールド=ワイド=ウェブを含め多様な環境での採用の妨げとなるレベルの複雑さのことである。

HTMLは、もともとそのように考えられていたのだが、文書の専門家でない人々による利用に適した、科学的その他技術的文書の交換のための言語であるべきものであった。HTMLは、SGMLの複雑さの問題を、比較的単純な文書を制作するのに適した構造的タグや意味論的タグの小さいセットを規定することにより処理した。文書構造を単純化したことに加えて、HTMLはハイパーテキストのサポートを追加した。マルチメディア機能が後に追加された。

非常に短い時間のうちに、HTMLはおそろしく普及し、急速に元々の目的からはみ出して成長した。HTMLの始まり以来、(標準規格としての)HTML内部で利用したり、HTMLを垂直的で高度に特化された市場に適合させるための新しい要素が急速に発明されてきた。この新しい要素の過剰は、異なるプラットフォーム間での文書の互換性問題にまて至っている。

ソフトウェア、プラットフォーム両者の異類混交性が急速に増殖するに伴い、これらのプラットフォームで利用することについて「クラシック」なHTML4の適性は幾分か限定されることが明らかである。

1.2 XMLとは何か

XML™ は、拡張可能マークアップ言語(Extensible Markup Language)の短縮形であり、Extensible Markup Language の頭字語である [XML]。

XMLは、SGMLの複雑さのほとんどを抜きにしてSGMLの力と柔軟性とを取り戻す手段として考えられていた。SGMLの制限形式であるにもかかわらず、XMLはSGMLの力と機能の豊富さとのほとんどを保持し、なおも一般に使われているSGMLの機能のすべてを残している。

これらの役に立つ機能を残しつつも、XMLは、適したソフトウェアの製作や設計を困難でコストのかかるものにしているもっと複雑なSGMLの機能を多数取り除いている。

1.3 XHTMLはなぜ必要か

XHTML 1.0 へ移り住むことの利点は、上記に説明されている。一般的にXHTMLへ移り住むことの利点のいくつかを挙げると、つぎのようなものがある。

2. 定義集

2.1 用語集

以下の用語はこの仕様書の中で使われているものである。これらの用語は、ISO/IEC 9945-1:1990 [POSIX.1] での類似の定義に基づいて [RFC2119] での定義を拡張している。

実装定義の (implementation-defined)

正しい文書構造についての対応する必要条件を定義[し文書化]することが実装にゆだねられているとき、値または挙動は実装定義である。

してもよい (may)

実装に関しては、「してもよい」という言葉は、この仕様書では要求されないが提供することができる任意的機能として解釈されるべきものである。文書の適合性に関しては、「してもよい」という言葉は、任意的機能が使われてはならないという意味である。「任意的」という用語は、「してもよい」と同じ定義である。

しなければならない (must)

この仕様書では、「しなければならない」という言葉は、文脈により、実装または厳格適合XHTML文書に関する義務的必要条件として解釈されるべきものである。「すべし」という用語は、「しなければならない」と同じ定義である。

予約済み (reserved)

値または挙動は規定されていないが、適合文書がそれを使うことや、適合ユーザエージェントがそれをサポートすることは許されない。

するべきである (should)

実装に関しては、「するべきである」という言葉は、実装上の勧告であるが必要条件ではないものとして解釈されるべきものである。文書に関しては、「するべきである」という言葉は、文書についての推奨されるプログラミング慣行や、厳格適合XHTML文書についての必要条件として解釈されるべきものである。

サポートされている (supported)

この仕様書にある一定の装備は任意的である。ある装備がサポートされている場合、それはこの仕様書によって規定されている通りの挙動をとる。

規定されていない (unspecified)

値または挙動が規定されていないとき、仕様書は、その装備を利用する文書に直面したときであっても、ある実装上の装備についての可搬性必要条件を定義しない。そうした場面で、その装備を使うときにどのような挙動でも容認するのではなく、特定の挙動を要求する文書は、厳格適合XHTML文書ではない。

2.2 一般的用語

属性 (attribute)

属性とは、DTDで宣言されている要素に対するパラメータである。属性の型や値域は、可能なデフォルト値を含め、DTDの中で定義される。

DTD

DTD、あるいは文書型定義とは、そのDTDに従う文書の中で利用できる合法的な文書構造や要素、属性を、集合体として定義するXML宣言の集合体である。

文書 (document)

文書とは、参照先のその他すべてのストリームと組み合わされた後、結びつけられたDTDで定義されているとおりに組織された要素の中に含まれている情報を保持するよう構築されたデータのストリームである。

要素 (element)

要素とは、DTDで宣言される、文書を構築する単位である。要素の内容モデルはDTDの中で定義され、追加的な意味論がその要素の散文的解説の中で定義される場合がある。

装備 (facilities)

機能(functionality)には、要素や属性と、それらの要素や属性に結びつけられた意味論とが含まれる。その機能をサポートしている実装は、必要な装備を用意していると言われる。

実装 (implementation)

実装とは、装備やこの仕様をサポートするサービスの集合体を用意するシステムである。詳しい情報についてはユーザエージェントの適合性を見よ。

解析 (parsing)

解析とは、それによって文書をスキャンし、文書に含まれている情報を、その情報が構造化されている要素の文脈の中へとフィルタリングする行動である。

レンダリング (rendering)

レンダリングとは、それによって文書の中にある情報を呈示する行動である。この呈示は、その環境にとって最も適切な形式(例. 音声的、視覚的、印刷)でなされる。

ユーザエージェント (user agent)

ユーザエージェントとは、XHTML文書を引き出して処理する実装である。詳しい情報についてはユーザエージェントの適合性を見よ。

妥当性検証 (validation)

妥当性検証とは、それにより、結びつけられているDTDに照らして文書を検証して、構造や、要素の使い方、属性の使い方がDTD内の定義と無矛盾であることを確かめる処理である。

整形式の (well-formed)

文書は、XML 1.0 勧告 [XML] の Section 2.1 に定義されている規則に従って構築されているとき、整形式である。基本的には、この定義は、要素が開始タグと終了タグとで区切られ、互いに適切にネストされているということを言うものである。

3. XHTML 1.0 の規範的定義

3.1 文書の適合性

このバージョンのXHTMLは、厳密適合XHTML文書の定義を用意する。この厳密適合XHTML文書とは、XHTML名前空間に由来するタグと属性とに制限されているものである。XHTMLを他の名前空間と一緒に使って、たとえばXHTML文書の中にRDFで表記されたメタデータを組み込むことに関する情報については、第3節第1項2を見よ。

3.1.1 厳密適合文書

厳密適合XHTML文書とは、この仕様書で義務的なものとして説明されている装備のみを要求する文書である。そうした文書は、以下の評価基準のすべてに合致しなければならない。

  1. 付録Aにある3つのDTDのうち1つに照らして正当化されなければならない。
  2. 文書のルート要素は <html> でなければならない。
  3. 文書のルート要素は、xmlns 属性を使うXHTML名前空間 [XMLNAMES] を指し示さなければならない。XHTMLを表す名前空間は http://www.w3.org/1999/xhtml と定義されている。
  4. ルート要素に先立って、文書の中に DOCTYPE 宣言が1個なければならない。DOCTYPE 宣言に組み込まれる公開識別子は、付録Aにある3つのDTDのうち1つを、それぞれの公式公開識別子を使って参照しなければならない。システム識別子は、ローカルシステム慣習を反映するために変更されてもかまわない。

こちらは、最小のXHTML文書の例である。

バーチャル図書館

vlib.org へ移転しました。

この例ではXML宣言が組み込まれていることに注意してほしい。上記のようなXML宣言は、すべてのXML文書に必須というわけではない。XHTML文書の制作者は、すべての文書でXML宣言を使うよう強く奨励される。文書のキャラクタエンコーディングがデフォルトの UTF-8 か UTF-16 以外のものであるときは、そうした宣言は必須である。

3.1.2 XHTMLを他の名前空間と一緒に使う

そうした文書は上記に定義した厳格適合 XHTML 1.0 文書ではないけれども、XHTML名前空間は、[XMLNAMES]に従って他のXML名前空間と一緒に使ってもかまわない。W3Cによる将来の作業により、複数の名前空間を巻き込む文書についての適合性を規定する方法を処理されるであろう。

以下の例は、XHTML 1.0 をMathML勧告と結合して利用できる方法を示したものである。

数学の例

以下はMathMLマークアップである。

3 x

以下の例は、XHTML 1.0 マークアップを他のXML名前空間に統合できる方法を示したものである。

まとめ買いでおトクに isbn:number1568491379

これは オンライン でもお求めになれます。

3.2 ユーザエージェントの適合性

適合ユーザエージェントは、以下の評価基準のすべてに合致しなければならない。

  1. XML 1.0 勧告 [XML] と無矛盾であるために、ユーザエージェントは整形式性についてXHTML文書を解析して評価しなければならない。ユーザエージェントが妥当性検証を行うユーザエージェントであると主張する場合には、[XML] に従って参照先のDTDに照らして文書の妥当性も検証しなければならない。
  2. ユーザエージェントが、この仕様書で定義されていたり、規範的な参照資料を通じてこの仕様書によって要求されている装備をサポートしていると主張するときは、その装備の定義と無矛盾な方法でそうしなければならない。
  3. ユーザエージェントがXHTML文書を汎用XMLとして処理するときは、フラグメント識別子として ID 型の属性(たとえばほとんどのXHTML要素上の id 属性)のみを認識すべし。
  4. ユーザエージェントが認識しない要素に遭遇した場合は、その要素の内容をレンダリングしなければならない。
  5. ユーザエージェントが認識しない属性に遭遇した場合は、その属性指定全体(すなわち属性とその値)を無視しなければならない。
  6. ユーザエージェントが認識しない属性値に遭遇した場合は、デフォルトの属性値を使わなければならない。
  7. ユーザエージェントがその宣言を処理していない(定義済み実体以外の)実体参照に遭遇した場合(これはユーザエージェントがまだ読んでいない外部サブセットの中に宣言がある場合に起こりうる。)、その実体参照は、その実体参照を作り上げている(アンパサンドで始まりセミコロンで終わる)キャラクタとしてレンダリングされるべきである。
  8. コンテンツをレンダリングするとき、認識するけれどもレンダリングできないキャラクタやキャラクタ実体参照に遭遇したユーザエージェントは、正常なレンダリングが行われていないことがユーザにとって明らかであるような方法で文書を表示するべきである。
  9. 以下のキャラクタは、[XML] によって空白キャラクタとして定義されている。
    • スペース ( )
    • タブ ( )
    • 復帰 ( )
    • 行送り ( )
      XMLプロセッサは、アプリケーションへ渡されるいろいろなシステムの行末コードを、単一の行送りキャラクタへと通常化する。XHTMLユーザエージェントはさらに、以下のキャラクタを空白として扱わなければならない。
    • フォームフィード ( )
    • ゼロ幅スペース (​)
      'xml:space' 属性が 'preserve' に設定されている要素では、ユーザエージェントは(先頭及び末尾の空白キャラクタを例外として。これらは除去されるべきである。)すべての空白キャラクタに手をつけずにおかなければならない。それ以外の場合には、空白は以下の規則に従って処理される。
    • ブロック要素を取り囲む空白は、すべて除去されるべきである。
    • 注釈は完全に除去され、空白の処理に影響しない。注釈の片側にある1個の空白キャラクタは、2個の空白キャラクタとして扱われる。
    • ブロック要素内部にある先頭及び末尾の空白は、除去されるべきである。
    • ブロック要素内部にある行送りキャラクタは、スペース1個に変換されなければならない。('xml:space' 属性が 'preserve' に設定されているときを除く。)
    • 空白キャラクタの連なりは、単一の空白キャラクタに縮小されなければならない。('xml:space' 属性が 'preserve' に設定されているときを除く。)
    • レンダリングに関して、ユーザエージェントは、コンテンツを書いている言語に適した方法で、コンテンツをレンダリングするべきである。主たる文字がラテン文字である言語では、ASCIIスペースキャラクタは概して、文法上のな単語の境界と印刷術的な空白との双方をエンコードするのに使われる。文字がナガリ文字に関係している言語(例. サンスクリット語、タイ語など)では、文法上のな境界はゼロ幅「スペース」キャラクタを使ってエンコードされることがあるが、レンダリングされたアウトプットには印刷術的なスペースによって表現されないのが典型である アラビア形式の文字を使う言語は、スペースキャラクタを使って印刷術的な空白をエンコードすることがあるが、「内部的な」文法上の境界を区切るのにゼロ幅スペースキャラクタも使われることがある (英語の目にとってアラビア語の単語のように見えるものが、しばしば数個の単語をエンコードしている。例. 'kitAbuhum' = 'kitAbu-hum' = 'book them' == their book)。また、中国文字の伝統にある言語は概して、そうした区切りをエンコードせず、またこのような印刷術的な空白も使わない。
      属性値の中の空白は、[XML] に従って処理される。

4. HTML4との相違点

XHTMLがXMLアプリケーションであるという事実のために、SGMLベースのHTML4 [HTML] では完全に合法であった一定の慣習が変更されなければならない。

4.1 文書は整形式でなければならない

整形式性は、[XML] によって導入された新しい概念である。本質的には、これは、すべての要素が終了タグを持つか(後述のとおり)特殊な形式で書かれるかしなければならず、またすべての要素がネストしていなければならないという意味である。

重なり合いはSGMLでも違法であったが、既存のブラウザでは広く容認されていた。

正: 要素がネストされている。

こちらは強調されている段落です。

誤: 要素が重なり合っている。

こちらは強調されている段落

です。

4.2 要素名及び属性名は小文字でなければならない

XHTML文書は、すべてのHTML要素名及び属性名に小文字を使わなければならない。この相違点が必要なのは、XMLが大文字小文字を区別し、たとえば

  • と
  • とは異なるタグだからである。

    • 4.3 非空要素については終了タグが必須である

    SGMLベースのHTML4では、一定の要素は終了タグを省略することが許されていた。そうした要素には黙示的な閉鎖がついていたのである。この省略は、XMLベースのXHTMLにおいては許されない。DTDの中で EMPTY として宣言されているものを除き、すべての要素が終了タグをもたなければならない。

    正: 要素が終結している。

    こちらに段落があります。

    こちらにもう一つ段落があります。

    誤: 要素が終結していない。

    こちらに段落があります。

    こちらにもう一つ段落があります。

    4.4 属性値はつねに引用符で括られなければならない

    属性値はすべて、たとえ数値のように見えるときであっても、引用符で括られなければならない。

    正: 属性値が引用符で括られている。

    誤: 属性値が引用符で括られていない。

    4.5 属性最小化

    XMLは、属性最小化をサポートしていない。属性-値のペアは完全形式で書かれなければならない。compact や checked といったような属性名は、その値を指定するのでなければ要素の中に出現することができない。

    正: 属性が最小化されていない。

    誤: 属性が最小化されている。

    4.6 空要素

    空要素は、たとえば、<br/> や <hr></hr> のように、終了タグをもつか、あるいは開始タグが /> で終わっているかでなければならない。これがHTML4ユーザエージェントと後方互換的であることを確かめる方法に関する情報については、HTML互換性ガイドラインを見よ。

    正: 空タグが終結している。


    4.7 属性値内での空白の処理

    属性値の中では、ユーザエージェントは、属性値から先頭及び末尾の空白を剥ぎ取り、1個以上の空白キャラクタ(改行を含む)が連なったものは単一の単語間スペース(西洋文字ではASCIIスペースキャラクタ)に割り付けることになる。[XML] の第3節第3項3 を見よ。

    4.8 スクリプト要素及びスタイル要素

    XHTMLでは、スクリプト要素やスタイル要素は、#PCDATA を持つものとして宣言される。結果として、< や & は、マークアップの始まりとして扱われ、&lt; や &amp; といったような実体は、実体参照としてXMLプロセッサがそれぞれ < や & に認識することになる。スクリプト要素やスタイル要素の内容を CDATA マークされた部分の中に包み込むことにより、これらの実体の展開が避けられる。

    CDATA 部は、XMLプロセッサにより認識され、文書オブジェクトモデルの中ではノードとして出現する。DOM1勧告 [DOM] の第1節第3項を見よ。

    代替策は、外部スクリプトやスタイル文書を使うことである。

    4.9 SGMLの排除機能

    SGMLは、DTDの筆者に、特定の要素がある要素の中に包含されないよう排除する能力を与えている。そうした禁止(「排除」と呼ばれる)は、XMLでは不可能である。

    たとえば、HTML 4 Strict DTD は、'a' 要素の中に他の 'a' 要素をネストすることを、子孫の深さを問わず禁止している。そうした禁止をXMLで綴ることは不可能である。これらの禁止をDTDの中で定義することはできないが、一定の要素はネストされるべきではない。そうした要素や、そうした要素の中にネストされるべきではない要素をまとめたものは、規範的である付録Bで見られる。

    4.10 'id' 及び 'name' 属性つきの要素

    HTML4は、a, applet, form, frame, iframe, img, map 要素について name 属性を定義している。またHTML4は、id 属性も導入している。これらの属性はともにフラグメント識別子として使われるよう設計されている。

    XMLでは、フラグメント識別子は ID 型であり、要素ごとに ID 型の属性は1個しかありえない。したがって、XHTML 1.0 では、id 属性が ID 型として定義されている。XHTML 1.0 文書が適正に構築されたXML文書であることを保証するために、XHTML 1.0 文書は、フラグメント識別子を定義するときには、歴史的には name 属性ももっている要素であっても、id 属性を使わなければならない。XHTML文書がメディア型 text/html として配布されるときにそうしたアンカーが後方互換であることを保証することに関する情報については、HTML互換性ガイドラインを見よ。

    XHTML 1.0 では、これらの要素の name 属性は公式には廃止予定であり、後続バージョンのXHTMLでは取り除かれるであろうから、注意してほしい。

    5. 互換性問題

    XHTML 1.0 文書が既存のユーザエージェントと互換的であるべしとの必要条件はないものの、実際にはこれは容易に達成できる。互換的な文書を作成するためのガイドラインは、付録Cで見ることができる。

    5.1 インターネットメディア型

    この勧告の公開時まででは、XMLベースのアプリケーション用に推奨される一般的なMIMEラベリングは、まだ未解決である。

    もっとも、付録C "HTML互換性ガイドライン" で打ち出されているガイドラインに従ったXHTML文書は、ほとんどのHTMLブラウザと互換的であるから、インターネットメディア型 "text/html" でラベル付けしてもよい。この文書は、その他のXHTML文書のMIMEラベリングについての勧告はしない。

    6. 将来的な方向性

    XHTML 1.0 は、広範囲の新しいデバイスやアプリケーションをサポートするため、モジュールを定義し、これらのモジュールを組み合わせるメカニズムを指定することにより、XHTMLを拡張したりサブセット化する文書型のファミリーのための基礎を用意するものである。このメカニズムは、新しいモジュールの定義を通じた統一的な方法で XHTML 1.0 の拡張やサブセット化を可能にするであろう。

    6.1 HTMLのモジュラ化

    XHTMLの利用が伝統的なデスクトップユーザエージェントからその他のプラットフォームへと移行するにつれて、すべてのXHTML要素がすべてのプラットフォームで要求されることになるわけではないことが明らかである。たとえば、ハンドヘルドのデバイスや携帯電話は、XHTML要素のサブセットだけをサポートするのでもかまわない。

    モジュラ化処理により、XHTMLは、さらに小さい要素セットが連なったものへと分解される。そうして、これらの要素を、いろいろなコミュニティの必要に沿うよう組み合わし直すことができるのである。

    これらのモジュールは、今後のW3C文書で定義されることになる。

    6.2 サブセットと拡張性

    モジュラ化は、いくつかの利点をもたらす。

    • XHTMLをサブセット化するための形式面のメカニズムを提供する。
    • 既存のXHTMLについて、形式面のメカニズムを用意する。
    • 文書型間の変形を単純化する。
    • 新しい文書型の中でモジュールを再利用するのを促進する。

    6.3 文書プロファイル

    文書プロファイルとは、文書のセットの文法や意味論を規定するものである。文書プロファイルに従うことが、相互運用性の保証の基礎を提供する。文書プロファイルは、たとえば使える画像フォーマットやスクリプトのレベル、スタイルシートのサポートなどはどのようなものかといったような、その型の文書を処理するために必要とされる装備を規定する。

    製品設計者にとっては、このことから、多様なグループが独自の標準プロファイルを定義することが可能になる。

    制作者にとっては、このことから、いろいろなクライアントのためにいろいろなバーションの文書をいくつか書く必要が事前に除去されることになる。

    化学者や医者、数学者といったような特殊なグループにとっては、このことから、標準的なHTML要素に加えてその専門家の必要に連動した要素グループを利用するよう、特別なプロファイルを構築することが可能となる。

    付録A. DTD

    この付録は規範的である。

    これらのDTDと実体セットとは、この仕様書の規範的部分を構成する。XML宣言やSGMLオープンカタログが一緒になった完全セットのDTDファイルは、この仕様書[原文]のzipファイルに組み込まれている。

    A.1 文書型定義

    これらのDTDは、HTML4 DTD を近似したものである。DTDがモジュラ化されるときには、さらにHTML4に密接に対応したDTD構築の方法が採用されることになる可能性が強い。

    A.2 実体セット

    XHTML実体セットはHTML4用と同じものであるが、妥当な XML 1.0 実体宣言であるよう修正されている。ユーロ通貨記号を表す実体 (&euro; あるいは &#8364;, &#x20AC;) は特殊キャラクタの一部として定義されているので注意してほしい。

    付録B. 要素の禁止事項

    この付録は規範的である。

    以下の要素には、包含できる要素についての禁止事項がある(第4節第9項を見よ)。この禁止事項は、すべてのネスト深度に適用される。すなわち、すべての子孫要素を含んでいるのである。

    a

    他の a 要素を包含してはいけない。

    pre

    img, object, big, small, sub, sup 要素を包含してはいけない。

    button

    input, select, textarea, label, button, form, fieldset, iframe, isindex 要素を包含してはいけない。

    label

    他の label を包含してはいけない。

    form

    他の form 要素を包含してはならない。

    付録C. HTML互換性ガイドライン

    この付録は参考である。

    この付録は、XHTML文書を既存のHTMLユーサーエージェントでレンダリングしたいと願う制作者のための設計ガイドラインをまとめたものである。

    C.1 処理命令

    処理命令をレンダリングするユーザエージェントもあることを意識すること。もっとも、XML宣言が文書に組み込まれていないときには、文書はデフォルトのキャラクタエンコーディングである UTF-8 か UTF-16 しか使えないことにも注意すること。

    C.2 空要素

    たとえば <br /> や <hr />, <img src="karen.jpg" alt="Karen" /> といったように、空要素の末尾の / と > との前にスペースを1個組み込むこと。また、たとえば <br /> といったように、空要素には最小化タグ文法を使うこと。これは、XMLで許容されている代わりの文法 <br></br> は、多くの既存のユーザエージェントでは与えられる結果が一定しないからである。

    C.3 要素最小化と空要素内容

    内容モデルが EMPTY ではない要素に空インスタンスが与えられる場合(たとえば空のタイトルや段落)には、最小化形式は使わないこと(たとえば <p /> は使わず <p> </p> を使う)。

    C.4 埋め込みスタイルシート及びスクリプト

    スタイルシートが < か & か ]]> か -- かを使っている場合には、外部スタイルシートを使うこと。スクリプトが < か & か ]]> か -- かを使っている場合には、外部スクリプトを使うこと。注釈の内容を黙って除去することがXMLパーサには許されていることに注意すること。したがって、文書を後方互換的にするために注釈の中にスクリプトやスタイルシートを「隠す」という歴史的な慣習は、XMLベースの実装では期待したとおりに働かない可能性が強い。

    C.5 属性値内部での改行

    属性値の内部では改行や重複空白キャラクタは避けること。これらは、ユーザエージェントによって扱いが一貫しない。

    C.6 Isindex

    文書の head の中に2個以上の isindex を組み込まないこと。isindex 要素は、input 要素の方が好まれて廃止の方向にある。

    C.7 lang 属性と xml:lang 属性

    要素の言語を指定するときには lang と xml:lang との双方を使うこと。xml:lang 属性の値が優先する。

    C.8 フラグメント識別子

    XMLでは、"#foo" という形式のフラグメント識別子で終わるURI [RFC2396] は、name="foo" という属性をもつ要素を参照するのではない。それよりも、たとえばHTML4の id 属性といったような、ID 型として定義されている属性をもつ要素を参照するのである。多くの既存のHTMLクライアントは、このような ID 型属性の使用法をサポートしていないので、最大の前方互換性と後方互換性とを保証するために、これらの属性の両方について同一の値を補ってもかまわない。(例. <a id="foo" name="foo">...</a>)

    さらに、ID 型の属性の合法的な値のセットは、CDATA 型のものよりも遙かに小さいから、name 属性の型は NMTOKEN に変更されている。この属性は、ID 型か、XML 1.0 第2節第5項の生成規則5にある Name 生成規則かと同じ値しかとれないよう制約されている。残念ながら、この制約は XHTML 1.0 DTD の中に表記することができない。この変更のせいで、既存のHTML文書を変換するときには注意を払わなければならない。これらの属性の値は、文書内部で一意的であり、妥当でなければならず、もしも変換の間に値が変更される場合には、これらのフラグメント識別子(内部てきなものも外部的なものも)への参照はどれも更新されなければならない。

    最後に、XHTML 1.0 は a, applet, form, frame, iframe, img, map 要素の name 属性を廃止予定としており、後続バージョンのXHTMLからは除去されるであろうから注意すること。

    C.9 キャラクタエンコーディング

    文書の中でキャラクタエンコーディングを指定するためには、xml 宣言でのエンコーディング属性の指定 (例. <?xml version="1.0" encoding="EUC-JP"?>) と meta http-equive ステートメント (例. <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />) とを両方とも使うこと。xml処理命令のエンコーディング属性の値が優先する。

    C.10 ブール値属性

    HTMLユーザエージェントによっては、ブール値属性が完全(非最小化)形式で出現したとき、XML 1.0 で要求されているとおりに解釈できないものがある。この問題は、HTML4に準拠したユーザエージェントには影響を及ぼさないことに注意してほしい。以下の属性が関係する。compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

    C.11 文書オブジェクトモデルとXHTML

    文書オブジェクトモデル第一水準勧告 [DOM] は、XMLやHTML4のための文書オブジェクトモデルインターフェイスを定義している。HTML4文書オブジェクトモデルは、HTML要素名及び属性名は大文字で返されることを規定している。XML文書オブジェクトモデルは、要素名及び属性名は、それらが指定されている文字で返されることを規定している。XHTML 1.0 では、要素や属性は小文字で指定される。この明白な相違点は、2つの方法で処理することができる。

    1. インターネットメディア型 text/html としてDOM経由で配布されるXHTML文書にアクセスするアプリケーションは HTML-DOMを使うことができ、そのインターフェイスからは要素名や属性名が大文字で返されることを当てにすることができる。
    2. インターネットメディア型 text/xml または application/xml として配布されるXHTML文書にアクセスするアプリケーションは、XML-DOMを使うこともできる。要素や属性は、小文字で返されることになる。また、XHTML要素によっては、内容モデルにおいて任意的であるため、オブジェクト樹に出現したりしなかったりするものもある(例. table 要素内の tbody 要素)。このことは、HTML4では、いくつかの要素で、開始タグと終了タグとを両方とも省略されるよう最小化することが許されていた(SGMLの特徴)ために発生する。これはXMLでは起こりえない。無関係な要素を挿入するよう文書制作者に要求する代わりに、XHTMLは要素を任意的なものとしている。アプリケーションは、きちんとこれに対応する必要がある。

    C.12 属性値の中でアンパサンドを使う

    属性値にアンパサンドが含まれているとき、アンパサンドはキャラクタ実体参照(例. "&amp;")として表記しなければならない。たとえば、a 要素の href 属性が、パラメータをとるCGIスクリプトを参照しているときには、http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user ではなく http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user と表記しなければならない。

    C.13 カスケーディングスタイルシート(CSS)とXHTML

    カスケーディングスタイルシート第二水準勧告 [CSS2] は、HTML文書やXML文書の解析樹に適用されるスタイルプロパティを定義している。解析の際の相違点は、使われているセレクタ次第で視覚的または聴覚的に、異なる結果を生み出すことになる。以下のヒントは、両方のメディア型としての修正がないまま配布される文書について、この効果を小さくすることであろう。

    1. XHTML用のCSSスタイルシートは、小文字の要素名や属性名を使うべきである。
    2. テーブルの中では、tbody 要素は、HTMLユーザエージェントのパーサには推断されるが、XMLユーザエージェントのパーサには推断されないことになる。したがって、それがCSSセレクタの中で参照されている場合には、つねに明示的に tbody 要素を追加するべきである。
    3. XHTML名前空間の中では、ユーザエージェントは "id" 属性をID型の属性として認識することが予定されている。したがって、ユーザエージェントがDTDを読まない場合であっても、スタイルシートが短縮 "#" セレクタ文法を使い続けられるべきである。
    4. XHTML名前空間の中では、ユーザエージェントは "class" 属性を認識できることが予定されている。したがって、スタイルシートが短縮 "." セレクタ文法を使い続けられるべきである。
    5. CSSは、HTML文書とXML文書について異なる適合性規則を定義している。HTMLとして引き出されたXHTML文書には規則が適用され、XMLとして引き出されたXHTML文書にはXML規則が適用されることを意識すること。

    付録D. 謝辞

    この付録は参考である。

    この仕様書は、W3C HTMLワーキンググループのメンバーの参加を得て書かれたものである。

    Steven Pemberton, CWI (HTMLワーキンググループ長)
    Murray Altheim, Sun Microsystems
    Daniel Austin, AskJeeves (1999年7月まで CNET: The Computer Network)
    Frank Boumphrey, HTML Writers Guild
    John Burger, Mitre
    Andrew W. Donoho, IBM
    Sam Dooley, IBM
    Klaus Hofrichter, GMD
    Philipp Hoschka, W3C
    Masayasu Ishikawa, W3C
    Warner ten Kate, Philips Electronics
    Peter King, Phone.com
    Paula Klante, JetForm
    Shin'ichi Matsui, Panasonic (1999年9月まで W3C客員エンジニア)
    Shane McCarron, Applied Testing and Technology (1999年8月まで The Open Group)
    Ann Navarro, HTML Writers Guild
    Zach Nies, Quark
    Dave Raggett, W3C/HP (W3C HTMLリーダー)
    Patrick Schmitz, Microsoft
    Sebastian Schnitzenbaumer, Stack Overflow
    Peter Stark, Phone.com
    Chris Wilson, Microsoft
    Ted Wugofski, Gateway 2000
    Dan Zigmond, WebTV Networks

    付録E. 参照資料

    この付録は参考である。

    [CSS2]

    "Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 1998年5月12日.
    最新バージョンは http://www.w3.org/TR/REC-CSS2 で入手可能。

    [DOM]

    "Document Object Model (DOM) Level 1 Specification", Lauren Wood 他, 1998年10月1日.
    最新バージョンは http://www.w3.org/TR/REC-DOM-Level-1 で入手可能。

    [HTML]

    "HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 1999年12月24日.
    最新バージョンは http://www.w3.org/TR/html401 で入手可能。

    [POSIX.1]

    "ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", Institute of Electrical and Electronics Engineers, Inc, 1990年.

    [RFC2046]

    "RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed and N. Borenstein, 1996年11月.
    http://www.ietf.org/rfc/rfc2046.txt で入手可能。このRFCは RFC1521, RFC1522, RFC1590 を破棄するものであるので注意すること。

    [RFC2119]

    "RFC2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, 1997年3月.
    http://www.ietf.org/rfc/rfc2119.txt で入手可能。

    [RFC2376]

    "RFC2376: XML Media Types", E. Whitehead, M. Murata, 1998年7月.
    http://www.ietf.org/rfc/rfc2376.txt で入手可能。

    [RFC2396]

    "RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月.
    この文書は RFC1738 と RFC1808 とを更新するものである。http://www.ietf.org/rfc/rfc2396.txt で入手可能。

    [XML]

    "Extensible Markup Language (XML) 1.0 Specification", T. Bray, J. Paoli, C. M. Sperberg-McQueen, 1998年2月10日.
    最新バージョンは http://www.w3.org/TR/REC-xml で入手可能。

    [XMLNAMES]

    "Namespaces in XML", T. Bray, D. Hollander, A. Layman, 1999年1月14日.
    XML名前空間は、XML文書の中で使われている名前を、URIによって識別される名前空間に結びつけることにより修飾するための単純な手段を提供するものである。
    最新バージョンは http://www.w3.org/TR/REC-xml-names で入手可能。

    トリプルAレベル適合アイコン. W3C-WAI ウェブコンテンツ アクセシビリティガイドライン 1.0

    どら猫本舗 (webmaster@doraneko.org)