以下の諸注意は参考情報であり、規範ではない。本仕様の他の部分同様に、「must」「should」など、遵守要求の語が使用される。エラー状態をどのように扱うべきかについて、本仕様が定義していない要素・属性・実体などに遭遇したケースの処理も含め、何らの規定も行わない。様々なHTMLバージョンの実装間での実験及び相互運用性を促進するため、次の動作を推奨する。認識できない要素があった場合、ユーザエージェントは、内容のレンダリングを試みねばならない。(すなわち、属性とその値)を無視しなければならない。認識できない属性値があった場合、ユーザエージェントは、デフォルトの属性値を用いねばならない。宣言されていない実体があった場合、この実体を文字データとして扱わねばならない。これに加えて、ユーザエージェントがユーザに対しエラーを知らせる機能を提供するよう推奨する。エラー条件をどのように処理するかはユーザエージェントにより様々なので、HTML文書の著者もユーザも、特定のエラー復元方法に依存してはいけない。2.0適合文書と仮定して処理していると述べている。経験的に明らかなように、そうした仮定による文書処理はうまく機能しない。4.0仕様では、このような処理方法は推奨しない。相互運用性を確保するため、HTML文書の著者は、利用可能なSGML機構を通じてDTDを拡張したり実体定義の追加セットを作るなどしてHTMLを「拡張」してはならない。(DTD中で%URI;と定義されている値)のつもりで非ASCIIの値を指定する場合があり得る。href属性値は不正である。href="http://foo.org/Håkon">...</A>こうした場合に非ASCII文字を扱うため、ユーザエージェントが次の規則に従うことを推奨する。([RFC2279]参照)の1バイトあるいは複数バイトで表現する。URIのエスケープ機構により、このバイトをエスケープする。各バイトをバイト値の十六進表現HHを用いて「%HH」で表す。[RFC1738]の2.2あるいは[RFC2141]の2が定めるシンタクス的に正当なURIが得られる。得られるURIは、HTML文書が符号変換され得る文字符号化方法に依存しない形式である。古いユーザエージェントの中には、HTMLのURIを、当該文書の文字符号化方法をそのまま適用して処理するものもある。古いHTML文書の中にはこうした処理方法に依存しているため、符号変換に際して破綻するようなものもある。した古い文書を処理するユーザエージェントは、正当な文字集合の範囲にない文字を含むURIを受け取った場合、まず初めにUTF-8に基づく変換を試みねばならない。変換結果が巧く扱えないものである場合のみ、当該文書の文字符号化方法のバイトに基づくURIの変換を試みるようにしなければならない。name属性についても必要である。href属性など、アンカー形式のリンクとして利用され得る。ここで困ったことに、フォームの項目区切りに「&」記号を使おうとすると、SGMLの文字実体参照区切り子としての役割と衝突してしまう。href="http://host/?x=1&amp;y=2">」と記述する必要がある。本仕様では、HTTPサーバの実装者、特にCGI実装者が、「&」の代用としての「;」をサポートするよう推奨し、「&」記号のエスケープに関するトラブルを著者が避けられるよう求める。([ISO8879]の7.6.1参照)は、開始タグ直後の行区切り及び終了タグ直前の行区切りは共に無視すべきであると定めている。これは全HTML要素に対しても例外なく適用される。そこで次の2つのHTMLの例は、まったく同じようにレンダリングされる必要がある。<P>トーマスはテレビを観ている。</P><P>トーマスはテレビを観ている。</P>次の2例も同様である。非HTMLデータの指定スクリプトデータやスタイルデータは、要素の内容にも属性値にも出現し得る。この節では、HTMLのマーク付けとHTMLでないデータとの境界部分について記述する。DTDは、スクリプトデータとスタイルデータを、要素の内容としても属性値としても共にCDATAとして定義している。SGMLの規定では、CDATA形式の要素内容には文字参照が許容されないが、CDATA形式の属性値では許容されるので注意されたい。要素内容と属性値のスクリプトデータやスタイルデータをカット&ペーストする場合、著者には細心の注意が必要となる。要素内容と属性値におけるこの非対称性については、能力の大きな文字符号化方法から小さい文字符号化方法へと符号変換する際にも注意が必要となる。符号変換を行う場合、スタイルデータやスクリプトデータの中の変換不能な文字を数値文字参照に置換えればいいとは限らない。データを正しく処理するためには、符号変換に際してHTML文書をパースし、スクリプト言語及びスタイル言語のシンタクスをも理解する必要がある。データは当該要素の開始タグの直後から始まり、最初のETAGO【終了タグ開始区切り子】「</」に続けて名前開始文字([a-zA-Z])があるところで終わる。末尾と判断される組み合わせ【ETAGOと名前開始文字】が当該要素の終了タグではない場合があり得ることに注意されたい。従って著者は、「</」を各スクリプト言語あるいはスタイルシート言語固有のエスケープ機構によってエスケープすべきである。不正な例:次のスクリプトデータは、「</EM>」の一部として、当該SCRIPT要素の終了タグより前に文字列「</」を用いた不正な例である。</SCRIPT>JavaScriptでは、SGML名前開始文字の直前のETAGOを隠すことによって、正当に表現できる。</SCRIPT>Tclでは、次のように表記できる。</SCRIPT>VBScriptでは、文字参照関数Chr()を用いてこの問題を回避できる。著者は、当該スクリプト言語あるいはスタイル言語の規定に沿って単引用符や二重引用符がデータ内容とならないようエスケープすべきである。同様に、文字参照の開始以外の「&」もエスケープしなければならない。「"」は「&quot;」または&#34;」と記す必要がある。「&」は「&amp;」または「&#38;」と記す必要がある。従って、次のように記すこととなる。適合するSGML処理系は、HTMLユーザエージェントが広くサポートしていないような多くの機能を利用できると考えられる。本仕様は、HTML文書の著者がそうした機能の全てについて利用を避けるよう勧告する。論理型属性HTML文書の著者は、多くのユーザエージェントが論理型属性の最小書式しか認識せず完全書式を理解しないという点を知っておくべきである。selected>上の代わりに下のようには記さない方がよい。マーク区間マーク区間は、C言語のプリプロセッサにおける「#ifdef」構造と同様の役割を果たす。-->]]>SGMLでは、内容をCDATAとするマーク区間の用法も定められており、そこでは「<」はタグの開始記号としての扱いを受けない。]]>あるユーザエージェントがマーク区間を認識していないという証拠は、「]]>」が出現することによって示される。最初の「>」記号は「<![」で始まるタグの末尾だとユーザエージェントが誤認した場合に、「]]>」が見えてしまうわけである。処理命令は、プラットフォーム依存の文書処理を示す機能である。処理命令は「<?」で始まり、「>」で終わる。>処理命令の例を示す。<?/experiment>HTML文書の著者は、多くのユーザエージェントが処理命令を文書中のテキストの一部としてレンダリングすることを知っておくべきである。省略化マーク付けSGMLのSHORTTAG(短縮タグ)機構は、タイピングの繁雑さを軽減するかもしれないが、SGMLアプリケーションに対して大きな能力を加えるものではない。技術的には何の両義性も伴わないが、新しい要素を含むよう言語の拡張を行う場合等には特に文書の堅固性を減少させる。そこで、属性に関するSGMLの短縮タグ機構は広く利用されまた実装されているが、要素についてはそうではない。この機構を利用する文書は適合SGML文書ではあるが、現存する多くのHTMLツールで作動するとは考えにくい。問題となる【要素の】短縮タグ機構を例示する。検索エンジンによるサイト索引づけを支援する場合の注意この節では、HTML文書を検索エンジンにとってアクセスしやすいものとするための、簡単な提案を行う。何語で書いたかを指定する地球規模のWebという観点から、当該ページが何語で書かれているかを知ることは重要である。この点については言語情報の項で記す。LINK要素によって参照情報を記すべきである。することで、検索エンジンは、問い合わせがどのように書かれていようとも、ユーザが希望する言語における検索結果を返すことができる。次のリンクは検索エンジンに対し、当該文書の代替版であるフランス語版とドイツ語版の所在を示す。Untergrund">キーワードや要約を提供するコンマ区切り形式で列挙されたキーワードや、要約が書かれたMETA要素を探すような検索エンジンもある。この検索エンジンは、検索結果としてこれらのキーワードを示し得る。name属性の値が何であるかは本仕様書の定義の範囲外である。次の事例を考慮されたい。vacations">文書群中の開始ページを示すワープロ文書やプレゼン資料を集めて複数のHTML文書にするということは、よくあることである。検索の結果ヒットしたページに、当該文書群の開始ページへの参照が示されると便利である。title属性を併用し、次のように記す。title="一般相対性理論">ロボットに対して索引づけの指示を行う検索エンジンによって自分のサイトが索引づけられていることを知って驚く場合や、公開したくない部分については巡回対象としていないことを知って驚く場合もあるだろう。多くの検索ロボットは、Webサイトの管理者やコンテンツの提供者に対し、ロボットの作業を制限する機構を用意している。META要素という2つの機構によって可能となる。検索ロボットrobots.txtファイル検索ロボットは、「http://www.foobar.com/」といったWebサイトを巡回する際、まず初めに「http://www.foobar.com/robots.txt」の有無を確認する。このrobots.txt文書があった場合、この内容を解析し、【当該サイトの】文書が検索可能かどうかを調べる。robots.txtの内容をカスタム化し、特定ロボットのみに適用させたり、特定ディレクトリや特定ファイルへのアクセスを不許可にしたりすることもできる。当該サイト全体からすべてのロボットを排除するrobots.txtファイルの例を掲げる。pagesロボットは単純に、サイトにある「/robots.txt」を探す。ここで言うサイトとは、あるホスト及びポート番号で稼動しているHTTPサーバを意味する。次に、robots.txtの置き方を示す。http://w3.org/robots.txt1つのサイトには1つの「/robots.txt」しか存在できない。ユーザディレクトリに「robots.txt」ファイルを置いてはならない。ロボットはそのファイルを探し出せないからである。【サイト管理者が】各ユーザに対して「robots.txt」を利用可能にさせようとする場合、サイト全体で1つの「robots.txt」となるようすべて結合する必要がある。これが面倒なら、代わりに各ユーザがロボット用のMETA宣言を行うようにしむける手もある。URIは大文字小文字を区別し、「/robots.txt」ファイル名は全て小文字の必要がある。「robots.txt」ファイル中の1条件レコードの範囲においては、空行は許されない。1条件レコードにつき、1つだけ「User-agent」フィールドが存在するようにすること。ロボットは、このフィールドを自由に解釈する。本仕様は、名称からバージョン情報を除いた部分文字列の、大文字小文字を区別しない合致によってロボット名称を判断するよう推奨する。「User-agent」の値が「*」だった場合、当該レコードは、他のどのレコードにも合致しないロボットに対するデフォルトのアクセス方針を示す。したレコードが「/robots.txt」の中に複数存在してはならない。「Disallow」フィールドは、巡回を拒否する箇所の部分URIを指定する。指定は、フルパスであっても、部分パスであってもよい。このパス値で始まるURIは、すべて巡回されない。「/help.html」と「/help/index.html」の双方が巡回されない。「/help/index.html」は不許可だが「/help.html」は許可される。値が空の「Disallow」は、全てのURIが巡回可能であることを示す。robots.txtファイルには、最低1つの「Disallow」フィールドが存在しなければならない。ロボットとMETA要素META要素によってHTML著者は、ロボットに対し、当該文書を索引づけてよいかどうかや、リンク部分を更に辿っていっていいかどうか等を知らせることができる。サーバ管理者の作業は不要である。次の例では、ロボットは当該文書の索引づけも、リンク内容の解析も許されていない。NOFOLLOW、NOINDEXである。1997年初頭の段階では、META要素による制限を実装しているロボットはわずかであった。検索ロボットの制御に関するより公然たる注意が払われるようになれば、この状況は変わっていくと期待できる。設計原理HTMLの表モデルは、既存のSGML表モデルや、一般的ワープロソフトによる表の扱い、雑誌・書籍その他の印刷物で見られる多様なテーブル的レイアウト技術、等の研究を元に開発された。単純な表を簡単に表現できてかつ必要に応じて複雑な表現が可能なモデルを選択した。これにより、日常用のテキストエディタでHTMLの表をマーク付けすることが実際的に可能となり、また初学者にとっての学習曲線を下げることもできた。この点は今日のHTMLの成功にとって非常に重要な点である。他の文書フォーマットからの変換によって表を作成したり、WYSIWYGエディタを用いて直接表を生成するような人も増えている。したオーサリングツールにうまく適合することも、HTMLの表モデルにとっては重要である。この点は、複数の行や列をまたぐセルをどのように表現するかといったことや、配置を揃えること等のプレゼンテーション特性をセルのグループとどのように関連づけるかといったことに関連する。動的再フォーマットHTMLの表モデルにとって重要な問題は、ユーザ側がこの表をどのような大きさで表示するか、どのフォントを用いるかといったことを制御しない点である。そこで、絶対ピクセル単位による列幅指定にはリスクが伴うこととなる。表は、固定サイズではなく、現在のウインドウサイズやフォントに合致するよう動的に大きさが変更できるようでなければならない。HTML著者は列幅の相対的な大きさの指針を指定できるが、ユーザエージェントはセル内容のうち最も大きい要素をレンダリングするのに十分な列幅を確保するべきである。著者の指定を上書きする必要が生じた場合、個々の列幅の相対的な関係は、大幅には変えないようにすべきである。巨大な表や、低速回線で接続している場合、逐次的に表を表示することによってユーザを満足させられる。ユーザエージェントは、表データの全体が届くより先に表示を開始できるようにすべきである。ほとんどのユーザエージェントのデフォルトのウインドウ幅は【半角】80文字であり、また多くのHTMLページの画像はこのデフォルト幅を念頭において描かれている。HTML著者は、列数を指定し、表全体の幅及び他と異なる列の幅を指定することで、ユーザエージェントが逐次表示を行なう際のヒントを提供することができる。逐次表示を行なうために、「ブラウザ」は列の数と幅とを知る必要がある。(width="100%")。width属性の指定で変更できる。COL要素によって、列幅の指定を行なうこともできる。第一行のデータを受け取ってから数えればいいという意見もあるが、セルが多くの内容を含んでいる場合は長い時間がかかる。大局的に見て、逐次表示が望ましい場合、HTML著者がTABLE要素で列数を明示しておく方が合理的である。HTML著者は更にまた、ユーザエージェントに対して逐次表示を用いるかセル内容に応じた自動的サイズ調整を行なうべきかを知らせる手段を必要とする。二段構えで表示することとなる自動サイズ調整モードの場合、列数は第一段階で確認される。COLGROUP要素で提示される必要がある。構造とプレゼンテーションHTMLでは、段落分けや引用など構造に関するマーク付けと、マージン、フォント、色指定などレンダリングに関するマーク付けが、明解に区別される。この区別は表に対してどんな影響を及ぼすだろうか。非常に厳密に言うと、セル内のテキスト配置やセル間の枠線等はレンダリングに関する問題であって、構造の問題ではない。実際的には、こうした機構はあるアプリケーションから別のアプリケーションへの移植性が高いため、構造情報と一緒にグループ化してしまうと便利である。HTMLの表モデルは、レンダリング情報の大半を関連するスタイルシートへと委ねている。本仕様が提示するモデルは、スタイルシートの利点を活かしはするが、スタイルシートを必須とはしない。現在のDTPパッケージでは表のレンダリングについて非常に高度な制御を行えるが、それをHTMLで再現しようというのは実際的ではない。これを再現するには、HTML仕様をRTFやMIFのように巨大な仕様へと書き換える必要が生じてしまう。なく、本仕様は、枠線スタイルとして一般的に使用されるクラス集合から著者が選択できるようにした。rules属性は表内部の罫線として選んだものを指定する。細かい表現は、レンダリングの注釈によってサポートされる。STYLE要素あるいはリンクしたスタイルシートによって得ることができる。本仕様の開発に際して、表の枠・罫線出現パターンの様々な方法を検査した。1つの問題は、作られ得る記述方法の種類に関するものである。縁取りの削除や追加をサポートすると、そのアルゴリズムは相対的に複雑化する。表を構成する全要素にframe属性とrules属性が許容されるとすると、あるセルの一辺について罫線を引くか引かないかを決定するために、24段階の手順を踏むアルゴリズムが必要となる。これほどの複雑さをもってしても、表に対するあらゆるニーズを満たすのに十分なレンダリングの制御は行えない。そこで本仕様では敢えて、ほとんどの目的に十分であり、かつ単純で分かりやすいモデルを採用するに留めることとした。複雑なアプローチを標準化するまでには、さらに多くの実験的作業が必要である。行グループと列グループ本仕様は、HTML+に関する初期の作業で示された単純な表モデルの上位モデルを提供する。ここでは表を、任意選択のキャプションと、連続するセルが成す行の連なりとから構成されるものと考える。このモデルでは見出しセルとデータセルを区別し、またセルが他の行や列をまたぐことを許容する。CALSの表モデル([CALS]参照)に準じ、本仕様では、表の各行をヘッダ・本体・フッタにグループ化できるようにした。これによりレンダリング情報の表現は簡素化され、ページ境界をまたぐような表でヘッダとフッタの繰り返しが可能となり、また本体をスクロールする際にもヘッダを固定的に表示することもできる。マーク付けでは、フッタは本体の前に位置する。これはCALSと共通する、非常に巨大な表を扱う場合の最適化手法である。することで、表全体の処理を待たずにフッタをレンダリングできる。視覚障害者のために、HTMLは、ウインドウシステムに基づくグラフィカルなユーザインターフェイスのみに適合してしまうことから引き起こされるアクセス障壁をなくせるような仕組みを設けた。HTMLの表モデルは各セルをラベルづけするための属性を含み、音声出力に変換するための高品質なテキストをサポートしている。このラベルづけ属性は、表データをデータベースや表計算シートとの間で自動的にやりとりする際にも利用できる。推奨するレイアウトアルゴリズムもしCOL要素かCOLGROUP要素が存在するなら、列数が指定されていることになるので、表を固定レイアウトでレンダリングしてよい。両要素が存在しない場合は、下で述べる自動レイアウトアルゴリズムを用いねばならない。width属性が指定されていない場合、視覚系ユーザエージェントはデフォルト値の100%を仮定してフォーマットせよ。仮にwidth指定を超えて表の幅を増やさないとセル内容がはみだしてしまう場合、ユーザエージェントは表の幅を増やすよう勧められる。この状況でユーザエージェントが指定された幅を上書きするのは合理的である。ユーザエージェントは、過大な横スクロールを避ける必要があったり、過大な横スクロールが実用的でないか望ましくないような場合は、行をまたいで単語の分割を行なってよい。CAPTION要素が指定する表のキャプションを、1つのセルであると考える必要がある。表の上側または下側に位置するキャプションは列全体にまたがる1つのセルであり、表の左側または右側に位置するキャプションは行全体にまたがるセルである。固定レイアウトアルゴリズムこのアルゴリズムでは、列数が既知であると仮定される。デフォルトでは、各列の幅は均等である必要がある。COL要素で相対的あるいは絶対的な列幅を指定してデフォルト値を上書きできる。TABLE要素のwidth属性によって上書きされ得るし、絶対指定の列幅によって決定される場合もある。列幅の絶対指定と相対指定が組み合わされている場合は、まず表全体の幅から絶対指定による列幅を確保し、次に残りを相対指定の値によって割り振る。属性値の一貫性を保証するには、表のシンタクスだけでは不十分である。COL要素及びCOLGROUP要素の個数は、表のセル数が暗示する列数と一致しないことがあり得る。列幅が狭すぎてセル内容が収まり切らない場合、より大きな問題が起きる。COL要素の指定が、セル内容が溢れる原因となり得る。セル内容が溢れる場合、ユーザエージェントは、単語をハイフネーションするか、ハイフネーションの位置が不明なら適宜分割する等して、セル溢れを見苦しくないよう回避することが推奨される。分割不能な要素がセル溢れを引き起こした場合、ユーザエージェントは、列幅を調整して表の再レンダリングを行なうことを考慮してよい。列幅調整かつ/またはスクロール表示が不可能であるような最悪の場合には、セル内容の切り捨ても考えざるをえない。何にせよ、セル内容の分割や切り捨てを行なう場合は、その旨をユーザに適宜示す必要がある。COL要素でもCOLGROUP要素でも指定されていない場合、ユーザエージェントはここで述べる自動レイアウトアルゴリズムを用いる必要がある。このアルゴリズムでは表のデータを二段階に渡って処理し、段階的に表の大きさを計る。第一段階では、ユーザエージェントは、行の折り返しを行なわず各セルの最小幅と最大幅を検出する。最大幅は、最大行によって求める。行を折り返さないため、段落は、BRによる区切りがない限り1つの長い行として扱われる。最小幅は、冒頭のインデントやリスト項目印なども勘案した上で最大のテキスト要素(単語や画像など)によって求める。言い換えると、セル溢れが生じる直前のところで、当該ウインドウにおいてセルが要求する最小幅を決定する必要がある。ユーザエージェントによる単語の分割を許容することで、横スクロールの必要性を最小限にし、また最悪のケースにおけるセル内容の切り捨てをも最小限にできる。列幅決定アルゴリズムは、セル内容になっている入れ子の表にも適用される。子である表の最小・最大幅は、その表自身の幅に反映されると共に、親である表のセル幅にも影響する。このアルゴリズムはセル内容総体に対して一律に働き、また概して入れ子の深さには無関係である。セル内容の文字配置に対処するため、列幅決定アルゴリズムでは各列について次の3つの最大・最小値をも検出する必要がある。桁揃え文字の左側、次に桁揃え文字の右側、そして桁揃えしないもの——の最大・最小値である。min_non-aligned)【桁揃え左側最小値と桁揃え右側最小値の合計か、桁揃えに関係のない部分の最小値の、どちらか大きい方】である。して得られる最小・最大セル幅は、その含まれる列の最小・最大幅決定の根拠になる。決定された列幅は、表の最小・最大幅を求めるために用いる。セルは入れ子の表を含み得るがコードが大幅に複雑化するものではない点に注意されたい。【以上が第一段階で、】第二段階の手順は、利用可能な空間、すなわち現在の左マージンと右マージンの間の空間に、列幅を割り当てていくものである。複数列をまたぐセルの場合、単純な手法は、またぐセルの各々に対して最小・最大幅を均等に割り振ることである。多少複雑な手法は、またがないセルの最小・最大幅を用いて、またぐ幅をどの程度にすれば妥当かを重みづけする方法である。実験により、2つの手法を混合することによって、多様な表において良い結果が得られると判っている。表の枠線とセル間マージンについても、列幅決定に際して考慮に入れる必要がある。次の3パターンがあろう。表の最小幅が、利用可能空間より大きいかまたは等しい。この場合、最小幅を割り当て、ユーザの横スクロールを可能にする。点字出力への変換においては、セル内容を、当該セル内容全体を含む注記への参照に置き換える必要がある。慣習的に、注釈は表より前に出現する。表の最大幅が、利用可能空間に収まる。この場合、各列を最大幅に設定する。表の最大幅は利用可能空間より大きいが、最小幅は利用可能空間より小さい。表の最小幅との差を計算し、それをWとする。利用可能空間と最大幅との差をDとする。各列における最大幅と最小幅の差をdとする。値を加えて、求める列幅とする。この計算で広がる列幅は、最小・最大の差が大きい列ほど大きくなり、差が小さい列ほど小さくなる。この計算過程は、入れ子の表においても、親世代の計算で得られた子世代の表が占有可能な最小・最大幅に基づいて、繰り返される。この場合、親である表のセルが、上記の説明における現在のウインドウサイズに該当する役割を果たす。この過程は入れ子の全世代にわたって循環的に繰り返される。入れ子の表では、まず最上位の表が計算結果が示す幅を用いてレンダリングされる。続いて子世代の表が、親である表のセル内容の一部としてレンダリングされていく。表の幅がwidth属性によって指定されている場合、ユーザエージェントはこれに合致するよう列幅を調節しようと試みる。width属性の指定による拘束を受けない。COL要素で相対指定されていた場合のアルゴリズムは、最小の列幅から増やしていって指定の相対比率に近づけるというものになる。COL要素はヒントとしてのみ受け取るべきであり、列幅は最小幅より小さくなってはいけない。同様に、表がウインドウの範囲を超えてしまうほど列幅を拡げてもいけない。COL要素が相対サイズをゼロと指定している場合は、当該列は常に最小幅に設定されねばならない。charoff属性が存在しない場合のデフォルトの配置は、align="char"である列については、各行における桁揃え文字の左右各々の最大値が均等になる、中心線を基準に決定できる。逐次表示に関する暗示的デフォルトはcharoff="50%"である。同じ列で異なる行にある複数のセルが桁揃え文字を用いている場合、デフォルトにより、桁揃え文字が何であるかによらず当該セルを揃えてしまう必要がある。これら明示的暗示的配置の結果、列幅からの溢れ処理が必要となるような大きすぎるモノを扱う場合、溢れ処理ルールが適用される。frame属性の値を、rules属性の値と配置に用いる値とに一致するよう選択することが、望ましいと考えられるだろう。none、top、bottom、topbot、left、right、leftright、allである。ところが残念なことに、SGML規定は列挙する属性値について、属性名が何であっても各要素において一意であることを要求しているので、「none」「left」「right」「all」に関して即座に問題が生じる。valign属性との衝突を避ける形で選択した。rules属性が追加される場合に起き得る将来の衝突を避ける基準ともなっている。frame属性をCDATA形式の属性とすることであった。W3CのHTML作業グループが達した合意は、列挙された値に基づいてSGML検証ツールで検証できる利益が、名前の一致による利益に勝るというものである。逐次表示ネットワークから受信しつつある文書を逐次表示することで、フォームに関連する問題が発生する。ユーザエージェントは、当該フォームの要素がすべて受信されてしまうまでは、ユーザがフォームをサブミットできないようにする必要がある。文書の逐次表示は、タブナビゲーションについても少々問題を生み出す。tabindexにフォーカスを合わせるという帰納法は、一見すると十分理にかなっていると思える。tabindexが変わり得るため、文書のテキスト全体が届くまで待ち続けねばならないことを意味する。全文到着以前にユーザがタブキーを叩いた場合には、当該時点で最低位であるtabindexにユーザエージェントがフォーカスを移動するのは合理的である。クライアント側スクリプトと関連づけられているフォームでは、問題発生可能性は更に増大する。あるフィールドのスクリプトハンドラが、まだ届いていないフィールドを参照している状態などがあり得る。本仕様は、フォーム作成に関する一般的な要求を満たすのに十分な能力を持つだけの要素と属性の集合を定義する。いえまだ幾つも改善の余地がある。次の点が将来の改善点として示されよう。現代的ユーザインターフェイスと比べて、フォームのフィールド形式の範囲があまりに制限されている。表形式でのデータ入力や、スライダ、多重ページ配置などは用意されていない。サーバはサブミットされたフォームのフィールドだけを更新することができず、HTML文書全体を送り返すしかなく、画面全体を書き換えざるを得ない。同様の【全体書き換え】問題が音声ベースのブラウザでも発生し、視覚障害者がHTMLフォームを操作するのが困難になっている。usemap属性を追加することである。AREA要素が、値をサーバに渡す。AREAを拡張するのが適切であろう。将来的なスクリプトマクロのために予約されるシンタクス本仕様は、HTMLのCDATA属性のスクリプトマクロを将来的にサポートするためのシンタクスを予約する。これは、ページの初めの方に出現するオブジェクトのプロパティに依存する形で属性の設定を許すことを意図している。シンタクスは次の通り。"現在のスクリプトマクロの扱いマクロ本体は、組込みイベント属性毎に、デフォルトのスクリプト言語で記述した1つ以上の行から成る。閉じ中括弧(})に続くセミコロンは常に必要であり、セミコロンが付随しない閉じ中括弧はマクロ本体の一部として扱われる。スクリプトマクロを含む属性の値は常に引用符で囲う必要がある点にも注意されたい。CDATA属性の処理手順は次の通り。SGMLパーサが、「&gt;」等のあらゆるSGML実体を処理する。次にスクリプトエンジンがスクリプトマクロを評価する。この結果得られた文字列が、最後に、次の処理を行うアプリケーションに渡される。マクロ処理は、文書の読込み(あるいは再読込み)時点で行われるが、文書サイズの変更や再描画などの時点では行われない。推奨しない例:JavaScriptを用いた例を幾つか示す。最初の例は、文書の背景色をランダムに変更する。bgcolor='&{randomrgb};'>夜に読まれる場合に背景を暗くしたい場合もあろう。18)...};'>次の例ではJavaScriptをクライアント側イメージマップのcoords属性設定用に用いている。</MAP>今度の例では、documentプロパティに合わせて画像のサイズを設定している。alt="banner">リンクあるいは画像のURIを、スクリプトで設定することもできる。alt="logo">最後となる次の例は、SGMLのCDATA属性では単引用符または二重引用符でどのように値を囲えるかについて示す。属性文字列を単引用符で囲った場合は二重引用符を属性文字列に含めることができる。属性文字列に二重引用符を用いるもう1つの手法は、&quot;を二重引用符として使用することである。目標フレーム名が一意であるという保証がないため、与えられた目標名のフレームを探し出すために現在使われている手法を参考に記しておく。目標名が、規範文書が規定する予約語の場合、定義通りに適用する。予約名以外の場合、当該リンクを含むウインドウにおいてフレーム階層の深さを優先して検索する。名前が正確に合致する最初のフレームを用いる。前段階で合致するフレームが発見されなかった場合、各ウインドウの前面から背面に向けて名前合致検索を行う。完全一致する名前に遭遇した時点で、即座に検索を終了する。それでも該当するフレームが無かった場合、新しいウインドウを開いてこれに目標フレーム名を割り当てる。アクセス性に関する注意ここで述べる代替テキスト生成アルゴリズムは、W3CのWebアクセス性イニシアチブグループ[WAI])が制作している、障害者のWebアクセス性向上のためのガイドライン文書群に従う。現在3つのガイドライン群がある。([WCGL])は、HTML著者およびサイト管理者向けの物である。画像、アプレット、スクリプト等に対する代替テキストを提供する場合の情報は、このWebコンテンツのアクセス性指針を参照されたい。([UAGL])は、ブラウザ、マルチメディア再生装置、サポート技術等の、ユーザエージェント開発者向けである。代替テキストの処理に関する情報は、このガイドラインを参照されたい。([ATGL])は、オーサリングツール開発者向けである。セキュリティに関する注意アンカー、埋込み画像、その他パラメータURIsを含むすべての要素は、ユーザの入力によってURIの逆参照が為され得る。[RFC1738]の6にあるセキュリティ問題を考慮する必要がある。フォームをサブミットする要求に広く用いられる手法——HTTPとSMTP——は、機密保持に関してほとんど何の保証もしない。重要な情報を扱うフォーム、特にtype="password"のINPUT要素を扱う場合、コンテンツ提供者は、機密性が保たれないことと、利用者に向けて機密性の問題へ注意を喚起することとに留意する必要がある。フォームにおけるセキュリティ問題ユーザエージェントは、ユーザが明示的に送信を求めたファイル以外のものは送ってはいけない。INPUT要素のvalue属性が示すと考えられるすべてのデフォルトファイル名に適合することが求められる。隠しコントロールはファイルを指定してはならない。本仕様は、データの暗号化に関するメカニズムを含まない。安全なデータ伝送に用いる他のあらゆるメカニズムが存在する場合、これを処理する必要がある。アップロードされたファイルは、処理エージェントがこれを適切に処理・格納する必要がある。正規の規定は英語版です。この文書は参考に過ぎません。翻訳上の誤りがあり得ます。このファイルは2004年3月7日版です。uchida@happy.email.ne.jp。