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

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

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

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

こちらにもう一つ段落があります。
4.4 属性値はつねに引用符で括られなければならない
属性値はすべて、たとえ数値のように見えるときであっても、引用符で括られなければならない。
正: 属性値が引用符で括られている。

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

4.6 空要素
空要素は、たとえば、

---

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

---

誤: 空タグが終結していない。

---

4.7 属性値内での空白の処理
属性値の中では、ユーザエージェントは、属性値から先頭及び末尾の空白を剥ぎ取り、1個以上の空白キャラクタ(改行を含む)が連なったものは単一の単語間スペース(西洋文字ではASCIIスペースキャラクタ)に割り付けることになる。
[XML]
第3節第3項3
を見よ。
4.8 スクリプト要素及びスタイル要素
XHTMLでは、スクリプト要素やスタイル要素は、
#PCDATA
を持つものとして宣言される。結果として、
は、マークアップの始まりとして扱われ、
<
&
といったような実体は、実体参照としてXMLプロセッサがそれぞれ
に認識することになる。スクリプト要素やスタイル要素の内容を
CDATA
マークされた部分の中に包み込むことにより、これらの実体の展開が避けられる。

CDATA
部は、XMLプロセッサにより認識され、文書オブジェクトモデルの中ではノードとして出現する。DOM1勧告
[DOM]
第1節第3項
を見よ。
代替策は、外部スクリプトやスタイル文書を使うことである。
4.9 SGMLの排除機能
SGMLは、DTDの筆者に、特定の要素がある要素の中に包含されないよう排除する能力を与えている。そうした禁止(「排除」と呼ばれる)は、XMLでは不可能である。
たとえば、HTML 4 Strict DTD は、'
' 要素の中に他の '
' 要素をネストすることを、子孫の深さを問わず禁止している。そうした禁止をXMLで綴ることは不可能である。これらの禁止をDTDの中で定義することはできないが、一定の要素はネストされるべきではない。そうした要素や、そうした要素の中にネストされるべきではない要素をまとめたものは、規範的である
付録B
で見られる。
4.10 'id' 及び 'name' 属性つきの要素
HTML4は、
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構築の方法が採用されることになる可能性が強い。
XHTML-1.0-Strict
XHTML-1.0-Transitional
XHTML-1.0-Frameset
A.2 実体セット
XHTML実体セットはHTML4用と同じものであるが、妥当な XML 1.0 実体宣言であるよう修正されている。ユーロ通貨記号を表す実体 (
€
あるいは
€
€
) は特殊キャラクタの一部として定義されているので注意してほしい。
Latin-1 キャラクタ
特殊キャラクタ
記号
付録B. 要素の禁止事項
この付録は規範的である。
以下の要素には、包含できる要素についての禁止事項がある(
第4節第9項
を見よ)。この禁止事項は、すべてのネスト深度に適用される。すなわち、すべての子孫要素を含んでいるのである。
他の
要素を包含してはいけない。
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 空要素
たとえば



といったように、空要素の末尾の
との前にスペースを1個組み込むこと。また、たとえば


といったように、空要素には最小化タグ文法を使うこと。これは、XMLで許容されている代わりの文法



は、多くの既存のユーザエージェントでは与えられる結果が一定しないからである。
C.3 要素最小化と空要素内容
内容モデルが
EMPTY
ではない要素に空インスタンスが与えられる場合(たとえば空のタイトルや段落)には、最小化形式は使わないこと(たとえば

は使わず

を使う)。
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
型属性の使用法をサポートしていないので、最大の前方互換性と後方互換性とを保証するために、これらの属性の両方について同一の値を補ってもかまわない。(例.
...
さらに、
ID
型の属性の合法的な値のセットは、
CDATA
型のものよりも遙かに小さいから、
name
属性の型は
NMTOKEN
に変更されている。この属性は、
ID
型か、XML 1.0 第2節第5項の生成規則5にある
Name
生成規則かと同じ値しかとれないよう制約されている。残念ながら、この制約は XHTML 1.0 DTD の中に表記することができない。この変更のせいで、既存のHTML文書を変換するときには注意を払わなければならない。これらの属性の値は、文書内部で一意的であり、妥当でなければならず、もしも変換の間に値が変更される場合には、これらのフラグメント識別子(内部てきなものも外部的なものも)への参照はどれも更新されなければならない。
最後に、XHTML 1.0 は
applet
form
frame
iframe
img
map
要素の
name
属性を廃止予定としており、後続バージョンのXHTMLからは除去されるであろうから注意すること。
C.9 キャラクタエンコーディング
文書の中でキャラクタエンコーディングを指定するためには、xml 宣言でのエンコーディング属性の指定 (例.

) と meta http-equive ステートメント (例.

) とを両方とも使うこと。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つの方法で処理することができる。
インターネットメディア型
text/html
として
DOM
経由で配布されるXHTML文書にアクセスするアプリケーションは HTML-DOMを使うことができ、そのインターフェイスからは要素名や属性名が大文字で返されることを当てにすることができる。
インターネットメディア型
text/xml
または
application/xml
として配布されるXHTML文書にアクセスするアプリケーションは、XML-DOMを使うこともできる。要素や属性は、小文字で返されることになる。また、XHTML要素によっては、内容モデルにおいて任意的であるため、オブジェクト樹に出現したりしなかったりするものもある(例.
table
要素内の
tbody
要素)。このことは、HTML4では、いくつかの要素で、開始タグと終了タグとを両方とも省略されるよう最小化することが許されていた(SGMLの特徴)ために発生する。これはXMLでは起こりえない。無関係な要素を挿入するよう文書制作者に要求する代わりに、XHTMLは要素を任意的なものとしている。アプリケーションは、きちんとこれに対応する必要がある。
C.12 属性値の中でアンパサンドを使う
属性値にアンパサンドが含まれているとき、アンパサンドはキャラクタ実体参照(例. "
&
")として表記しなければならない。たとえば、
要素の
href
属性が、パラメータをとるCGIスクリプトを参照しているときには、
ではなく
と表記しなければならない。
C.13 カスケーディングスタイルシート(CSS)とXHTML
カスケーディングスタイルシート第二水準勧告 [
CSS2
] は、HTML文書やXML文書の解析樹に適用されるスタイルプロパティを定義している。解析の際の相違点は、使われているセレクタ次第で視覚的または聴覚的に、異なる結果を生み出すことになる。以下のヒントは、両方のメディア型としての修正がないまま配布される文書について、この効果を小さくすることであろう。
XHTML用のCSSスタイルシートは、小文字の要素名や属性名を使うべきである。
テーブルの中では、tbody 要素は、HTMLユーザエージェントのパーサには推断されるが、XMLユーザエージェントのパーサには推断されないことになる。したがって、それがCSSセレクタの中で参照されている場合には、つねに明示的に tbody 要素を追加するべきである。
XHTML名前空間の中では、ユーザエージェントは "id" 属性をID型の属性として認識することが予定されている。したがって、ユーザエージェントがDTDを読まない場合であっても、スタイルシートが短縮 "#" セレクタ文法を使い続けられるべきである。
XHTML名前空間の中では、ユーザエージェントは "class" 属性を認識できることが予定されている。したがって、スタイルシートが短縮 "." セレクタ文法を使い続けられるべきである。
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日.
最新バージョンは
で入手可能。
[DOM]
"Document Object Model (DOM) Level 1 Specification"
, Lauren Wood
, 1998年10月1日.
最新バージョンは
で入手可能。
[HTML]
"HTML 4.01 Specification"
, D. Raggett, A. Le Hors, I. Jacobs, 1999年12月24日.
最新バージョンは
で入手可能。
[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月.
で入手可能。このRFCは RFC1521, RFC1522, RFC1590 を破棄するものであるので注意すること。
[RFC2119]
"RFC2119: Key words for use in RFCs to Indicate Requirement Levels"
, S. Bradner, 1997年3月.
で入手可能。
[RFC2376]
"RFC2376: XML Media Types"
, E. Whitehead, M. Murata, 1998年7月.
で入手可能。
[RFC2396]
"RFC2396: Uniform Resource Identifiers (URI): Generic Syntax"
, T. Berners-Lee, R. Fielding, L. Masinter, 1998年8月.
この文書は RFC1738 と RFC1808 とを更新するものである。
で入手可能。
[XML]
"Extensible Markup Language (XML) 1.0 Specification"
, T. Bray, J. Paoli, C. M. Sperberg-McQueen, 1998年2月10日.
最新バージョンは
で入手可能。
[XMLNAMES]
"Namespaces in XML"
, T. Bray, D. Hollander, A. Layman, 1999年1月14日.
XML名前空間は、XML文書の中で使われている名前を、URIによって識別される名前空間に結びつけることにより修飾するための単純な手段を提供するものである。
最新バージョンは
で入手可能。
目次
どら猫本舗 (
webmaster@doraneko.org

Same domain → Similar titles →