W3Cワーキングドラフト 1999年3月4日
この仕様書は、HTML 4.0 を XML 1.0 アプリケーションとして再定式化した XHTML 1.0 と、HTML 4.0 によって定義された名前空間に対応する3つの名前空間を定義するものである。要素やその属性の意味論は、HTML 4.0 についてのW3C勧告で定義される。これらの意味論は、XHTMLの将来の拡張性に基盤を提供する。既存のHTMLユーザエージェントとの互換性は、小セットのガイドラインに従うことにより可能である。
このワーキングドラフトは、何時にても他のW3C文書によって更新され、置換され、または廃止されることがある。W3Cワーキングドラフトを参照資料として利用したり、「進行中の作業」以外のものとして引用することは不適切である。この文書は進行中の作業であり、W3C会員組織による保証としての意味合いを含むものではないので注意されたい。
この仕様書は最終案内(last call)に入っており、コメントは1999年3月24日より前に求められる。このバージョンのワーキングドラフトは、先のバージョン(2月24日)で検知された2つのエラーを訂正したものである。この2つのエラーとは、frame 要素に src 属性が欠けていたことと、名前空間URIが ".dtd" で終了しており不正だったこととである。
この文書は W3C HTMLアクティビティの一部として作成されているものである。HTMLワーキンググループ(会員限定)の目標は、HTMLワーキンググループ検証(会員限定)に論じられている。
ワーキンググループ内でまだ緩やかに継続しており、我々がそれについて特にコメントを受け取ることに興味のある問題が1つある。我々は新しいインターネットメディア型 "text/xhtml" を登録すべきか否かという問題である。
ごく簡単に言うと、選択肢には2つある。yes - リソースにアクセスすることなく応用型を認識するにはそれが唯一の方法である。no - この問題はすべてのXMLアプリケーションにあるであろうことであり、アプリケーションを一つずつ登録するのでは答えにならない。
HTMLをモジュラ化したり他のXMLターゲットと組み合わせたりするための基礎として文書プロファイルを定義するアイデアに関しては、作業が続いている。第6節「将来的な方向性」を見ること。
この文書に関する詳細なコメントを www-html-editor@w3.org までお送り願いたい。我々は個人的な応答を保証できないが、それが適切であるときには努力するつもりである。HTML機能に関する公開の議論は、メーリングリスト www-html@w3.org (アーカイブ)で行われる。HTMLに関する作業についてのW3Cスタッフ連絡役は Dave Raggett である。
XHTMLは、HTML 4.0 [HTML] を XML 1.0 [XML] のアプリケーションとして再定式化したものである。
XHTML 1.0 は、3つの HTML 4.0 DTD に対応して、Strict, Transitional, Frameset という3つの名前空間を規定する。この3つの名前空間はそれぞれが独自のURIによって識別される。
XHTML 1.0 は、HTMLの拡張やサブセット化をする将来的な文書型のファミリーのための基礎である。このアイデアは、将来的な方向性に関する節でさらに詳しく論じられる。
HTML 4.0 [HTML] は、国際規格 ISO 8879 に準拠したSGML(標準汎用マークアップ言語)アプリケーションであり、ワールド=ワイド=ウェブの標準的な出版言語として広く認められている。
SGMLは、マークアップ言語、とりわけ電子文書交換や文書管理、文書出版に使われるものを記述するための言語である。HTMLは、SGMLで定義された言語の一例である。
SGMLは、1980年代半ば以来出回っており、きわめて安定を保っている。この安定性の多くは、この言語が機能に富みつつ柔軟でもあるという事実に由るものである。もっともこの柔軟性は一定の対価によって生まれるもので、その対価とは、ワールド=ワイド=ウェブを含め多様な環境における採用の妨げとなる一定レベルの複雑さである。
HTMLは、元々の認識では、科学文書やその他の技術文書を交換するための、文書の専門家でない者による利用に適した言語であるべきものであった。HTMLは、SGMLの複雑さという問題を、比較的単純な文書を制作するのに適した構造タグや意味論タグの小セットを規定することにより処理したのである。文書構造の単純化に加えて、HTMLはハイパーテキストのサポートを追加した。後にマルチメディア能力が追加された。
目を見張るほど短い時間で、HTMLはえらく一般向けに普及し、その本来の目的を越えて急速に成長した。HTMLの始まり以来、(標準規格としての)HTMLで利用したり、高度に特化した垂直的な市場にHTMLを適合させたりするための新しいタグが急速に発明されている。この新しい要素の過剰が、異なるプラットフォームにわたる文書にとっては互換性問題の原因となっているのである。
ソフトウェアとプラットフォームとの両方で異種混交性が急速に増殖するにつれ、これらのプラットフォームで利用するには「クラシックな」HTML 4.0 の適性がいくらか限定されることは明らかである。
XMLとは、Extensible Markup Language™(拡張可能マークアップ言語)の短縮表記であり、eXtensible Markup Language の頭字語である [XML]。
XMLは、SGMLの複雑さの大半を抜きにしながらSGMLの能力と柔軟性とを回復する手段として考えられてきた。SGMLの制約形式であるけれども、にもかかわらずXMLは、SGMLの能力と豊かさのほとんどを保存し、なおSGMLの一般に使われる機能のすべてを維持する。
これらの役立つ特徴を維持しつつ、XMLは、適したソフトウェアの制作や設計を困難かつ高コストなものとするさらに複雑なSGML機能の多くを取り除くのである。
コンテンツ開発者がXHTMLを採用する主な理由は2つある。
第一に、XHTMLは拡張できるよう設計されている。この拡張性は、文書が整形式でなくてはならないというXMLの必須事項に依存する。SGMLの下では、新しい要素グループの追加がDTD全体の変更を意味することになろう。XMLベースのDTDでは、要求されるのは、新しい要素セットが既存のDTDに追加するについて内部的に矛盾がなく整形式であることだけである。これは新しい要素の集合体の開発や統合を著しく容易にする。
第二に、XHTMLは可搬的であるよう設計されている。インターネット文書にアクセスするために非デスクトップのユーザエージェントが利用されることが増えていくであろう。2002年までにインターネット文書閲覧の75%がこれらの代替プラットフォーム上でなされるだろうと示す試算もある。ほとんどの場合で、これらのプラットフォームは、デスクトップのプラットフォームの計算力を持たないであろうし、現在のユーザエージェントの傾向のように不整なHTMLを受け入れる能力を持つようには設計されないであろう。
以下の用語はこの仕様書で使われているものである。これらの用語は、[RFC2119] における定義を、ISO/IEC 9945-1:1990 [POSIX.1] における類似の定義に基づく方法で拡張するものである。
このバージョンのXHTMLは、厳格準拠XHTML文書(Strictly Conforming XHTML Document)に関する文書の準拠性を定義するのみである。厳格準拠XHTML文書とは、この仕様書において義務的なものとして記述されているファシリティのみを要求する文書である。そうした文書は、以下の判断基準のすべてに沿うものでなければならない。
付録Aに見られる3つのDTDのうちの一つに照らして妥当性を有しなければならない。
文書のルート要素は <html>
でなければならない。
文書のルート要素は、xmlns
属性を使うことにより [XMLNAMES]、定義済みの3つの名前空間のうちの一つを指し示さなければならない。指し示された名前空間は、その文書が妥当性を有するものと主張するDTDの名前空間に一致しなければならない。定義済みの名前空間は、つぎのものである。
http://www.w3.org/Profiles/xhtml1-strict
http://www.w3.org/Profiles/xhtml1-transitional
http://www.w3.org/Profiles/xhtml1-frameset
ルート要素に先立ってその文書の中には DOCTYPE 宣言がなければならない。DOCTYPE 宣言の中に組み込まれる公開識別子は、それぞれの公式公開識別子を使って付録Aに見られる3つのDTDのうちの一つを参照するものでなければならない。システム識別子は適切に修正されてもかまわない。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "xhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "xhtml1-frameset.dtd">
厳格準拠XHTML文書は、text/html
または text/xhtml
というインターネットメディア型でラベルされてもかまわない。text/html
としてラベルされたときは、文書は付録Cのうちの4つ目のガイドラインセットに従うべきである。このガイドラインに従い漏らすと、ほぼ確実に、古い実装の上で文書が処理され損なうことになる。
こちらは、最小限のXHTML文書の例である。
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/Profiles/xhtml1-strict.dtd"> <head> <title>バーチャル図書館</title> </head> <body> <p><a href="http://www.vlib.org/">www.vlib.org</a> へ移転しました。</p> </body> </html>
準拠ユーザエージェントは、以下の判断基準のすべてに沿うものでなければならない。
XHTMLがXMLアプリケーションであるという事実のせいで、SGMLベースの HTML 4.0 [HTML] では完全に合法であった一定の慣行が変更されなければならない。
整形式性は [XML] によって導入された新しい概念である。本質的に、これはすべての要素が終了タグを有するか、(下記の通りの)特殊な形式でかかれなければならず、またすべての要素がネストされなければならないことを意味する。
オーバーラッピングはSGMLでは違法であるにもかかわらず、SGMLベースのブラウザでは広く大目に見られている。
<p>こちらは強調を受けた<em>段落</em>です。</p>
<p>こちらは強調を受けた<em>段落</p>です。</em>
XHTML文書は、すべてのHTML要素名および属性名に小文字を使わなければならない。この違いは、XMLが大文字小文字を区別し、たとえば <li> と <LI> とが異なるタグとみなされることから不可避である。
SGMLベースの HTML 4.0 では、一定の要素は終了タグを省略することが許された。黙示的な結了が続いたエレメントを用いるのである。この省略はXMLベースのXHTMLでは許されない。DTDで EMPTY
として宣言されている要素以外のすべての要素は終了タグがなければならない。
<p>こちらに段落があります。</p><p>こちらにもう一つ段落があります。</p>
<p>こちらに段落があります。<p>こちらにもう一つ段落があります。
属性値はすべて、数値として現れるものであっても、引用符で括られなければならない。
<table rows="3">
<table rows=3>
XMLは属性最小化をサポートしない。属性-値の対は完全表記で書かれなければならない。compact
や checked
といったような属性名は、値が規定されなければ要素内に発生できない。
<dl compact="compact">
<dl compact>
空要素は />
で終わらなければならない。例. <br />
, <hr />
.
<br /><hr />
<br><hr>
XHTMLは、属性値の中にある空白の扱いについて、HTML 4.0 の規則を変更する。とりわけ、XHTMLは、先頭や末尾の空白を引き剥がし、1つ以上の空白キャラクタ(改行を含む)の連なりを単一の単語間空白(西洋文字についてはASCIIスペースキャラクタ)に割り付ける。[XML] の Section 3.3.3 を見ること。
XHTMLでは、script 要素や style 要素は #PCDATA
内容をもつものとして宣言される。結果として、<
や &
といった実体は、XMLプロセッサによってそれぞれ <
や &
に展開されることになる。script 要素や style 要素を CDATA
マークされた部分の中に包み込めば、これらの実体の展開が避けられる。
<script> <![CDATA[ ... エスケープされていないスクリプト内容 ... ]]> </script>
CDATA
部は、XMLプロセッサによって認識され、文書オブジェクトモデルにおけるノードとして現れる。DOM1勧告 [DOM] の Section 1.3 を見ること。
代替策は、外部スクリプト文書や外部スタイル文書を使うことである。
SGMLは、DTDの筆者に、ある要素内に特定の要素が組み込まれないよう排除する能力を与える。そうした禁止(「排除(exclusion)」と呼ばれる)はXMLでは不可能である。
たとえば、HTML 4.0 Strict DTD は、どのネスト深度でも 'a
' 要素を他の 'a
' 要素の中にネストすることを禁止する。XMLではそうした禁止をはっきりと綴ることが不可能である。これらの禁止がDTDでは定義できないとしても、一定の要素はネストされるべきではない。そうした要素と、その要素の中にネストするべきではない要素とをまとめたものが、規範的な付録B の中にある。
現行の HTML 4.0 DTD は、HTML 4.0 勧告 [HTML] になされたエラッタ変更を反映していない。XHTML DTD はこれらのエラッタを組み込み、そのため HTML 4.0 DTD のエラーは XHTML DTD では訂正される。エラッタは [ERRATA] で見ることができる。
HTML Tidy は、既存のウェブコンテンツをXHTMLに自動変換するW3Cサンプルコードである。これは、広範なマークアップエラーを処理することができるものであり、既存のHTML文書からXHTMLへとスムーズに移行するための手段を提供する。さらなる情報については [TIDY] を見ること。
XHTML 1.0 文書には既存のユーザエージェントと互換的でなければならないという要求はないが、実際上、これは実現が簡単である。互換的な文書を作成するためのガイドラインは付録C で見ることができる。
XHTML文書を転送するのに使ってよいのは、以下のインターネットメディア型のうちの一つである。これらの型を使って、文書制作者は、汎用的なXMLアプリケーションに対して(text/xml
)や、従来のHTMLユーザエージェント(text/html
)、新しいXHTMLアプリケーション(text/xhtml
)に対して配信できるXHTML文書を作成することにより、可搬的なインターネットコンテンツを作成することができる。
text/xml
どのXHTML文書も整形式で妥当なXML文書でもあるから、text/xml
というインターネットメディア型 [RFC2376] を使って転送してもかまわない。もっとも、XHTML文書を text/xml
として転送すると、2つの点で情報の損失が生じる。
第一に、この仕様書のテキストで与えられているが、文書に結びつけられた XHTML DTD によって捉えられない制約事項は、妥当性を検証する汎用的なXMLパーサによって強制することができない。
第二に、HTML 4.0 仕様書に記述されているが、文書に結びつけられたスタイルシートによって捉えられないレンダリング意味論は、汎用的なXMLパーサによってレンダリングすることかできない。
要するに、受信側が text/xml
しか知らない場合には、XHTML特有の解析制約事項をチェックすることを知ることができず、XHTML特有の意味論をレンダリングすることを知ることができないのである。
それでもなおサーバは、文書に関して汎用的なXML処理だけしか要求されない環境では、XHTML文書を text/xml
として転送することを選ぶかもしれない。
将来的なバージョンのXHTMLの究極の目標の一つは、XHTML文書を text/xml
として転送することにより失われるような情報がないということにある。もっとも、この仕様書はその目標をまだ実現していない。
text/html
XHTML文書が付録C にあるガイドラインに準拠している場合には、text/html
というインターネットメディア型を使って転送してもかまわない。もっとも、XHTML文書を text/html
として転送すると、2つの点で情報の損失が生じる。
第一に、受信側は、インターネットメディア型からその文書が妥当なXML文書であると主張していることがわからず、そのため、汎用的なXMLツールを使って文書の文法をチェックしたり文書をレンダリングしたりすることができない。ゆえに受信側は、アドホックな様式で HTML 4.0 文法のチェックおよび/または HTML 4.0 意味論のレンダリングをするよう心構えをしておかなければならない。
第二に、受信側は、インターネットメディア型だけからでは、その文書が妥当な XHTML 1.0 文書であると主張していることがわからず、そのため XHTML 文書については要求されるが HTML 4.0 文書に要求されない制約事項を強制することができない。
それでもなおサーバは、受信側にXHTMLサポートがない環境では、XHTML文書を text/html
として転送することを選ぶかもしれない。
XHTML文書を text/html
というインターネットメディア型を使って転送することは、HTMLからXHTMLへのスムーズな移行をサポートする助けとなり、またその早期の採用を促進するであろう。この方を使って転送されるXHTML文書は、既存のユーザエージェントによって通常の方法で処理される可能性が高い。
text/xhtml
text/xml
や text/html
といった上記のインターネットメディア型はそれぞれXHTML文書についての情報を切り捨てるので、text/xhtml
というインターネットメディア型を登録するというのがW3Cの腹づもりである。
text/xhtml
型の文書に遭遇した準拠的なユーザエージェントは、その文書がこの仕様書に準拠していると主張しているものと前提してもかまわない。この前提は、text/html
型の文書の受信側が文書の整形式性をチェックしなければならず、またその文書に結びつけられた XHTML DTD に照らして文書の妥当性をチェックしてもかまわないことを意味する。
このメディア型の役割や代替的な機構に関する議論を強く歓迎する。
XHTML 1.0 は、広い範囲の新しいデバイスやアプリケーションをサポートするため、モジュールを定義し、これらのモジュールを組み合わせる機構を用意することにより、XHTMLを拡張またはサブセット化する文書型のファミリーの基礎を提供する。この機構は、新しいモジュールの定義を通じて、統一的な方法で XHTML 1.0 の拡張やサブセット化を可能にすることになる。
XHTMLの利用が伝統的なデスクトップのユーザエージェントからその他のプラットフォームへと移行するにつれ、すべてのプラットフォームでXHTML要素のすべてが要求されるとは限らないであろうことが明確である。たとえば、ハンドヘルドのデバイスや携帯電話はXHTML要素のサブセットだけしかサポートしないかもしれない。
モジュラ化の過程とは、XHTMLをさらに小さい一連の要素セットに分割するものである。これらの要素はその後、異なるコミュニティの要望に添うように再度組み合わせることが可能である。
このモジュールは、今後のW3C文書で定義されることになる。
モジュラ化は、いくつかの利点をもたらす。
XHTMLをサブセット化するための形式面の機構を提供する。
XHTMLを拡張するための形式面の機構を提供する。
文書型間の変形を単純化する。
新しい文書型におけるモジュールの再利用を推進する。
文書プロファイルとは、あるセットの文書の文法や意味論を規定するものである。文書プロファイルに準拠することは、相互運用性を保証するため基礎を提供する。文書プロファイルは、その型の文書を処理するために要求されるファシリティ、たとえば使うことができる画像フォーマットや、スクリプトのレベル、スタイルシートのサポートなどを規定する。
プロダクトの設計者にとっては、これは多様なグループが独自の標準プロファイルを定義することを可能にする。
制作者にとっては、これは、異なるクライアントのために異なるバージョンの文書をいくつも書く必要性を消滅させることになる。
科学者や医者、数学者といったような特殊なグループにとっては、これは、その専門家の需要とかみ合った要素のグループを標準的なHTML要素に加えたものを使って特別なプロファイルを組み立てることを可能にする。
この付録は規範的である。
3つのDTDとエンティティセットとは、この仕様書の規範的部分を形成する。XML宣言やSGMLオープンカタログのついたDTDファイルの完全なセットは、この仕様書[原文]のzipファイルに組み込まれている。
3つのDTDは HTML 4.0 DTD に近似する。DTDがモジュラ化されるときには、もっと HTML 4.0 に密接に対応したDTD構築の手段が採用される可能性が高いであろう。
XHTML実体セットは HTML 4.0 のものと同じであるが、妥当な XML 1.0 実体宣言となるように修正されている。ユーロ通貨記号(€
または €
または €
)は特殊キャラクタの部分に定義されているので注意されたい。
この付録は規範的である。
以下の要素は、包含できる要素について禁止事項がある(Section 4.1.9 を見ること)。この禁止事項は、すべてのネスト深度に適用される。すなわち、すべての子孫要素を包含するのである。
a
|
他の a 要素を含むことができない。
|
---|---|
pre
|
img , object , big , small , sub , sup 要素を含むことができない。
|
button
|
input , select , textarea , label , button , form , fieldset , iframe 要素を含むことができない。
|
label
|
他の label 要素を含むことができない。
|
form
|
他の form 要素を含むことができない。
|
この付録は参考である。
この付録は、XHTML文書を既存のHTMLユーザエージェント上でレンダリングしたいと思う制作者のための設計ガイドラインをまとめたものである。
ユーザエージェントによっては処理命令(PI)がレンダリングされることに注意する。
空要素の末尾の /
と >
の前に空白を組み込む。例. <br />
, <hr />
<img src="karen.jpg" alt="Karen" />
. また、空要素には、たとえば <br />
といった最小化タグ文法を使う。XMLによって認められている <br></br>
という代替文法は、多数の既存のユーザエージェントでは結果が一定しないからである。
内容モデルが EMPTY
ではない要素の空インスタンス(たとえば、空タイトルや空パラグラフ)が与えられる場合には、最小化形式を使わない(たとえば、<p />
ではなく <p> </p>
を使う)。
スタイルシートが <
や &
や ]]>
を使っている場合には、外部スタイルシートを使う。スクリプトが <
や &
や ]]>
を使っている場合には、外部スクリプトを使う。
属性値の内部では改行や複数の空白キャラクタを避ける。これらはユーザエージェントによる扱いが一貫していない。
要素に言語を規定するときには lang
と xml:lang
属性との両方を使う。
XMLでは、"#foo"
という形式のフラグメント識別子で終了するURIは、name="foo"
という属性をもつ要素を参照しない。というよりも、たとえば HTML 4.0 の id
属性といったように、ID
という型のものとして定義された属性を持つ要素を参照するのである。多数の既存のHTMLクライアントは、このような方法での ID
型属性の利用をサポートしないから、文書をHTMLクライアント上で処理できるようにしたい場合には、ターゲット要素に id
と name
値との両方を補いたいと思ってもかまわない。例. <a id="foo" name="foo">...</a>
文書内でキャラクタエンコーディングを規定するには、xml宣言上のエンコード属性規定(例. <?xml version="1.0" encoding="EUC-JP"?>
)と meta http-equiv ステートメント(例. <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />
)との両方を使う。
この付録は参考である。