前   次   目次   要素   属性   索引

附属書B 性能, 実装及び設計のための備考

附属書Bに示す備考は，参考であって，規定ではない。"しなければならない"及び"することが望ましい"といった用語が用いられてはいるが，附属書Bの中の要件は，すべてこの標準情報(TR)の他の箇所に現われている。

B.1 妥当でない文書に関する備考

この標準情報(TR)は，利用者エージェントがこの文書で規定されていない要素，属性，属性値，又は実体に出会う場合にどのように振る舞うかを含めて，適合する利用者エージェントが，一般的なエラー条件をどのように処理するかを定義しない。

しかし, HTMLの様々な版の実装間での実験及び相互運用性を促進するために，次の振る舞いを推奨する。

利用者にそれらのエラーを知らせるためのサポートを利用者エージェントが提供することも推奨する。

エラー条件の処理方法は利用者エージェントによって様々なため，文書作成者及び利用者は，固有のエラー回復の振る舞いに依存してはならない。

HTML 2.0規定([RFC1866])は，多くのHTML 2.0利用者エージェントが，文書型宣言で始まらない文書はHTML 2.0規定を参照していると仮定しているという推定をしている。経験上，この推定は不十分であると分かっているので，現規定は，この振る舞いを推奨しない。

相互運用性のために，文書作成者は，利用可能なSGML機構を通じて，DTDを拡張したり，実体定義の新しい集合を付加するなど，HTMLを"拡張"してはならない。

B.2 URI属性値の特殊文字

B.2.1 URI属性値の非ASCII文字

URIは非ASCII値を含まないが([URI]の2.1参照)，文書作成者は，URIを期待する属性値(すなわち，DTDで%URI;を用いて定義されている属性値)で非ASCII値を指定する場合が時々ある。例えば，次のhref値は，不当である。 

<A href="http://foo.org/Håkon">...</A>

そういった場合に，非ASCII文字を処理するために，利用者エージェントが次の規約を採用することを推奨する。

  1. UTF-8([RFC2044]参照)を使い1個以上のバイトで各文字を表現する。
  2. URIのエスケープ機構を用いて，すなわち，各バイトを%HH(ただし，HHはバイト値の16進表記)に変換することによって，各バイトをエスケープする。

この方法は，[RFC1738]の2.2又は[RFC2141]の2で定義されるとおりに，URIを運ぶHTML文書が符号変換されるかもしれない文字符号化に依存しない，構文上正当なURIを生じる。

備考　 受信した文書の文字符号化のバイトを用いて，HTML内のURIをそのまま処理する古い利用者エージェントも存在する。このやり方に依存しており符号変換がされると破綻してしまう古いHTML文書もある。これらの古い文書を処理したい利用者エージェントは，正当な集合以外の文字を含むURIを受信した場合，最初に，UTF-8に基づく変換を用いることが望ましい。結果として得られたURIが解決できない場合に限り，受信した文書の文字符号化のバイトに基づき，URIの構成を試みることが望ましい。

備考　 UTF-8に基づく同じ変換を，A要素に対するname属性の値にも適用することが望ましい。

B.2.2 URI属性値のアンパサンド

フォームが実行依頼される場合に構成されるURIは，A要素に対するhref属性など，アンカスタイルリンクとして使用されてもよい。残念なことに，フォームフィールドを分離するための"&"文字の使用は，文字実体参照を区切るためにSGML属性値での使用と相互に作用し合う。例えば，"http://host/?x=1&y=2"というURIをリンク付けURIとして使用するためには，<A href="http://host/?x=1&#38;y=2">又は<A href="http://host/?x=1&amp;y=2">と書かなければならない。

HTTPサーバ実装者，特にCGI実装者が，"&"の代わりに";"の使用をサポートし，この方法によって"&"文字をエスケープするトラブルを文書作成者が避けられるようにすることを推奨する。

B.3 SGML実装の備考

B.3.1 行区切り

SGML([ISO8879]の7.6.1参照)は，開始タグの直後に続く行区切りを無視し，同様に，終了タグの直前にある行区切りも無視しなければならないと規定している。これは，すべてのHTML要素に例外なく適用される。

次の二つのHTMLの例は，同一になるようにレンダリングされなければならない。 

<P>Thomas is watching TV.</P>

<P>
Thomas is watching TV.
</P>

次の二つの例も同一にレンダリングされなければならない。 

<A>My favorite Website</A>

<A>
My favorite Website
</A>

B.3.2 非HTMLデータの指定

スクリプト及びスタイルデータは，要素内容又は属性値として現われよい。次では，HTMLマーク付けと外部データとの間の境界を記述する。

備考　 DTDは，スクリプト及びスタイルデータを要素内容及び属性値の両方に対してCDATAであると定義する。SGML規則は，CDATA要素内容中では文字参照を許容しないが，CDATA属性値中ではそれを許容する。文書作成者は，要素内容と属性値との間でスクリプト及びスタイルデータを切り取ったり貼り付けたりする際に，特に注意することが望ましい。

この非対称性は，同様に，豊富な文字符号化から貧弱な文字符号化に符号変換する場合，符号変換器が，スクリプト又はスタイルデータにおける変換不能な文字を単純に対応する数値文字参照に置き換えできないことを意味する。データを正確に処理するためには，HTML文書を構文解析し，各スクリプト言語及び各スタイル言語の構文について知らなければならない。

要素内容 

スクリプト又はスタイルデータが要素(SCRIPT及びSTYLE)の内容である場合, データは，要素開始タグの直後から始まり，最初のETAGO("</")区切りに名前文字([a-zA-Z])が続くもので終了する。これは，要素の終了タグとは限らない点に注意すること。そのために，文書作成者は，内容中の"</"をエスケープすることが望ましい。エスケープ機構は，各スクリプト言語又は各スタイルシート言語に固有とする。

不正な例


次のスクリプトデータは，"</EM>"の一部として，SCRIPT終了タグの前に"</"シーケンスを正しくなく含んでいる。 

    <SCRIPT type="text/javascript">
      document.write ("<EM>This won't work</EM>")
    </SCRIPT>

JavaScriptでは，この符号は，SGML名前開始文字の前のETAGO区切りを隠ぺいすることによって，正しく表現できる。

    <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属性又はintrinsic event属性のいずれかの属性の値である場合，文書作成者は，スクリプト言語又はスタイル言語の規約に従って，値の中の区切りである1重引用符又は2重引用符の出現をエスケープすることが望ましい。文書作成者は，"&"が文字参照の開始を意味しない場合は，"&"の出現もエスケープすることが望ましい。

例えば例として，次を書くことができる。

 <INPUT name="num" value="0"
 onchange="if (compare(this.value, &quot;help&quot;)) {gethelp()}">

B.3.3 サポートが限定されたSGML機能

[ISO8879]に適合するSGMLシステムは，HTML利用者エージェントで広くはサポートされていない多くの機能を認識すると期待される。文書作成者が，これらの機能すべてを使用するのは避けることを推奨する。

B.3.4 論理的属性

文書作成者は，多くの利用者エージェントが論理的属性の最小限の形式だけを認識し，完全な形式を認識しないことを知っておくことが望ましい。

例えば, 文書作成者は次を指定したいかもしれない。 

<OPTION selected>

これは，次の代わりに指定されている。 

<OPTION selected="selected">

B.3.5 マーク付き区間

マーク付き区間は，C言語のプリプロセサが認識する#ifdef構成要素と似た役割を果す。 

<![INCLUDE[
 <!-- this will be included -->
]]>

<![IGNORE[
 <!-- this will be ignored -->
]]>

SGMLは，CDATA内容に対するマーク付き区間の使用も定義しているが，例えば，その中の"<"は，タグの開始として処理されない。

<![CDATA[
 <an> example of <sgml> markup that is
 not <painful> to write with < and such.
]]>

利用者エージェントがマーク付き区間を認識していないことを示すサインは，"]]>"の出現であって，これは，利用者エージェントが誤って最初の">"文字を"<!["で始まるタグの終了として使用した場合に現れる。

B.3.6 処理命令

処理命令は，プラットフォーム固有の慣用句を捕らえるための機構である。処理命令は，<? で始まり > で終わる。 

<?instruction >

例を次に示す。 

<?>
<?style tt = font courier>
<?page break>
<?experiment> ... <?/experiment>

文書作成者は，利用者エージェントの多くが処理命令を文書のテキストの一部としてレンダリングすることを認識することが望ましい。

B.3.7 短縮マーク付け

幾つかのSGML SHORTTAG構成要素は，入力の手間を減らすが，SGMLアプリケーションに表現能力を付加しない。これらの構造は，技術的にあいまい性をもたらさないが，特に新しい要素を含めるために文書が拡張される場合には，文書の頑健性を減少させる。このため，属性に関係するSGMLのSHORTTAG構成要素は広く使用され実装されているが，要素に関係するSGMLのSHORTTAG構成要素はそうではない。それらを使用する文書は，適合SGML文書ではあるが，多くの既存のHTMLツールではうまく作動しない。

問題のあるSHORTTAG構成要素を次に示す。

B.4 検索エンジンのウェブサイトを索引付け支援に関する備考

B.4では，文書を検索エンジンからよりアクセスしやすくするための，簡単な提案を幾つか行う。

文書言語の定義
ウェブの大域的な文脈では，ページがどの自然言語で書かれているかを知ることが重要である。これは，言語情報の節で示される。
文書の他言語の版の指定
文書の，他の言語による翻訳を用意している場合，LINK要素を使用してそれらを参照することが望ましい。これによって，索引付けエンジンは，問合せがどのように書かれていても，利用者が望む言語で検索結果を利用者に提供することができる。例えば，次のリンクは，検索エンジンにフランス語及びドイツ語による代替物を提供する。 
<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要素を探す索引付けエンジンも存在する。検索エンジンは，これらのキーワードを検索の結果として提供してもよい。この標準情報(TR)は，検索属性によって検索されるname属性の値を定義しない。次の例を参考のこと。 
<META name="keywords" content="vacation,Greece,sunshine">
<META name="description" content="Idyllic European vacations">
集まりの先頭の指示
ワープロ文書又は表示の集まりが，HTML文書の集まりに変換されることも多い。検索で見つかったページに加えて，その集まりの先頭を参照するのは検索結果において有用である。title属性とともにrel="start"をもつLINK要素を使用することによって，検索エンジンを支援してもよい。その例を次に示す。 
 
<LINK rel="begin" 
         type="text/html"
         href="page1.html" 
         title="General Theory of Relativity">
ロボットへの索引付け命令の提供
索引付けロボットによって自分のサイトが索引付けされていること，及びサイトの機密な部分をロボットが訪れることを許可しないほうがよかったと分かって驚く人々もいる。多くのウェブロボットは，ウェブサイト管理者及び内容提供者に索引付けロボットの作業を制限する機能を提供する。これは"robots.txt"ファイル及びHTML文書のMETA要素という二つの機構を通じて可能となる。この二つの機構について次に示す。

B.4.1 検索ロボット

robots.txt ファイル 

ロボットがhttp://www.foobar.com/などのウェブサイトを訪れる場合，最初に，http://www.foobar.com/robots.txt.を検査する。この文書を発見できた場合，ロボットはその内容を分析して，文書検索が許されているかどうかを調べる。robots.txtファイルをカスタム化して，特定のロボットだけに適用したり，特定のディレクトリ又はファイルへのアクセスを禁止することができる。

次に，robots.txtファイルの例を示す。このファイルは，すべてのロボットがサイト全体を訪れることができないようにしている。

        User-agent: *    # applies to all robots
        Disallow: /      # disallow indexing of all pages

ロボットは，単にサイト上の"/robots.txt" URIを探すだけであるが，その場合，サイトは特定のホスト及びポート番号で動作しているHTTPサーバとして定義される。次に，robots.txtの位置の例を幾つか示す。

サイトURI robots.txtのURI
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"だけが存在できる。特に，利用者ディレクトリに"robots.txt"ファイルを配置することは望ましくない。これは，ロボットがそれを決して見ようとしないからである。利用者が自分自身の"robots.txt"を生成できるようにしたいと考える場合は，それらすべてを単一の"/robots.txt"にマージする必要がある。これをしたくない場合には，利用者は，代わりにRobots META Tagを使用したいと考えるかもしれない。

幾つかのヒントを次に示す。URIは，大文字及び小文字を区別し，文字列"/robots.txt"は，すべて小文字でなければならない。空行は認められない。

レコードごとに，ただ一つの"User-agent"フィールドが存在していなければならない。ロボットは，このフィールドの解釈に関しては自由であることが望ましい。版情報をもたない名前の大文字・小文字を区別しない部分文字列の一致が，推奨される。

値が"*"である場合，そのレコードは，他のレコードのどれにもマッチしなかったロボットすべてに対するデフォルトアクセス方針を記述する。"/robots.txt"ファイルにそういったレコードが複数存在することは許されない。

"Disallow"フィールドは，訪れられることが望ましくない部分的なURIを指定する。これは，完全パスでも部分バスでもよい。この値で始まるURIは，どれも検索されない。例を次に示す。 

    Disallow: /help disallows both /help.html and /help/index.html, whereas
    Disallow: /help/ would disallow /help/index.html but allow /help.html.

"Disallow"に対する空値は，すべてのURIが検索できることを示している。robots.txtファイルには，"Disallow"フィールドが少なくとも一つ存在しなければならない。

ロボット及びMETA要素 

META要素によって，HTMLの文書作成者は，文書を索引付けしてよいかどうか，又はより多くのリンクを収集するために使ってよいかどうかを，訪れたロボットに知らせることができる。サーバ管理者が何かすることは要求されない。

次の例では，ロボットは，この文書を索引付けすることも，リンクに関して文書を分析することもしないのが望ましい。 

<META name="ROBOTS" content="NOINDEX, NOFOLLOW">

contentにおける語は，ALL, INDEX, NOFOLLOW, 又はNOINDEXとする。name及びcontentの属性値は，大文字及び小文字を区別しない。

備考　 1997年の初めには，これを実装するロボットはわずかだが，索引付けロボットを制御することに，より公的な注意が向けられているので，変化することが期待される。

B.5 表に関する備考

B.5.1 設計の根拠

HTML表モデルは，既存のSGML表モデル，一般的なワード処理パッケージにおける表の取扱い，並びに雑誌，本及びその他の紙に基づく文書での広範囲にわたる表レイアウト技術の研究から発展してきた。モデルは，簡単な表は単純に表現でき，必要な場合には複雑さが単純に追加できるように選択された。これによって，一般のテキストエディタでHTMLの表へのマーク付けを生成することが実用的になり，初期に学ぶことが減る。この機能は，今日のHTMLの成功に非常に重要であった。

他の文書フォーマットから変換することによって，又はWYSIWYGエディタを用いて直接に生成することによって，表を設計することが，ますます増えている。HTML表モデルが，これらの作成ツールにうまく適応することが重要である。これは，複数の行又は列にまたがるセルをどのように表現するか，配置特性及び他の表示特性がセルのグループとどのように関連付けられるかに影響する。

動的な再フォーマット化 

HTML表モデルに関する主な問題は，文書作成者が，利用者がどのように表のサイズを決めるか，どのフォントを使用するかなどを制御しないことにある。これによって，絶対的な画素単位で指定された列幅に依存することは危険になる。代わりに，表は，動的にサイズを変更して，現在のウィンドウのサイズ及びフォントに一致できなければならない。文書作成者は，列の相対幅に関する指針を提供できるが，利用者エージェントは，列がセル内容の最大要素の幅をレンダリングするのに十分な幅をもつことを確実にすることが望ましい。文書作成者の指定を上書きしなければならない場合，各列の相対幅を大きく変更しないことが望ましい。

増加的ディスプレイ 

大きな表，又は低速のネットワーク接続に対しては，利用者の要求を満たすために，増加的な表の表示(display)が重要となる。利用者エージェントは，データをすべて受信する前に表の表示を開始できることが望ましい。ほとんどの利用者エージェントではデフォルトウィンドウ幅は約80文字であって，多くのHTMLページのための図形は，このデフォルトを用いることを想定して設計されている。列の数を指定し，表幅と別の列の幅との制御の準備を備えることによって，文書作成者は，表の内容を増加的に表示できる利用者エージェントにヒントを与えることができる。

増加的な表示のために，ブラウザは列の数及びその幅を必要とする。表のデフォルト幅は，現在のウィンドウのサイズ(width="100%")である。これは，TABLE要素のwidth属性を設定することによって変更できる。デフォルトではすべての列の幅は同じとするが，表データを開始する前に，一つ以上のCOL要素で列幅を指定できる。

残る問題は列の数である。表の最初の行を受信するまで待機することを提案する人もいるが，これは，セルが多くの内容をもつ場合には長い時間がかかる。増加的な表示が求められる場合には，総じて，文書作成者にTABLE要素の列数を明示的に指定させる方がより理にかなっている。

文書作成者は，依然として，利用者エージェントに増加的な表示を使用するかどうか，又はセルの内容に合った表のサイズを自動的に決定するかどうかを知らせる方法を必要としている。2パス自動サイズ化モードでは，列数は最初のパスで決定される。増加的モードでは，列数は，COL要素又はCOLGROUP要素を用いて，先行提示されなければならない。

構造及び表示 

HTMLは，段落及び引用のような構造的なマーク付けを，マージン，フォント，色などのレンダリングの慣用句とは区別する。この区別は，表にどのような影響をもたらすか。理論的な見地からいえば，表セル内のテキストの配置及びセル間の境界線は，レンダリングの問題であって，構造の問題ではない。しかし，実際には，これらの機能はあるアプリケーションから次のアプリケーションへとかなりの部分移植可能なので，これらを構造的情報と一緒にグループ化することが有益となる。HTML表モデルは，ほとんどのレンダリング情報を関連するスタイルシートにゆだねる。この標準情報(TR)で提供するモデルは，それらスタイルシートの利点を利用できるが必要とはしないように設計されている。

現在のデスクトップパブリッシングパッケージは，表のレンダリングについて極めて豊富な制御を提供しており，これを，RTF又はMIFのような大量のテキストフォーマットに変換することなくHTMLで再現することは現実的でない。しかし，この標準情報(TR)は，文書作成者に，一般的に使用される境界線スタイルのクラスの集合から選択できるようにする。frame属性は，表の回りの境界フレームの見かけを制御し，rules属性は，表内のけい(罫)線の選択を決定する。レンダリングの注記によって，より細かなレベルの制御がサポートされる。style属性は，個々の要素に対するレンダリング情報を指定するために使用できる。文書ヘッドのSTYLE要素，又はリンクされたスタイルシートを介して，更なるレンダリング情報を入手できる。

この標準情報(TR)の原規定の開発中に，表のけい(罫)線パタンを指定するために，数多くの方法が検査された。作成できる文の種類に関連する問題もある。縁の加算と同様に，縁の減算に対するサポートを含めると，相対的に複雑なアルゴリズムとなる。例えば，表要素の全集合がframe属性及びrules属性を含むことができる場合の作業は，セルの特定の縁の線を引くことが望ましいかどうかを決定するために24の手順を含むアルゴリズムとなる。このように複雑度を増しても，表に関する要求すべてを満たすだけ十分なレンダリング制御は提供されない。現規定は，ほとんどの目的に十分な単純で直観的なモデルに意図的に執着している。より複雑なアプローチが標準化される前に，更に実験的な作業が必要である。

行集合及び列集合 

この標準情報(TR)は，HTML+に関する初期の作業で示されたより単純なモデルの上位集合を提供する。表は，1個のオプションの表題と行の並びとから構成されると考えられ，行は，表セルの並びから構成される。さらにこのモデルは，ヘッダ及びデータセルを区別し，セルが複数の行及び列にまたがることを可能にする。

CALS表モデル([CALS]参照)に従い，この標準情報(TR)では，表の行をヘッド部分，本体部分及びフット部分にグループ化することができる。これは，レンダリング情報の表現を簡便化し，ページ境界をまたぐ表を区切る場合に，表のヘッド行及びフット行を繰り返すために，又はスクロール可能な本体パネルの上部に固定ヘッダを提供するために使用できる。マーク付けでは，フット部分が本体部分の前に置かれる。これは，非常に長い表を処理するための，CALSと共有される最適化である。それによって，表全体が処理されるのを待たなくとも，フット部分をレンダリングすることができる。

アクセス可能性 

視覚障害者のために，HTMLは，図形的な利用者インタフェースに基づくウィンドウの採用によって発生する損害に対する権利の設定の可能性を提供する。HTML表モデルは，各セルをラベル付けするための属性を含み，音声変換のために高品質テキストをサポートする。データベース又は表計算処理への表データの自動インポート及び自動エクスポートをサポートするためにも，同じ属性を使用できる。

B.5.2 推奨するレイアウトアルゴリズム

COL要素又はCOLGROUP要素が存在する場合, それらは列の数を指定し，表は固定配置を使用してレンダリングしてもよい。存在しない場合は，後に示される自動レイアウトアルゴリズムを使用することが望ましい。

width属性が指定されない場合，視覚的利用者エージェントは，フォーマットに100%のデフォルト値を仮定することが望ましい。

セル内容が入りきらないとき，利用者エージェントは，表の幅をwidthによって指定された値以上に増加することを推奨する。利用者エージェントは，そうする理由がある場合にだけ，指定された幅を上書きすることが望ましい。利用者エージェントは，水平方向の過剰なスクロールの必要性を回避するために，又はそういったスクロールが実用的でないか若しくは望まれない場合に，行をまたいで語を分割してもよい。

レイアウトの目的では, 利用者エージェントは，CAPTION要素によって指定される表題がセルのように振る舞うと考えることが望ましい。各表題は，表の上又は下に位置する場合は表の列全体にまたがるセルであって，表の左側又は右側に位置する場合は，行全体にまたがるセルとなる。

固定レイアウトアルゴリズム 

このアルゴリズムでは，列の数は既知であると仮定される。デフォルトの列幅は，同一サイズに設定されることが望ましい。文書作成者は，COLGROUP要素又はCOL要素を使用して相対的列幅又は絶対的列幅を指定することによって，これを上書きしてもよい。デフォルトの表幅は，現在の左マージンと右マージンとの間の間隔であるが，TABLE要素上のwidth属性によって上書きされてもよいし，絶対的列幅から決定されてもよい。絶対的列幅及び相対的列幅を取り混ぜて処理するためには，最初に，表幅から絶対的幅をもつ列に間隔を割り当てる。この後，残りの間隔を相対的幅をもつ列の間で分割する。

表構文だけでは，属性値の整合性を保証するのに十分ではない。例えば，COL要素及びCOLGROUP要素の数は，表セルが暗黙に示す列数に整合しなくてもよい。列が狭すぎてセル内容が入りきらない場合には，更なる問題が発生する。TABLE要素又はCOL要素が指定するような表の幅では，セル内容が入りきらない場合もある。利用者エージェントが，語のハイフン処理を行う，ハイフン処理する箇所が未知の場合には語の分割を行うなどして，これらの状況からうまく回復しようと試みることを推奨する。

分割できない要素がセルのオーバフローを発生させる場合には，利用者エージェントは，列幅を調整し，表を再度レンダリングしてもよい。最悪，列幅調整及び/又はスクロール可能なセル内容が実行できない場合には，切り取りを検討してもい。いずれにせよ，セル内容が分割されるか，又は切り取られる場合には，適切な方法で利用者にこれを通知することが望ましい。

自動レイアウトアルゴリズム 

列数がCOL要素及びCOLGROUP要素で指定されない場合，利用者エージェントは，次の自動レイアウトアルゴリズムを使用することが望ましい。自動レイアウトアルゴリズムは，表データを用いた2パスの処理を行い，表のサイズを線形にスケール化する。

最初のパスでは，改行はできず，利用者エージェントは，各セルの最小幅及び最大幅を記憶する。最大幅は，最も幅の広い行によって与えられる。改行ができないので，BR要素によって区切られない場合には，長い行として段落を処理する。最小幅は，字下げ及び箇条記号などの導入を考慮して，最も幅の広いテキスト要素(語，画像など)によって与えられる。言い換えれば，セルがオーバフローを始める前に，それ自体のウィンドウでセルが要求する最小幅を決定する必要がある。利用者エージェントに語の分割を許すことによって，水平方向のスクロール，又は最悪の場合は，セル内容の切取り，の必要性を最小限にする。

この過程は，セル内容に出現するネストした表にも適用される。ネストした表の中のセルに対する最小幅及び最大幅は，これらの表に対する及び親表のセル自体に対する，最小幅及び最大幅を決定するために使用される。アルゴリズムは，セル内容の集合体に対して線形であって，大雑把に言えば，ネストの深さには依存しない。

セル内容の文字配置に対処するため，アルゴリズムは，各列に対して，配置文字の左，配置文字の右及び未配置という三つの実行時の最小及び/又は最大の合計を保持する。このとき，列の最小幅は，max(min_left + min_right, min_non-aligned)である。

最小セル幅及び最大セル幅は，列のための対応する最小幅及び最大幅を決定するために使用される。これらは，さらに表の最小幅及び最大幅を見つけるために使用される。セルはネストした表を含むことができるが，これはコードを極度には複雑にしないことに注意。利用可能な間隔，すなわち，現在の左マージンと右マージンとの間の間隔に従って，列幅を割り当てるのが，次の手順である。

複数の列にまたがるセルについて，簡単なアプローチは，最小幅及び/又は最大幅を構成列の各々に均等に割り当てることから構成される。それより若干複雑なアプローチは，またがらないセルの最小幅及び/又は最大幅を使用して，またがる幅の割当て方法を重み付けすることである。実験によって，これら二つのアプローチの混合すると，広範囲の表について良い結果がもたらされることが分かっている。

表枠線及び内部セルマージンは，列幅を割り当てる際に含まれる必要がある。次の三つの場合が存在する。

  1. 最小の表幅は，利用可能な間隔と同じか又はそれより大きい。この場合，最小幅を割り当て，利用者に水平方向のスクロールを可能にする。点字への変換に対しては，全内容を含む注記への参照で，セルを置換する必要がある。慣例によって，これらは表の前に出現する。
  2. 最大の表幅が，利用可能な間隔に収まる。この場合, 列を最大幅に設定する。
  3. 表の最大幅は利用可能な間隔より大きいが，最小の表幅は利用可能な間隔より小さい。この場合，利用可能な間隔と最小の表幅との差を見つけ，それをWと呼ぶ。同様に，表の最大幅と最小幅との差をDと呼ぶ。

    各列については，dをその列の最大幅と最小幅との差とする。列の幅を，dにWを掛けそれをDで割って最小幅に加算したものに設定する。これによって，最小幅と最大幅との差が大きい列が，その差がより小さい列より広くなる。

この割当てステップは，次に，ネストした表のすべてに対して，最初のパスでそれらの表のすべてに対して導出された最小幅及び最大幅を使用して，繰り返される。この場合，親表セルの幅は，先の記述での現ウィンドウサイズの役割を果たす。この過程は，ネストした表のすべてに対して，再帰的に繰り返される。最上位の表は，割り当てられる幅を使用してレンダリングされる。ネストした表は，親表のセル内容の一部として，引き続きレンダリングされる。

表幅がwidth属性を用いて指定される場合，利用者エージェントは，列幅が一致するように設定することを試みる。width属性は，列の幅が分割できない最小幅より小さくなる場合は，結合されない。

相対幅がCOL要素を用いて指定される場合には，アルゴリズムは変更され，列幅を最小幅以上に増加させ相対幅の制約を満たすようにする。COL要素は，ヒントとしてだけ扱うことが望ましい。そのため，列を最小幅よりも小さく設定しないことが望ましい。同様に，表がウィンドウの範囲を超える程に列を広くし過ぎないことが望ましい。COL要素がゼロの相対幅を指定する場合，列は常に最小幅に設定されることが望ましい。

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属性との衝突を避けるように選択されてきた。frame属性及びrules属性が，この標準情報(TR)の将来的な改訂版で，他の表要素に追加されることが期待されるため，これは将来の作業状況の検査の尺度を提供する。一つの代替手段は，frameをCDATA属性にすることである。SGML妥当性検査ツールを使用して，列挙される値に基づいた属性を検査できる利点は，整合の取れた名前の必要性に優るというのが，W3C HTML作業グループの合意である。

B.6 フォームに関する備考

B.6.1 増加的ディスプレイ

ネットワークから受信される文書の増加的ディスプレイは，フォームに関する問題をいくつか発生させる。利用者エージェントは，フォームの要素がすべて受信されるまで，フォームを実行依頼を禁止することが望ましい。

文書の増加的ディスプレイはタブナビゲーションに関する問題をいくつか発生させる。文書で最も低く評価される tabindexにフォーカスを提供する手動操作は，一見したところ十分理にかなっているように思われる。 しかし，これは，文書のテキストがすべて受信されるまで待機する必要があることを意味する。 これは，それまでは，最も低く評価される tabindexが変わり得るためである。 その前に利用者がタブキーをヒットする場合は，利用者エージェントが現在最低の利用可能な tabindexにフォーカスを移動するのは理にかなっている。

フォームがクライアント側スクリプトと関連づけられる場合，問題が発生する可能性はさらに大きくなる。 例えば，ある与えられたフィールドに対するスクリプトハンドラは，まだ存在しないフィールドを参照するかもしれない。

B.6.2 将来計画

この標準情報(TR)は，フォームを生成する一般的なニーズを満たすのに十分効果的な要素及び属性の集合を定義する。しかし，まだ十分改善できる余地がある。 例えば，次に示す問題は将来検討されうる。

別の拡張として考えられるのは，クライアント側画像マップとして使用するために，usemap属性を INPUTに追加することである。 この場合， "type=image"である。クリックされる位置に対応する AREA 要素は，サーバに渡される値を提供する。 サーバスクリプトの変更を回避するため， AREAを拡張して， INPUT 要素に対するx値及びy値を提供するのが適当であろう。

B.7 スクリプトに関する備考

B.7.1 将来的なスクリプトマクロのための予約済み構文

この標準情報(TR)は，HTML CDATA属性中のスクリプトマクロを将来的にサポートするための構文を予約している。 これは，ページの初めのほうに現われるオブジェクトの特性に依存するように属性を設定できることを意図したものである。 構文を次に示す。 

   attribute = "... &{ macro body }; ... "

スクリプトマクロの現状の実施 

マクロ本体は，組込みイベント属性により，デフォルトスクリプト言語による１個以上の文から構成される。 右中括弧後のセミコロンは常に必要である。そうでない場合は，右中括弧文字"}"はマクロ本体の一部として処理される。 引用符もスクリプトマクロを包含する属性に常に必要とされる点に注意すること。

CDATA属性の処理の進行順を次に示す。

  1. SGMLパーサは，"&gt;"などのあらゆるSGML実体を評価する。
  2. 次に，スクリプトマクロはスクリプトエンジンによって評価される。
  3. 最後に，結果である文字列が引き続く処理のためにアプリケーションに渡される。

マクロ処理は，文書がロードされるか又は再ロードされる場合に発生するが，文書のサイズが変更されたり，再描写されるなどの場合に，再度発生することはない。

推奨しない例:
ここでは，JavaScriptを使用する例をいくつか示す。最初の例は，文書の背景色をランダム化する。 

    
<BODY bgcolor='&{randomrbg};'>

夜らしくみせるために，背景を薄暗くしたい場合は次となる。 

    
<BODY bgcolor='&{if(Date.getHours > 18)...};'>

次の例は，JavaScriptを使用して，クライアント側画像マップのために座標を設定している。 

    
<MAP NAME=foo>
   <AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
 </MAP>

次の例は，文書特性に基づき画像のサイズを設定している。 

    
<IMG src="bar.gif" width='&{document.banner.width/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属性をどのように引用できるかを示している。属性ストリングに一重引用符を使用する場合は，属性ストリングの一部として二重引用符を包含できる。別のアプローチは，二重引用符に&quot;を使用することである。 

   
<IMG src="&{logo(manufacturer(&quot;widget&quot;))};" alt="logo">

B.8 フレームに関する備考

フレーム対象名が固有であるという保証はないため，与えられた対象名に対応するフレームを発見するための現在の習慣を述べておくのは適切である。

  1. 対象名が，標準テキストで記述されるような予約単語である場合，記述されたとおりそれを適用する。
  2. そうでない場合は, リンクを含むウィンドウのフレーム階層を深さ優先で検索する。名前が正確にマッチする最初のフレームを使用すること。
  3. そういったフレームが(2)で発見されなかった場合は，逆順で各ウィンドウに手順2を適用する。全く同じ名前を有するフレームに遭遇した場合はただちに中止する。
  4. そういったフレームが(3)で発見されなかった場合は，新しいウィンドウを生成して，それに対象名を割り当てる。

B.9 アクセス可能性に関する備考

備考　 次のアルゴリズムは，代替テキストを生成するためのものであるが，W3C ウェブアクセス可能性推進グループによる勧告によって廃棄される可能性がある。さらに情報を入手したい場合は， [WAIGUIDE]を参照のこと。

文書作成者が IMG要素又は APPLET要素に対してalt属性を設定しない場合，利用者エージェントは，代替テキストを提供し，次の順で計算される代替テキストを提供することが望ましい。

  1. titleが指定されている場合，その値が代替テキストとして使用されることが望ましい。
  2. そうでない場合は，包含オブジェクトが検索される際，HTTPヘッダがタイトル情報を提供する場合は， この情報が代替テキストとして使用されることが望ましい。
  3. そうでない場合は，GIF画像がいくつかのテキストフィールドを包含するなど，包含オブジェクトがテキストフィールドを含む場合は，テキストフィールドから抽出される情報が代替テキストとして使用されることが望ましい。利用者エージェントは，テキスト情報を抽出するために，最初に全オブジェクトを検索しなければならないため，内容交渉など，より経済的なアプローチを採用してよい。
  4. そうでない場合は，他の情報がなければ，利用者エージェントは拡張子を除いたファイル名を代替テキストとして使用することが望ましい。

文書作成者がINPUT要素に対してalt 属性を設定しない場合は，利用者エージェントは次の順で算出される代替テキストを提供することが望ましい。

  1. titleが指定されていた場合，その値が代替テキストとして使用されることが望ましい。
  2. そうでない場合は，nameが指定されていた場合，その値が代替テキストとして使用されることが望ましい。
  3. そうでない場合は，(実行依頼ボタン及びリセットボタン)，type属性の値が代替テキストとして使用されることが望ましい。

B.10 フォームのためのセキュリティ課題

アンカ，埋込み画像及びURIをパラメタとして含むその他すべての要素によって，URIは，利用者入力に応答して参照解除される。この場合，[RFC1738]の6のセキュリティ問題を考慮することが望ましい。フォーム要求を実行依頼するために広く配置されるメソッド，すなわち，HTTP及びSMTPは，機密性を保証しない。フォームを介して重要な情報を要求する情報提供者，特にINPUT要素, type="password"を用いる場合は，機密性が欠落していること知っていて，利用者にそれを知らせることが望ましい。

B.10.1 フォームに関するセキュリティ問題

利用者エージェントは，利用者が明示的に送信を要求しないファイルを送信しないことが望ましい。したがって，HTML利用者エージェントには，INPUT要素の value属性が示すデフォルトファイル名をすべて確認することを期待する。隠ぺいされる制御はファイルを指定しないことが望ましい。

この標準情報(TR)は，データ暗号化の機構を包含しない。すなわち，データの安全な伝送に代わる他の機構が存在する場合は，それが何であっても，これを処理することが望ましい。

ファイルが一度アップロードされたら，処理エージェントはそれを適正に処理し，格納することが望ましい。

前   次   目次   要素   属性   索引