以下は参考として記したもので、規範として定義づけた内容ではありません。けれども、「必ず must」「すべき should」などの、遵守すべきであることを示す語が表す制限事項については、本書の他の部分と同様、守るようにして下さい。
この仕様書では、本仕様に適合するユーザエージェントに対し、エラー文書の一般的な処理方法については定めません。ここで言うエラー文書には、仕様書にない要素、属性、属性値、実体を記した文書を含みます。
けれども、様々なバージョンのHTML仕様をうまく扱って共同利用できるようにするため、この仕様書では、次の枠組みによるエラー処理を推奨します。
エラー処理が発生した場合、ユーザエージェントは、読み手にその旨が判るようにしてください。
エラー文書は、各ユーザエージェントにより様々な異なる取り扱いがされますので、書き手も読み手も、ある特定のエラー復元方法にだけ依存してしまってはいけません。
HTML2.0の仕様書 ([RFC1866]) には、HTML 2.0対応のユーザエージェントの多くが文書型宣言が記されていないHTML文書をHTML 2.0準拠文書と仮定して処理していると述べています。けれども経験的に明らかなように、そうした仮定による文書処理はうまく機能しません。そこで、このHTML 4.0仕様では、このような処理方法は奨めません。
[ 訳注。原文の記述はこんな感じですが、RFC1866は実際には「文書型宣言が記されていない文書はHTML 2.0準拠のものとして扱え」と求めています。]
相互運用性を守るため、HTML文書を作る場合にSGMLの機構によって勝手にHTML仕様を拡張したりするのはやめて下さい。（例えばDTDを拡張するとか、実体セットを追加するとか。）
URI中には非ASCII文字を記せませんが ([URI] の section 2.1 を参照のこと) 、URI形式であるような属性値（DTD中で%URI;と定められているもの）において、非ASCII文字を使ってしまう場合があるでしょう。例えば次のように書いてしまったhref属性の値は文法違反です。
<A href="http://foo.org/Håkon">...</A>
[ 訳注。文字化けしている方もいらっしゃるでしょう。「å」という文字参照が使われています。]
本仕様は、ユーザエージェントに対し、URI形式属性値において非ASCII文字を扱う場合に次の規則に従うよう勧告します。
このような置き換えによって、HTML文書を伝送する際にどんな文字符号化方法を用いても安全な、正しい書式のURI値 ([RFC1738]のsection 2.2あるいは[RFC2141]のsection 2 の定めによる) として非ASCII文字を記せます。
注。 古いブラウザの中には、受け取ったHTML文書の文字符号化方法をそのまま適用してURIを処理するものがあります。またそのような処理方法に [無自覚に] 依存しており、符号変換<transcode>によって破綻を来すような古式のHTML文書もあります。そのような古式のHTML文書を扱う場合、ユーザエージェントは、正しくない書式のURI記述が現れた際には、UTF-8への変換を試みてください。そしてUTF-8への変換によっては巧く扱えないような場合にのみ、当該HTML文書の元々の文字符号化方法に従ってURI値を取り扱うようにしてください。
入力済みフォームの送信によって生成されるURI値は、アンカー形式のリンクとして働くこととなるでしょう。（例えばA要素のhref属性のように。） ここで困ったことに、フォームの項目区切りに「&」記号を使おうとすると、文字実体参照の開始記号としての「&」の役割と衝突してしまいます。例えば、リンク用URIとして「http://host/?x=1&y=2」を使いたい場合は、「<A href="http://host/?x=1&y=2">」あるいは「<A href="http://host/?x=1&y=2">」と書き直す必要があります。
本仕様書では、HTTPサーバの実装を行う場合、特にCGIを扱う方々に対して、「&」の代用としての「;」をサポートするよう推奨し、上記のように「&」記号を避けることが出来るよう求めます。
SGML ([ISO8879]の section 7.6.1を参照のこと) は、開始タグ直後の改行及び終了タグ直前の改行は共に無視すべきであると定めています。これは全HTML要素に対しても例外なく適用されます。
そこで、次の2例は全く同じように表示される必要があります。
<P>Thomas is watching TV.</P>
<P> Thomas is watching TV. </P>
また、次の2例も同じ表示結果になる必要があります。
<A>My favorite Website</A>
<A> My favorite Website </A>
スクリプトデータやスタイルデータは、要素の内容としても属性値としても記されます。以下ではHTMLのマークづけとHTML以外のデータとの境界部分について記します。
注。 HTML 4.0のDTDは、スクリプトデータについてもスタイルデータについても、要素の内容としても属性値としても「CDATA」型のデータとして定義しています。ここでの注意点は、SGMLの文法では、要素の内容としての「CDATA」型データには文字参照を使えないけれども「CDATA」型の属性値には文字参照が使える、という点です。そこで、スクリプト記述やスタイル記述を含むHTML文書をカット&ペーストで作る場合には、文字参照の可能不可能について細心の注意が必要です。
要素内容と属性値におけるこの非対称は、直接扱える文字数の多い符号系から少ない符号系へと符号変換を行う場合にも注意が必要となる点です。符号変換に際しては、文字として置き換えられないものを単純に数値文字参照によって表していいというものではなく、元のHTML文書を検定し、スクリプト言語やスタイルシート言語の文法を理解した上で、各々のルールに抵触しないよう正しく符号変換処理を行う必要があります。
スクリプトデータやスタイルデータが要素の内容として記されている場合（SCRIPT要素やSTYLE要素）、要素の開始タグの直後から記述内容が始まると判断され、終了タグ開始<ETAGO>（「</」）区切り子に続くアルファベット([a-zA-Z])があるところで終了すると判断されます。これは必ずしも当該要素の終了タグを意味しないということに注意して下さい。そこで、スクリプトデータやスタイルデータの内容として「</」が必要になる場合には、各言語で用意されている代替表記法によって書き換えるようにしてください。
間違った書き方（ILLEGAL EXAMPLE）:
次のスクリプトデータは、SCRIPT要素の終了タグの前に（「</EM>」として）「</」を記した、間違った文例です。
<SCRIPT type="text/javascript">
document.write ("<EM>This won't work</EM>")
</SCRIPT>
JavaScriptでは、SGMLのタグ記法との衝突を避けるために、次にようにして終了タグ開始区切り子を書き換える文法が用意されています。
<SCRIPT type="text/javascript">
document.write ("<EM>This will work<\/EM>")
</SCRIPT>
Tclでは次のように書けます。
<SCRIPT type="text/tcl">
document write "<EM>This will work<\/EM>"
</SCRIPT>
VBScriptでは、文字参照関数 Chr() によって書き換えます。
"<EM>This will work<" & Chr(47) & "EM>"
スクリプトデータやスタイルデータが、様々な要素の属性値として記される場合（すなわちstyle属性や内在イベント系の属性として記される場合）、スクリプトデータやスタイルデータの内容として単引用符・二重引用符を記すのは避けて下さい。また文字参照以外の目的で「&」を記すのもやめてください。
まとめると、例えば次のように記すことになります。
<INPUT name="num" value="0"
onchange="if (compare(this.value, "help")) {gethelp()}">
[ISO8879]に適合したSGML利用環境においては、HTMLユーザエージェントでは広くサポートされていないような様々な機能を利用できます。この仕様書では、HTML文書を書く場合にはそうした機能を使わないよう求めます。
論理型属性を含むマークアップをする場合には、多くのユーザエージェントが完全書式<full form>ではなく最小型書式<minimized form>しか認識しないということに注意して下さい。
例えば、次の場合、
<OPTION selected>
下のようには書かない方がよい、ということです。
<OPTION selected="selected">
マーク区間は、C言語のプリプロセッサにおける「#ifdef」構造と同様の働きをします。
<![INCLUDE[ <!-- これは含まれます --> ]]> <![IGNORE[ <!-- これは無視されます --> ]]>
SGMLでは、内容をCDATAとするマーク区間の用法も定められており、そこでは「<」はタグの開始記号にはなりません。
<![CDATA[ <an> example of <sgml> markup that is not <painful> to write with < and such. ]]>
あるユーザエージェントが、マーク区間を理解していないということは「]]>」が表示されているという証拠によって示されます。つまり「<![」によって開始されたマーク区間の末尾がソース文書で最初に現れた「>」によって閉じられているという風に誤った処理をしたと考えられるわけです。
処理命令は、システム依存の文書処理を記すマーク付けです。処理命令は次のように「<?」と「>」の間に記します。
<?instruction >
処理命令の例を示しましょう。
<?> <?style tt = font courier> <?page break> <?experiment> ... <?/experiment>
HTML文書を書く場合は、多くのユーザエージェントが処理命令を単なる地の文として扱うことに注意が必要です。
SGMLの短縮タグ機構<SHORTTAG constructs>は、タイピングの煩雑さを軽減するかもしれませんけれども、SGMLアプリケーションに対して大きな能力を加えるようなものではありません。技術的には何の両義性をも伴わない機構ですが、実際の文書において新しい要素の拡張が行われるような場合にややこしさの元となります。そこで、属性に関連する短縮タグ機構は [HTMLでも] 広く利用され、また実装されていますが、要素に関連する短縮タグ機構は受け入れられていません。要素に対する短縮タグ機構を用いた文書はSGMLの文法には適合する文書しますが、多くの現存のHTMLツールにおいては正しく機能しません。
問題の [要素における] 短縮タグ機構とは、次のようなものです。
<name/.
<name1<name2>
<>
</>
この節では、検索エンジンにとって活用しやすいHTML文書を書くための手法について、いくつか提案します。
<LINK rel="alternate"
type="text/html"
href="mydoc-fr.html" hreflang="fr"
lang="fr" title="La vie souterraine">
<LINK rel="alternate"
type="text/html"
href="mydoc-de.html" hreflang="de"
lang="de" title="Das Leben im Untergrund">
<META name="keywords" content="vacation,Greece,sunshine"> <META name="description" content="Idyllic European vacations">
<LINK rel="start"
type="text/html"
href="page1.html"
title="General Theory of Relativity">
検索ロボットは、「http://www.foobar.com/」といったサイトをチェックしに出かけると、まず初めに「http://www.foobar.com/robots.txt」の有無を確認します。もし「robots.txt」ファイルがあれば、内容を読み、当該サイトの文書を索引づけの対象にしていいのかどうかを確認します。「robots.txt」ファイルを作る場合には、特定の検索ロボットに対してのみ索引づけを許可したり、特定のディレクトリやファイルについて不許可にしたりという書き方もできます。
次の例は全ロボットに対して当該サイトの全ページを索引づけ不許可にする「robots.txt」ファイルとなっています。
User-agent: * # applies to all robots
Disallow: / # disallow indexing of all pages
検索ロボットは、HTTPサーバが稼働している特定ホスト・ポート番号の所在を示すURIの直下のディレクトリで確認できる「/robots.txt」のみを読み込みます。有効な「robots.txt」の所在を例示しましょう。
| サイトのURI例 | そこで有効なrobots.txtの例 |
|---|---|
| http://www.w3.org/ | http://www.w3.org/robots.txt |
| http://www.w3.org:80/ | http://www.w3.org:80/robots.txt |
| http://www.w3.org:1234/ | http://www.w3.org:1234/robots.txt |
| http://w3.org/ | http://w3.org/robots.txt |
「/robots.txt」は1サイト1ファイルしか記せません。また、「robots.txt」はユーザ・ディレクトリには置かないようにしてください。検索ロボットがその「robots.txt」を発見できないからです。あなたがサイトの管理者で、ユーザ個々人に対して独自の「robots.txt」を用意させたいのであれば、個々の「robots.txt」の内容を結合してサイト全体としての「robots.txt」にその内容を反映させるようにしてください。この作業を行えない場合には、ユーザ個々人が各HTML文書において検索ロボットに対する制限を記した「META」宣言を行うように頼みましょう。
おまけ。URIの書式では文字種の区別が行われるので、「robots.txt」のファイル名は全て小文字で記す必要があります。また、1条件レコードの範囲においては空白行は入れられません。[訳注。正誤表に基づき訂正済み。]
対象とするロボット名すなわち「User-agent」名は、1条件文につき複数を記すことが可能です。またロボットは、「robots.txt」の各行を解釈するに当たっては寛大な判定基準を用いてください。バージョン情報を除く、大文字小文字の別を問わない名称の一致によってロボット名を判断するよう勧告します。[訳注。正誤表に基づき訂正済み。]
もしロボット名の値が「*」だった場合、他の条件文に該当しない全てのロボットへの制限条項であると解釈されます。この「*」による条件文は、1つの「robots.txt」ファイルにつき1箇所しか記せません。
条件文の「Disallow」列には、下記にようにして、索引づけを拒否するURIを記します。フルパス<full path>で書いても部分パス<partial path>で書いても構いません。ファイル名でなくパス名で記した場合は、そのパス以下のディレクトリにある全ファイルが索引づけの対象外となります。
Disallow: /help という記述の場合、 /help.html と /help/index.html の両方が索引づけ不許可となり、
Disallow: /help/ の場合は /help/index.html は不許可だけれども /help.html は索引づけが許されます。
値が記されていない「Disallow」列は、全ファイルが索引づけ可能であることを示します。「robots.txt」ファイルには、最低1つの「Disallow」列を記す必要があります。
META要素を使うと、HTML文書を書くだけで、検索ロボットに対して、当該文書を索引づけしていいかどうかやリンク部分のチェックをしていっていいかどうかなどの情報を表示できます。サーバ管理者の手を借りる必要はありません。
次の例文は、索引づけもリンク内容チェックも拒否する旨を示したものです。
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
「content」属性として表記可能な語は「ALL」「INDEX」「NOFOLLOW」「NOINDEX」です。これら「name」属性値と「content」属性値は、大文字小文字が区別されます。[訳注。正誤表に基づき訂正済み。]
注。 1997年初期の段階では、ごくわずかな検索ロボットしか、この仕組みを実装していません。けれども、検索ロボットに対する制限づけの仕組みについては、より広く知識が普及することによって実装が進むことが期待できます。
HTMLの表機能は、SGMLの優れた表機能や、商用ワープロソフトにおける作表機能、そして雑誌や書籍その他の印刷物における表レイアウト技術などを参考にして開発されました。そして、簡単に表をマークアップできて、しかも必要に応じて複雑なコントロールもこなせるような表機能として生み出されました。これにより、習得が容易で手作業でも実用になるHTML式表機能を利用できるようになっています。これはHTMLが成功するために必要な要点といえるでしょう。
また、別のソフトウエアで作った表をHTML形式にコンバートしたり、WYSIWYGなHTMLエディタで作表したりする人も増えています。こうしたオーサリングツールの機能に適合することも、HTML式表機能設計の重要な目標です。複数の列や表をまたぐセルをどのようにマークアップするかといったことや、桁揃え他見た目に関する設定内容を行・列単位で共有する方法などに関連します。
HTMLの表機能にとって重要な点は、読み手における表の見え方、つまり表示画面の大きさや、どんなフォントが使われるかといったことは、書き手が指示するものではないという点です。よって列幅を絶対的なピクセル数で指定すると表示が破綻する場合があります。その代わりに、表機能そのものは、表示ウインドウの大きさやフォントに合わせて柔軟に大きさが変わるように設計される必要があります。HTML文書の書き手は列幅の相対的な大きさを指定できますが、書き手の指定には必ずしも拘らずに必要に応じてセル内の最も大きな要素に合わせて列幅の変更を行うことが、ユーザエージェントの動作としては望まれます。ただし書き手の指示を上書きする必要が乗じた場合、個々の列の相対的な大きさの関係はあまり大幅には変えないようにしてください。
巨大な表や、低速回線でのデータ転送の際に、表データの逐次表示が可能であれば、読み手を待たせずにすみます。そうすると、ユーザエージェントは、表データ全体が到着するのを待たずに表を描き始められるようになります。多くのユーザエージェントでは [半角] 80文字分程度の表示画面幅が規定値で、また多くのHTML文書で扱われている画像サイズもそうした画面サイズを前提にしています。表の列数や、表全体の幅と各列の幅を明示的に指定しておけば、ユーザエージェントは表データの逐次表示に取りかかれます。
逐次表示を行うために、読み手の「ブラウザ」は、表に含まれる列の個数とその幅がどれだけかを知る必要があります。表全体の幅に関する既定値は表示画面サイズ全体（width="100%"）です。この表全体の幅は、TABLE要素のwidth属性によって変更可能です。また既定値としては各列は等しい幅に分割されることとなっていますが、COL要素によって表のデータ内容とは別に予め列幅の指定を行うこともできます。
列幅指定と同時に逐次表示に必要な列数指定について、第1行のデータを確認してから自動的に判定すればよいという意見もあります。けれども、セル内に非常に多くの内容が記されていた場合には、判定までかなり時間がかかってしまいます。大局的に見て、逐次表示を行いたい場合により有効な列数判定方法は、書き手がTABLE要素中で列数を明示的に記しておくことでしょう。
最後に、HTMLで表を書く場合に、指定通りに逐次表示を行うべきか、データ内容に合わせて自動的にレイアウト調整を行うべきかをユーザエージェントに伝える必要があります。二段構えで表示することとなる自動レイアウト調整を行わせる場合、列数は最初に表示してみた段階で確認されます。逐次表示の場合（COL要素やCOLGROUP要素の列数指定によって）、まず列数を先に確認しておくこととなります。
HTMLでは、段落分けや引用部分など文章構造に関するマークアップと、余白・フォント種別・色指定などレンダリングに関するマークアップが、明解に区別されます。この区別は表構造にどのような影響を与えるでしょうか。非常に厳密に言うと、各セル内の文字の幅寄せや桁揃え、あるいはセル間の罫線などを指定するのはレンダリングに関するマークアップであって、構造に関するマークアップではありません。けれども実際上、こうした内容はアプリケーション間での移植が容易なので、構造定義のマークアップと併せて行う方が便利です。HTMLの表機能はレンダリング指定に関する能力の大部分をスタイルシートに委ねていて、この仕様書が示している表モデルはスタイルシートの利点を活かすように設計されていますが、スタイルシートがどうしても必要だというわけではありません。
現在のDTPアプリケーションは、非常に複雑な表を作成できますが、それをそのままHTMLで再現しようというのは実際的ではありません。HTML仕様をRTFやらMTFやらのように鈍重なリッチテキスト・フォーマット仕様に変更する必要が生じてしまいます。この仕様書では、そうした方向は取らずに、よく利用されている枠線スタイルをいくつか選べるようにだけしました。frame属性によって表全体の外枠について設定でき、またrules属性によって表の内部の罫線について設定できます。更に細かい表現はレンダリング関連の指定によって行います。個々の要素に対してはstyle属性によってレンダリング設定が行え、またより詳しいレンダリング設定は、「HEAD」要素内にSTYLE要素として記したスタイルシートあるいは外部スタイルシートへのリンクを示すことで、行えます。
この仕様に取りかかっている間、表の枠線・罫線の指定方法について、様々な道筋を考慮しました。1つは、作られ得る枠線・罫線の組合せ状態に関するものです。縁取りの追加や削除をサポートすると、線の引き方を判定するアルゴリズムは複雑なものとなります。例えば、表を構成する全要素に対して枠線frame属性と罫線rules属性が利用される場合、あるセルの1辺を線引きするかしないかを判定するために24段階の計算が必要となってくるのです。にも関わらず、これだけ複雑なことをやっても、表のレンダリングに必要だと思われる手法の全てをコントロールするには十分ではありません。そこでこの仕様書では、敢えて、多くの用途に利用できる簡単で判りやすい表モデルを構築しておくに留めることとしました。より複雑な表モデルを標準化するまでには、まだまだ多くの研究が必要でしょう。
この仕様書ではHTML+の初期の作業で示された簡素な表モデルの上位モデルを策定しました。表というのは、キャプションと、セルの集合である行の連なりとで構成されるものだと考えることができます。[HTML+の] 表モデルは、見出しセルとデータセルの区別や、複数の列や行をまたぐセルの設定を可能にしています。
CALSの表モデル（[CALS]の項を参照のこと）に準じ、この仕様書では表の各行を「頭部」「本体」「脚部」にグループ化できるようにしました。これにより、レンダリングに関する設定を簡素化でき、またページ単位で出力する際に、ページをまたぐような大きな表の場合に頭部・脚部を各ページに繰り返し表示することや、画面上で頭部・脚部を固定したまま本体部分だけをスクロールするというようなことが可能になりました。なお、ソース文書のマークアップにおいては、脚部は本体より先に記すことになります。「CALS」と共通する、巨大な表を扱う場合における最適化の結果生まれた表記法です。これにより、全表データの到着を待たずに、[頭部と] 脚部を表示できます。
視力に障害のある方々のために、HTML 4.0では、ウインドウシステムに基づくグラフィカルなユーザインターフェイスのみに適合してしまうことから引き起こされるアクセス障壁をなくせるような仕組みを設けました。例えば音声出力環境でも判りやすい表表現ができるように、各セルに対してラベルづけを行える属性を設定可能にしました。このラベルづけに用いる属性は、HTMLの表データを機械的にデータベースや表計算アプリケーションに移植する際にも利用できるでしょう。
表示しようとする表に、COL要素かCOLGROUP要素による列数の指定がされていれば、表は固定レイアウト・アルゴリズムによって表示して下さい。それ以外の場合には、下で述べる自動レイアウト・アルゴリズムによって表示して下さい。
また、「width」属性が指定されていない場合、表全体の幅を100%と仮定して表示を始めて下さい。
「width」属性の指定を活かすとセル内容がはみ出してしまうような場合には、表の幅を拡げて下さい。その限りにおいて、書き手の指定を上書きする必要があります。また、表示幅との兼ね合いで文章の折り返しが生じる際に、極端に移動距離の長いスクロールになることを避ける必要があったり、またそうしたスクロールが出来なかったり無効化されていたりする場合には、あふれた文章を切り捨ててしまって構いません。
表を表示する際には、キャプション（CAPTION要素の内容）を、表のセルとして扱う必要があります。表の上部あるいは下部に表示するキャプションは全ての列をまたぐ大きなセルとして扱い、また表の左あるいは右に表示するキャプションは全ての行をまたぐ大きなセルとして扱って下さい。
固定レイアウト・アルゴリズムの場合、列数が既に指定されているものとします。各列の幅は均等割りというのが既定値です。書き手はこの列幅をCOLGROUP要素やCOL要素での相対指定や絶対指定によって変更可能です。表全体の幅の既定値は表示画面中の左右の余白を引いた残りとなりますが、TABLE要素のwidth属性値または各列の絶対幅指定が優先します。列幅の絶対指定と相対指定が組み合わされていた場合には、まず表全体の幅から絶対指定による列幅を確保し、次に残りを相対指定の値によって割り振ることとなります。
表のマークアップ方法それ自体は、属性値が正確かどうかを保証するものではありません。例えば、COL要素やCOLGROUP要素が指定している列数と、実際に存在するセル数の間に食い違いが起こり得ます。それはそれとして、表示に当たって問題になるのは、表の幅が狭くてセル内容がはみ出してしまう場合です。TABLE要素やCOL要素が指定する表示幅ではセル内容がはみ出してしまう、という場合が起こるわけです。もしセル内容がはみ出してしまうような場合、ユーザエージェントは、上手にそれを回避してください。例えば単語のハイフネーションを行うとか、文法的に正しいハイフネーション位置が判らない単語の場合には適宜分割してしまうとか。
分割できない要素によってセル内容のはみ出しが発生した場合は、列幅を調整し、表全体を表示し直してください。また、列幅調整かつ/またはスクロール表示が不可能であるような最悪の場合にはセル内容を切り捨ててしまうのもやむを得ないでしょう。何にせよ、セル内容の分割や切り捨てが行われた場合には、その旨を読み手に対し適宜知らせる必要があります。
表示しようとする表の列数が、COL要素やCOLGROUP要素で指定されていなかった場合、ここで述べる自動レイアウト・アルゴリズムによって表示して下さい。各セルのデータ内容をチェックし、列の表示サイズを計算するという、2段構えのレイアウト方法です。
最初の処理の際には、セル内に長い文章があっても自動改行をせず、各セルの最小・最大幅をチェックすることに努めて下さい。最大幅は最長の文章によって求めます。自動改行をしないので、BR要素による改行がない限り、各段落は非常に長い1行の文章として扱います。最小幅は、インデントやリスト項目先頭の●なども勘案しつつ、最も大きな構成要素（単語や画像など）によって求めます。言い換えると、セル内容があふれてしまわないギリギリのところで最小幅を決める必要があるということです。ただし単語の分割を認めることで、水平スクロールの必要を減らし、また最悪の場合セル内容が切り捨てられてしまうというような危険は避けられます。
この列幅決定仮定は、ある表のセル内に入れ子にされている表においても適用されます。内側の表の最小・最大幅は、その表自身の幅に反映されると共に、外側の表のセル幅にも影響します。この最小・最大幅決定のアルゴリズムは、各セル間において一律に働き、また入れ子が何層であっても大概等しく働きます。
またセル内容の桁揃えとの兼ね合いで、ある列の最小・最大幅の計算には、次の3種の数字を組み込む必要があります。桁揃え位置の左側の総計、右側の総計、そして桁揃えに関係のない部分。そこで、各列の最小幅は次の計算によって求めることとなります。 max(min_left + min_right, min_non-aligned) [最大でも、桁揃え左側最小値と桁揃え右側最小値の合計か、桁揃えに関係のない部分の、どちらか大きい方]。
各セルの最小・最大幅は、列の最小・最大幅決定の根拠として用いられます。そして決められた列幅は、表全体の最小・最大幅を決めるために利用されます。セルの中に別の表を入れ子にできるという点に注意が必要ですが、入れ子にできること自体は計算過程を大幅に複雑化させるというようなものではありません。ここまでで第1段階の計算過程は終わりで、次は表示可能領域内（すなわち左右の余白を取った残り）での、各列幅の割り振りに取りかかることとなります。
複数列をまたぐセルの場合、単純に、またぐセルの各々に対して最小・最大幅を均等に割り振って考えればよいでしょう。少し複雑に考えるなら、またぐセルの各々の最小・最大幅の比率に応じて割り振るという手だてもあります。経験上、この2つの方法を併用することで、多様な表構造に対して充分な表示結果をもたらすことが判っています。
表の外枠線と各セル間の余白もまた、セル幅を決めるに当たって考慮する必要があります。次の3通りの事例があるでしょう。
以上の計算過程は、入れ子になった表においても繰り返されます。内側の表の表示幅を計算する場合、外側の表のセル幅が、上述の表示可能領域の幅ということになります。入れ子の処理は、全階層に渡って繰り返されます。入れ子の表の場合、まず最上位の表が先に表示され、続いて内側の表が外側の表のセル内容として表示され始めます。
表全体の幅がwidth属性で指定されている場合、ユーザエージェントは、列幅をその表幅に合わせて調節します。けれども列幅の最小値の合計よりも指定された表幅が小さかった場合には、width属性での指定による拘束を受けるものではありません。
COL要素によって相対指定が行われている場合、各列の幅は、その相対指定の比率に合わせて最小幅から増やされていきます。ただしCOL要素の相対指定は表示のための目安でしかなく、必要な最小幅を下回るような調整は行うべきではありません。同様に、表示可能領域を越えてまで列幅を拡げることも避けねばなりません。COL要素の相対指定が「0」だった場合、常に最小値の列幅で表示して下さい。
2段構えアルゴリズムによって表のレイアウトを行う場合、明示ないし継承されたcharoff属性が設定されていない状態での桁揃え位置に関する既定値は、「align="char"」属性・値で指定されている桁揃え基準文字の前方・後方の文字列の最大値を確認した上で、列幅の中心線を桁揃えの基準線としておきます。逐次表示の場合は「charoff="50%"」として処理します。またある列の別々の行に属する複数のセルに桁揃えの指定がある場合には、桁揃え文字が何であるかに拠らず、その指定に沿って列全体の桁揃えを行います。もし桁揃えを行おうとした際に、ある列で列幅指定を越えてしまうことになるような大きすぎるオブジェクトを扱う必要が生じた場合は、あふれ処理のルールが適用されます。
属性名の選定基準について。 frame属性とrules属性の間で値に一貫性があり、また位置を指し示す用語にも統一性がある方が望ましいことは自明です。具体的には、「none、top、bottom、topbot、left、right、leftright、all」という語が共用できればそれに越したことがないわけです。ところが残念なことに、SGMLでは、列記する場合の属性値については各々違うものでなければならないという文法になっています。そこで、「none」「left」「right」「all」において、衝突の問題が発生します。そのため、この仕様書においてframe属性の名称を定める際、rules属性、align属性、valign属性との衝突を避けるようなものを用いることにしました。これは、将来のバージョンのHTMLにおいてframe属性とrules属性が表に関連する他の要素にも付け加えられると予想される事態に関する衝突回避基準を定めた形になっています。代替案はframe属性をCDATA型属性にするというものです。W3CのHTMLワーキンググループにおいては、一貫した名前を用意することよりはSGMLの検証ツールを利用できることで得る利益の方が大きいという合意に達しました。
フォームの場合は、ソース文書データを到着順に逐次表示することによって問題が起きてしまうケースがあります。ユーザエージェントは、フォームを扱う場合、フォームの全ソース文書データが届かないうちに読み手が送信ボタンを押したりできないよう、気遣う必要があります。
また逐次表示を行っている場合のタブキー移動の扱いにも、少々注意が必要です。到着しているソース文書を一瞥した範囲で発見される「最低位」のtabindex項目にタブキー移動先としての焦点を合わせることには一理あります。もちろんソース文書全体が読み込まれてみれば「最低位」のtabindexの実際の位置関係も変わってくるわけですが、全文を読み込み終える前に読み手がタブキー入力をした場合、その時点で既に読み終えている範囲で「最低位」のtabindex項目に焦点を合わせるのが合理的判断というものです。
フォームがクライアント側スクリプトと組み合わされている文書の場合、より取り扱いに問題がある場合があります。例えば、現在表示されている部分のスクリプトハンドラが、まだ表示されていない部分を参照する内容だったような場合など。
この仕様書では一般的なフォーム設計に対して充分な能力を発揮しうる要素・属性を定めました。けれども、まだ幾つか改良の余地があります。例えば次のような点が既に次期HTML仕様への課題として浮上しています。
他に施し得るフォーム機能の拡張は、クライアント側イメージマップとして機能しているINPUT要素のtype属性が「image」である場合にusemap属性を設定可能にすることです。サーバ側のスクリプト変更を不要にするため、INPUT要素とクライアント側イメージマップの併用を行う際にはAREA要素の拡張によって x y 座標値を取得できるようにする方がいいでしょう。
このHTML 4.0仕様は、CDATA型属性において将来利用され得るスクリプトマクロの記述方法を予約しています。その目的は、当該ページの初めの方に出現するオブジェクトのプロパティを利用した属性値記述を行えるようにすることで、次の書き方を想定しています。
attribute = "... &{ macro body }; ... "
マクロの記述は、既定のスクリプト言語 [として宣言したスクリプト言語] による1行以上のスクリプト文<statement>で、（intrinsic event属性毎に）行います。上記のように閉じ中括弧<right brace>に続けてセミコロンを常に記す必要があり、単独の閉じ中括弧<right brace>「｝」はマクロ記述の本文として扱われます。またマクロによる属性値記述を行う場合は常に引用符によって値全体を囲う必要があります。
CDATA型の属性の処理は次のようになります。
マクロ処理は、ソース文書の読込（あるいは再読込）の時点で行われますが、表示ウインドウの大きさ調節や再描画などの際には行われません。
使えなくなる書き方（DEPRECATED EXAMPLE）:
次に JavaScript による文例をいくつか挙げます。最初の例は背景色を [文書の読込毎に] ランダムに指定するものです。
<BODY bgcolor='&{randomrbg};'>
あるいは背景色を夜の時間に合わせて暗くしようと考える人もいるでしょう。
<BODY bgcolor='&{if(Date.getHours > 18)...};'>
次の例は JavaScript とクライアント側イメージマップを組み合わせたものです。
<MAP NAME=foo>
<AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
</MAP>
この例は画像サイズを document プロパティに対応させて指定するものです。
<IMG src="2};' height='50%' alt="banner">
スクリプトによって記したリンクや画像のURIをスクリプトによって記述することもできます。
<SCRIPT type="text/javascript">
function manufacturer(widget) {
...
}
function location(manufacturer) {
...
}
function logo(manufacturer) {
...
}
</SCRIPT>
<A href='&{location(manufacturer("widget"))};'>widget</A>
<IMG src='&{logo(manufacturer("widget"))};' alt="logo">
次の最後の例は、SGMLで言うCDATA型属性値がどのように単引用符・二重引用符を扱うかを示すものです。値全体を単引用符で囲んだ場合、属性値の一部として二重引用符を用いることができます。もちろん「"」と書いて値としての二重引用符を代用することもできます。
<IMG src="&{logo(manufacturer("widget"))};" alt="logo">
目標枠名<frame target name>が一意であるという保証はないので、念のため、目標フレーム枠名を確認するために現在行われている手法を記しておきます。
注。 ここで述べる代替テキスト生成アルゴリズムは、W3CのWeb Accessibility Initiative Groupによる勧告文書の指定に対し、その地位を譲るものとします。詳しくは[WAIGUIDE]をご覧下さい。
もしalt属性の設定がないIMG要素やAPPLET要素を扱う必要が生じた場合、ユーザエージェントは、次の手順に沿って代替テキストを生成して下さい。
もしalt属性の設定がないINPUT要素を扱う必要が生じた場合、ユーザエージェントは、次の手順に沿って代替テキストを生成して下さい。
アンカー、埋め込み画像、及びパラメータとしてURIを含む他のあらゆる要素は、読み手の反応によってURI値を取得させます。この場合、[RFC1738]第6章のセキュリティに関する内容に配慮する必要があります。フォームの送信要求の受け答えを行う通信手段 -- HTTP と SMTP -- は、機密保持に関してほとんど何の保証もできないからです。微妙な内容の情報をフォームによって取り扱おうとする場合、とりわけ「type="password"」形式のINPUT要素については、セキュリティに関する注意を読み手に促してください。
ユーザエージェントは、読み手が明示的に送信を求めたファイル以外は送信すべきでありません。そこで、HTMLユーザエージェントは、INPUT要素のvalue属性値に設定される可能性のある形式のファイル名を正しく認識できるようにしなければなりません。また書き手は隠し選択肢でファイルを定義してはいけません。
この仕様書では、データの暗号化<encryption>のメカニズムについては何も定めていません。何か相応しいデータ転送処理メカニズムでもって扱ってください。
いったん送信されたファイルは、処理側プログラムによって適切に処理・格納されるべきでしょう。