附属書 B: パフォーマンス上、実装上、設計上の注意

目次

  1. 不正文書に関する注意
  2. URI属性値の特殊文字
    1. URI属性値の非ASCII文字
    2. URI属性値のアンパサンド記号
  3. SGML実装の注意
    1. 行区切り
    2. 非HTMLデータの指定
    3. サポート制限のあるSGML機能
    4. 論理型属性
    5. マーク区間
    6. 処理命令
    7. 省略化マーク付け
  4. 検索エンジンによるサイト索引づけを支援する場合の注意
    1. 検索ロボット
  5. 表に関する注意
    1. 設計原理
    2. 推奨するレイアウトアルゴリズム
  6. フォームに関する注意
    1. 逐次表示
    2. 将来的計画
  7. スクリプトに関する注意
    1. 将来的なスクリプトマクロのために予約されるシンタクス
  8. フレームに関する注意
  9. アクセス性に関する注意
  10. セキュリティに関する注意
    1. フォームにおけるセキュリティ問題

以下の諸注意は参考情報であり、規範ではない。しかし、本仕様の他の部分同様に、「must」「should」など、遵守要求の語が使用される。

B.1 不正文書に関する注意

本仕様書は、適合ユーザエージェントが一般的 エラー状態をどのように扱うべきかについて、本仕様が定義していない要素・属性・実体などに遭遇したケースの処理も含め、何らの規定も行わない。

しかし、様々なHTMLバージョンの実装間での実験及び相互運用性を促進するため、次の動作を推奨する。

これに加えて、ユーザエージェントがユーザに対しエラーを知らせる機能を提供するよう推奨する。

エラー条件をどのように処理するかはユーザエージェントにより様々なので、HTML文書の著者もユーザも、特定のエラー復元方法に依存してはいけない。

HTML 2.0 仕様書 ([RFC1866])は、HTML 2.0対応ユーザエージェントの多くが、文書型宣言が記されていないHTML文書をHTML 2.0適合文書と仮定して処理していると述べている。しかし経験的に明らかなように、そうした仮定による文書処理はうまく機能しない。そこで、このHTML 4.0仕様では、このような処理方法は推奨しない。

相互運用性を確保するため、HTML文書の著者は、利用可能なSGML機構を通じてDTDを拡張したり実体定義の追加セットを作るなどしてHTMLを「拡張」してはならない。

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

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

URIには非ASCII値が含まれない ([URI]の2.1を参照)とはいえ、HTML文書の著者が、URI属性値 (DTD中で%URI;と定義されている値)のつもりで非ASCIIの値を指定する場合があり得る。例えば、 次の href属性値は不正である。

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

こうした場合に非ASCII文字を扱うため、ユーザエージェントが次の規則に従うことを推奨する。

  1. 与えられた各文字を、UTF-8 ([RFC2279]参照)の1バイトあるいは複数バイトで表現する。
  2. URIのエスケープ機構により、このバイトをエスケープする。すなわち、各バイトをバイト値の十六進表現HHを用いて「%HH」で表す。

この変換規則に従うと、 [RFC1738]の2.2あるいは[RFC2141]の2が定めるシンタクス的に正当なURIが得られる。得られるURIは、HTML文書が符号変換され得る文字符号化方法に依存しない形式である。

注意。 古いユーザエージェントの中には、HTMLのURIを、当該文書の文字符号化方法をそのまま適用して処理するものもある。 また、古いHTML文書の中にはこうした処理方法に依存しているため、符号変換に際して破綻するようなものもある。 そうした古い文書を処理するユーザエージェントは、正当な文字集合の範囲にない文字を含むURIを受け取った場合、まず初めにUTF-8に基づく変換を試みねばならない。 そして変換結果が巧く扱えないものである場合のみ、当該文書の文字符号化方法のバイトに基づくURIの変換を試みるようにしなければならない。

注意。 UTF-8に基づく同様の変換は、A要素の name属性についても必要である。

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

フォームの送信によって生成されるURIは、A要素の href属性など、アンカー形式のリンクとして利用され得る。 ここで困ったことに、フォームの項目区切りに「&」記号を使おうとすると、SGMLの文字実体参照区切り子としての役割と衝突してしまう。 例えば、リンク用URIとして「http://host/?x=1&y=2」を使いたい場合、「<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要素に対しても例外なく適用される。

そこで次の2つのHTMLの例は、まったく同じようにレンダリングされる必要がある。

<P>トーマスはテレビを観ている。</P>
<P>
トーマスはテレビを観ている。
</P>

次の2例も同様である。

<A>お気に入りのWebサイト</A>
<A>
お気に入りのWebサイト
</A>

B.3.2 非HTMLデータの指定

スクリプトデータやスタイルデータは、要素の内容にも属性値にも出現し得る。 この節では、HTMLのマーク付けとHTMLでないデータとの境界部分について記述する。

注意DTDは、スクリプトデータとスタイルデータを、要素の内容としても属性値としても共にCDATAとして定義している。 SGMLの規定では、CDATA形式の要素内容には文字参照が許容されないが、CDATA形式の属性値では許容されるので注意されたい。 要素内容と属性値のスクリプトデータやスタイルデータをカット&ペーストする場合、著者には細心の注意が必要となる。

要素内容と属性値におけるこの非対称性については、能力の大きな文字符号化方法から小さい文字符号化方法へと符号変換する際にも注意が必要となる。符号変換を行う場合、スタイルデータやスクリプトデータの中の変換不能な文字を数値文字参照に置換えればいいとは限らない。データを正しく処理するためには、符号変換に際してHTML文書をパースし、スクリプト言語及びスタイル言語のシンタクスをも理解する必要がある。

要素内容 

スクリプトデータやスタイルデータが要素の内容である場合 (SCRIPT要素かSTYLE要素)、 データは当該要素の開始タグの直後から始まり、最初のETAGO【終了タグ開始区切り子】「</」に続けて名前開始文字([a-zA-Z])があるところで終わる。末尾と判断される組み合わせ【ETAGOと名前開始文字】が当該要素の終了タグではない場合があり得ることに注意されたい。 従って著者は、「</」を各スクリプト言語あるいはスタイルシート言語固有のエスケープ機構によってエスケープすべきである。

不正な例:
次のスクリプトデータは、「</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属性または組込みイベント属性)、 著者は、当該スクリプト言語あるいはスタイル言語の規定に沿って単引用符や二重引用符がデータ内容とならないようエスケープすべきである。 同様に、文字参照の開始以外の「&」もエスケープしなければならない。

従って、次のように記すこととなる。

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

B.3.3 サポート制限のあるSGML機能

[ISO8879] に適合するSGML処理系は、HTMLユーザエージェントが広くサポートしていないような多くの機能を利用できると考えられる。本仕様は、HTML文書の著者がそうした機能の全てについて利用を避けるよう勧告する。

B.3.4 論理型属性

HTML文書の著者は、多くのユーザエージェントが論理型属性の最小書式しか認識せず完全書式を理解しないという点を知っておくべきである。

つまり、次のような指定では、

<OPTION selected>

上の代わりに下のようには記さない方がよい

<OPTION selected="selected">

B.3.5 マーク区間

マーク区間は、C言語のプリプロセッサにおける「#ifdef」構造と同様の役割を果たす。

<![INCLUDE[
 <!-- これは含まれる -->
]]>

<![IGNORE[
 <!-- これは無視される -->
]]>

SGMLでは、内容をCDATAとするマーク区間の用法も定められており、そこでは「<」はタグの開始記号としての扱いを受けない。

<![CDATA[
 <この> 例が示す <sgml> のマーク付けでは
 このように < とかを記述しても <問題が> ない。
]]>

あるユーザエージェントがマーク区間を認識していないという証拠は、「]]>」が出現することによって示される。つまり、最初の「>」記号は「<![」で始まるタグの末尾だとユーザエージェントが誤認した場合に、「]]>」が見えてしまうわけである。

B.3.6 処理命令

処理命令は、プラットフォーム依存の文書処理を示す機能である。処理命令は「<?」で始まり、「>」で終わる。

<?instruction >

処理命令の例を示す。

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

HTML文書の著者は、多くのユーザエージェントが処理命令を文書中のテキストの一部としてレンダリングすることを知っておくべきである。

B.3.7 省略化マーク付け

SGMLのSHORTTAG(短縮タグ)機構は、タイピングの繁雑さを軽減するかもしれないが、SGMLアプリケーションに対して大きな能力を加えるものではない。 技術的には何の両義性も伴わないが、新しい要素を含むよう言語の拡張を行う場合等には特に文書の堅固性を減少させる。 そこで、属性に関するSGMLの短縮タグ機構は広く利用されまた実装されているが、要素についてはそうではない。この機構を利用する文書は適合SGML文書ではあるが、現存する多くのHTMLツールで作動するとは考えにくい。

問題となる【要素の】短縮タグ機構を例示する。

B.4 検索エンジンによるサイト索引づけを支援する場合の注意

この節では、HTML文書を検索エンジンにとってアクセスしやすいものとするための、簡単な提案を行う。

何語で書いたかを指定する
地球規模のWebという観点から、当該ページが何語で書かれているかを知ることは重要である。 この点については言語情報の項で記す。
別言語版の所在を指定する
この文書を翻訳しようとする場合、 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要素を探すような検索エンジンもある。 この検索エンジンは、検索結果としてこれらのキーワードを示し得る。ただし検索エンジンが検索する【META要素の】 name属性の値が何であるかは本仕様書の定義の範囲外である。 次の事例を考慮されたい。
<META name="keywords" content="vacation,Greece,sunshine">
<META name="description" content="Idyllic European vacations">
文書群中の開始ページを示す
ワープロ文書やプレゼン資料を集めて複数のHTML文書にするということは、よくあることである。 検索の結果ヒットしたページに、当該文書群の開始ページへの参照が示されると便利である。 検索エンジンを支援するには、 LINK要素の属性・値rel="start"及び title属性を併用し、次のように記す。
 
<LINK rel="start" 
         type="text/html"
         href="page1.html" 
         title="一般相対性理論">
ロボットに対して索引づけの指示を行う
検索エンジンによって自分のサイトが索引づけられていることを知って驚く場合や、公開したくない部分については巡回対象としていないことを知って驚く場合もあるだろう。 多くの検索ロボットは、Webサイトの管理者やコンテンツの提供者に対し、ロボットの作業を制限する機構を用意している。 この制限は、「robots.txt」というファイルとHTML文書の META要素という2つの機構によって可能となる。詳細は次節の通り。

B.4.1 検索ロボット

robots.txtファイル 

検索ロボットは、「http://www.foobar.com/」といったWebサイトを巡回する際、まず初めに「http://www.foobar.com/robots.txt」の有無を確認する。 もしこのrobots.txt文書があった場合、この内容を解析し、【当該サイトの】文書が検索可能かどうかを調べる。 robots.txtの内容をカスタム化し、特定ロボットのみに適用させたり、特定ディレクトリや特定ファイルへのアクセスを不許可にしたりすることもできる。

当該サイト全体からすべてのロボットを排除するrobots.txtファイルの例を掲げる。

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

ロボットは単純に、サイトにある「/robots.txt」を探す。ここで言うサイトとは、あるホスト及びポート番号で稼動している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

1つのサイトには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は、すべて巡回されない。例を示す。

    Disallow: /help という指定の場合、
        「/help.html」と「/help/index.html」の双方が巡回されない。一方、
    Disallow: /help/ の場合、
        「/help/index.html」は不許可だが「/help.html」は許可される。 

値が空の「Disallow」は、全てのURIが巡回可能であることを示す。robots.txtファイルには、最低1つの「Disallow」フィールドが存在しなければならない。

ロボットとMETA要素 

META要素によってHTML著者は、ロボットに対し、当該文書を索引づけてよいかどうかや、リンク部分を更に辿っていっていいかどうか等を知らせることができる。サーバ管理者の作業は不要である。

次の例では、ロボットは当該文書の索引づけも、リンク内容の解析も許されていない。

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

content属性の値となる語は、 ALLINDEX NOFOLLOWNOINDEXである。

注意。1997年初頭の段階では、META要素による制限を実装しているロボットはわずかであった。しかし検索ロボットの制御に関するより公然たる注意が払われるようになれば、この状況は変わっていくと期待できる。

B.5 表に関する注意

B.5.1 設計原理

HTMLの表モデルは、既存のSGML表モデルや、一般的ワープロソフトによる表の扱い、雑誌・書籍その他の印刷物で見られる多様なテーブル的レイアウト技術、等の研究を元に開発された。 そして、単純な表を簡単に表現できてかつ必要に応じて複雑な表現が可能なモデルを選択した。 これにより、日常用のテキストエディタでHTMLの表をマーク付けすることが実際的に可能となり、また初学者にとっての学習曲線を下げることもできた。この点は今日のHTMLの成功にとって非常に重要な点である。

他の文書フォーマットからの変換によって表を作成したり、WYSIWYGエディタを用いて直接表を生成するような人も増えている。こうしたオーサリングツールにうまく適合することも、HTMLの表モデルにとっては重要である。 この点は、複数の行や列をまたぐセルをどのように表現するかといったことや、配置を揃えること等のプレゼンテーション特性をセルのグループとどのように関連づけるかといったことに関連する。

動的再フォーマット 

HTMLの表モデルにとって重要な問題は、ユーザ側がこの表をどのような大きさで表示するか、どのフォントを用いるかといったことを制御しない点である。 そこで、絶対ピクセル単位による列幅指定にはリスクが伴うこととなる。表は、固定サイズではなく、現在のウインドウサイズやフォントに合致するよう動的に大きさが変更できるようでなければならない。 HTML著者は列幅の相対的な大きさの指針を指定できるが、ユーザエージェントはセル内容のうち最も大きい要素をレンダリングするのに十分な列幅を確保するべきである。 ただし著者の指定を上書きする必要が生じた場合、個々の列幅の相対的な関係は、大幅には変えないようにすべきである。

逐次表示 

巨大な表や、低速回線で接続している場合、逐次的に表を表示することによってユーザを満足させられる。ユーザエージェントは、表データの全体が届くより先に表示を開始できるようにすべきである。 ほとんどのユーザエージェントのデフォルトのウインドウ幅は【半角】80文字であり、また多くのHTMLページの画像はこのデフォルト幅を念頭において描かれている。 HTML著者は、列数を指定し、表全体の幅及び他と異なる列の幅を指定することで、ユーザエージェントが逐次表示を行なう際のヒントを提供することができる。

逐次表示を行なうために、「ブラウザ」は列の数と幅とを知る必要がある。表全体のデフォルトの幅は現在のウインドウの大きさである (width="100%")。 この大きさは、 TABLE要素の width属性の指定で変更できる。 デフォルトではすべての列幅が等しいが、表データに先立つ COL要素によって、列幅の指定を行なうこともできる。

残る問題は列数だ。第一行のデータを受け取ってから数えればいいという意見もあるが、セルが多くの内容を含んでいる場合は長い時間がかかる。 大局的に見て、逐次表示が望ましい場合、HTML著者がTABLE要素で列数を明示しておく方が合理的である。

HTML著者は更にまた、ユーザエージェントに対して逐次表示を用いるかセル内容に応じた自動的サイズ調整を行なうべきかを知らせる手段を必要とする。 二段構えで表示することとなる自動サイズ調整モードの場合、列数は第一段階で確認される。逐次表示モードの場合、列数はまず初めに COL要素あるいは COLGROUP要素で提示される必要がある。

構造とプレゼンテーション 

HTMLでは、段落分けや引用など構造に関するマーク付けと、マージン、フォント、色指定などレンダリングに関するマーク付けが、明解に区別される。この区別は表に対してどんな影響を及ぼすだろうか。 非常に厳密に言うと、セル内のテキスト配置やセル間の枠線等はレンダリングに関する問題であって、構造の問題ではない。しかし実際的には、こうした機構はあるアプリケーションから別のアプリケーションへの移植性が高いため、構造情報と一緒にグループ化してしまうと便利である。 HTMLの表モデルは、レンダリング情報の大半を関連するスタイルシートへと委ねている。本仕様が提示するモデルは、スタイルシートの利点を活かしはするが、スタイルシートを必須とはしない。

現在のDTPパッケージでは表のレンダリングについて非常に高度な制御を行えるが、それをHTMLで再現しようというのは実際的ではない。これを再現するには、HTML仕様をRTFやMIFのように巨大な仕様へと書き換える必要が生じてしまう。 そうではなく、本仕様は、枠線スタイルとして一般的に使用されるクラス集合から著者が選択できるようにした。 frame属性は表全体の外枠の見かけを制御し、 rules属性は表内部の罫線として選んだものを指定する。 更に細かい表現は、レンダリングの注釈によってサポートされる。 個々の要素についてstyle属性でレンダリング情報を指定でき、またより多くのレンダリング情報を、文書のHEAD要素にある STYLE要素あるいはリンクしたスタイルシートによって得ることができる。

本仕様の開発に際して、表の枠・罫線出現パターンの様々な方法を検査した。1つの問題は、作られ得る記述方法の種類に関するものである。縁取りの削除や追加をサポートすると、そのアルゴリズムは相対的に複雑化する。 例えば、表を構成する全要素にframe属性とrules属性が許容されるとすると、あるセルの一辺について罫線を引くか引かないかを決定するために、24段階の手順を踏むアルゴリズムが必要となる。 これほどの複雑さをもってしても、表に対するあらゆるニーズを満たすのに十分なレンダリングの制御は行えない。 そこで本仕様では敢えて、ほとんどの目的に十分であり、かつ単純で分かりやすいモデルを採用するに留めることとした。より複雑なアプローチを標準化するまでには、さらに多くの実験的作業が必要である。

行グループと列グループ 

本仕様は、HTML+に関する初期の作業で示された単純な表モデルの上位モデルを提供する。ここでは表を、任意選択のキャプションと、連続するセルが成す行の連なりとから構成されるものと考える。さらにこのモデルでは見出しセルとデータセルを区別し、またセルが他の行や列をまたぐことを許容する。

CALSの表モデル([CALS]参照)に準じ、本仕様では、表の各行をヘッダ・本体・フッタにグループ化できるようにした。これによりレンダリング情報の表現は簡素化され、ページ境界をまたぐような表でヘッダとフッタの繰り返しが可能となり、また本体をスクロールする際にもヘッダを固定的に表示することもできる。 マーク付けでは、フッタは本体の前に位置する。これはCALSと共通する、非常に巨大な表を扱う場合の最適化手法である。こうすることで、表全体の処理を待たずにフッタをレンダリングできる。

アクセス性 

視覚障害者のために、HTMLは、ウインドウシステムに基づくグラフィカルなユーザインターフェイスのみに適合してしまうことから引き起こされるアクセス障壁をなくせるような仕組みを設けた。 HTMLの表モデルは各セルをラベルづけするための属性を含み、音声出力に変換するための高品質なテキストをサポートしている。このラベルづけ属性は、表データをデータベースや表計算シートとの間で自動的にやりとりする際にも利用できる。

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

もしCOL要素かCOLGROUP要素が存在するなら、列数が指定されていることになるので、表を固定レイアウトでレンダリングしてよい。両要素が存在しない場合は、下で述べる自動レイアウトアルゴリズムを用いねばならない。

もしwidth属性が指定されていない場合、視覚系ユーザエージェントはデフォルト値の100%を仮定してフォーマットせよ。

仮にwidth指定を超えて表の幅を増やさないとセル内容がはみだしてしまう場合、ユーザエージェントは表の幅を増やすよう勧められる。この状況でユーザエージェントが指定された幅を上書きするのは合理的である。 またユーザエージェントは、過大な横スクロールを避ける必要があったり、過大な横スクロールが実用的でないか望ましくないような場合は、行をまたいで単語の分割を行なってよい。

レイアウトの観点では、ユーザエージェントは CAPTION要素が指定する表のキャプションを、1つのセルであると考える必要がある。表の上側または下側に位置するキャプションは列全体にまたがる1つのセルであり、表の左側または右側に位置するキャプションは行全体にまたがるセルである。

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

このアルゴリズムでは、列数が既知であると仮定される。デフォルトでは、各列の幅は均等である必要がある。HTML著者は、 COLGROUP要素や COL要素で相対的あるいは絶対的な列幅を指定してデフォルト値を上書きできる。 デフォルトの表幅は現在の左マージンから右マージンの間の空間となるが、表幅は TABLE要素のwidth属性によって上書きされ得るし、絶対指定の列幅によって決定される場合もある。 列幅の絶対指定と相対指定が組み合わされている場合は、まず表全体の幅から絶対指定による列幅を確保し、次に残りを相対指定の値によって割り振る。

属性値の一貫性を保証するには、表のシンタクスだけでは不十分である。例えば、 COL要素及びCOLGROUP要素の個数は、表のセル数が暗示する列数と一致しないことがあり得る。 列幅が狭すぎてセル内容が収まり切らない場合、より大きな問題が起きる。TABLE要素が指定する表幅か COL要素の指定が、セル内容が溢れる原因となり得る。 セル内容が溢れる場合、ユーザエージェントは、単語をハイフネーションするか、ハイフネーションの位置が不明なら適宜分割する等して、セル溢れを見苦しくないよう回避することが推奨される。

分割不能な要素がセル溢れを引き起こした場合、ユーザエージェントは、列幅を調整して表の再レンダリングを行なうことを考慮してよい。列幅調整かつ/またはスクロール表示が不可能であるような最悪の場合には、セル内容の切り捨ても考えざるをえない。 何にせよ、セル内容の分割や切り捨てを行なう場合は、その旨をユーザに適宜示す必要がある。

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

表の列数が COL要素でもCOLGROUP要素でも指定されていない場合、ユーザエージェントはここで述べる自動レイアウトアルゴリズムを用いる必要がある。このアルゴリズムでは表のデータを二段階に渡って処理し、段階的に表の大きさを計る。

第一段階では、ユーザエージェントは、行の折り返しを行なわず各セルの最小幅と最大幅を検出する。最大幅は、最大行によって求める。行を折り返さないため、段落は、BRによる区切りがない限り1つの長い行として扱われる。 最小幅は、冒頭のインデントやリスト項目印なども勘案した上で最大のテキスト要素(単語や画像など)によって求める。言い換えると、セル溢れが生じる直前のところで、当該ウインドウにおいてセルが要求する最小幅を決定する必要がある。 ユーザエージェントによる単語の分割を許容することで、横スクロールの必要性を最小限にし、また最悪のケースにおけるセル内容の切り捨てをも最小限にできる。

列幅決定アルゴリズムは、セル内容になっている入れ子の表にも適用される。子である表の最小・最大幅は、その表自身の幅に反映されると共に、親である表のセル幅にも影響する。 このアルゴリズムはセル内容総体に対して一律に働き、また概して入れ子の深さには無関係である。

セル内容の文字配置に対処するため、列幅決定アルゴリズムでは各列について次の3つの最大・最小値をも検出する必要がある。まず桁揃え文字の左側、次に桁揃え文字の右側、そして桁揃えしないもの――の最大・最小値である。 こうして得られる最小列幅は、 max(min_left + min_right, min_non-aligned)【桁揃え左側最小値と桁揃え右側最小値の合計か、桁揃えに関係のない部分の最小値の、どちらか大きい方】である。

こうして得られる最小・最大セル幅は、その含まれる列の最小・最大幅決定の根拠になる。そして決定された列幅は、表の最小・最大幅を求めるために用いる。 セルは入れ子の表を含み得るがコードが大幅に複雑化するものではない点に注意されたい。 【以上が第一段階で、】第二段階の手順は、利用可能な空間、すなわち現在の左マージンと右マージンの間の空間に、列幅を割り当てていくものである。

複数列をまたぐセルの場合、単純な手法は、またぐセルの各々に対して最小・最大幅を均等に割り振ることである。多少複雑な手法は、またがないセルの最小・最大幅を用いて、またぐ幅をどの程度にすれば妥当かを重みづけする方法である。 実験により、2つの手法を混合することによって、多様な表において良い結果が得られると判っている。

表の枠線とセル間マージンについても、列幅決定に際して考慮に入れる必要がある。次の3パターンがあろう。

  1. 表の最小幅が、利用可能空間より大きいかまたは等しい。 この場合、最小幅を割り当て、ユーザの横スクロールを可能にする。点字出力への変換においては、セル内容を、当該セル内容全体を含む注記への参照に置き換える必要がある。慣習的に、注釈は表より前に出現する。
  2. 表の最大幅が、利用可能空間に収まる。 この場合、各列を最大幅に設定する。
  3. 表の最大幅は利用可能空間より大きいが、最小幅は利用可能空間より小さい。 この場合、利用可能空間と表の最小幅との差を計算し、それをWとする。更に利用可能空間と最大幅との差をDとする。

    また各列における最大幅と最小幅の差をdとする。そして、各列の最小幅に (d×W)÷D の値を加えて、求める列幅とする。この計算で広がる列幅は、最小・最大の差が大きい列ほど大きくなり、差が小さい列ほど小さくなる。

この計算過程は、入れ子の表においても、親世代の計算で得られた子世代の表が占有可能な最小・最大幅に基づいて、繰り返される。 この場合、親である表のセルが、上記の説明における現在のウインドウサイズに該当する役割を果たす。 この過程は入れ子の全世代にわたって循環的に繰り返される。 入れ子の表では、まず最上位の表が計算結果が示す幅を用いてレンダリングされる。続いて子世代の表が、親である表のセル内容の一部としてレンダリングされていく。

表の幅がwidth属性によって指定されている場合、ユーザエージェントはこれに合致するよう列幅を調節しようと試みる。 しかし列幅の最小値の合計よりも小さい値(すなわち表示不能な値)が指定されている場合には、 width属性の指定による拘束を受けない。

列幅が COL要素で相対指定されていた場合のアルゴリズムは、最小の列幅から増やしていって指定の相対比率に近づけるというものになる。 COL要素はヒントとしてのみ受け取るべきであり、列幅は最小幅より小さくなってはいけない。同様に、表がウインドウの範囲を超えてしまうほど列幅を拡げてもいけない。 なお、 COL要素が相対サイズをゼロと指定している場合は、当該列は常に最小幅に設定されねばならない。

二段構えのレイアウトアルゴリズムを用いる際、明示または継承された charoff属性が存在しない場合のデフォルトの配置は、align="char"である列については、各行における桁揃え文字の左右各々の最大値が均等になる、中心線を基準に決定できる。 逐次表示に関する暗示的デフォルトはcharoff="50%"である。 同じ列で異なる行にある複数のセルが桁揃え文字を用いている場合、デフォルトにより、桁揃え文字が何であるかによらず当該セルを揃えてしまう必要がある。 これら明示的暗示的配置の結果、列幅からの溢れ処理が必要となるような大きすぎるモノを扱う場合、溢れ処理ルールが適用される。

属性名の選択frame属性の値を、rules属性の値と配置に用いる値とに一致するよう選択することが、望ましいと考えられるだろう。具体的には、 nonetopbottomtopbotleftrightleftrightallである。 ところが残念なことに、SGML規定は列挙する属性値について、属性名が何であっても各要素において一意であることを要求しているので、「none」「left」「right」「all」に関して即座に問題が生じる。 そのため、本仕様は frame属性の値について、 rules属性、align属性、及び valign属性との衝突を避ける形で選択した。 この選択は、本仕様の将来的な改訂に際して表の他の要素にframe属性と rules属性が追加される場合に起き得る将来の衝突を避ける基準ともなっている。 この代替案は、 frame属性をCDATA形式の属性とすることであった。 W3CのHTML作業グループが達した合意は、列挙された値に基づいてSGML検証ツールで検証できる利益が、名前の一致による利益に勝るというものである。

B.6 フォームに関する注意

B.6.1 逐次表示

ネットワークから受信しつつある文書を逐次表示することで、フォームに関連する問題が発生する。ユーザエージェントは、当該フォームの要素がすべて受信されてしまうまでは、ユーザがフォームをサブミットできないようにする必要がある。

文書の逐次表示は、タブナビゲーションについても少々問題を生み出す。【到着している分の】文書中で最低位な値の tabindexにフォーカスを合わせるという帰納法は、一見すると十分理にかなっていると思える。しかしこれは、【続けて届く部分によって】最低位の tabindexが変わり得るため、文書のテキスト全体が届くまで待ち続けねばならないことを意味する。 全文到着以前にユーザがタブキーを叩いた場合には、当該時点で最低位であるtabindexにユーザエージェントがフォーカスを移動するのは合理的である。

クライアント側スクリプトと関連づけられているフォームでは、問題発生可能性は更に増大する。例えば、あるフィールドのスクリプトハンドラが、まだ届いていないフィールドを参照している状態などがあり得る。

B.6.2 将来的計画

本仕様は、フォーム作成に関する一般的な要求を満たすのに十分な能力を持つだけの要素と属性の集合を定義する。とはいえまだ幾つも改善の余地がある。例えば、次の点が将来の改善点として示されよう。

他の拡張としてあり得るのは、"type=image"であるINPUT要素をクライアント側イメージマップとして機能させられるよう、 usemap属性を追加することである。 クリック位置に対応する AREA要素が、値をサーバに渡す。 サーバ側スクリプトを変更する必要を生じさせないために、 INPUT要素との併用に際してx・y座標を提供できるよう、 AREAを拡張するのが適切であろう。

B.7 スクリプトに関する注意

B.7.1 将来的なスクリプトマクロのために予約されるシンタクス

本仕様は、HTMLのCDATA属性のスクリプトマクロを将来的にサポートするためのシンタクスを予約する。これは、ページの初めの方に出現するオブジェクトのプロパティに依存する形で属性の設定を許すことを意図している。シンタクスは次の通り。

   attribute = "... &{ マクロ本体 }; ... "

現在のスクリプトマクロの扱い 

マクロ本体は、組込みイベント属性毎に、デフォルトのスクリプト言語で記述した1つ以上の行から成る。閉じ中括弧(})に続くセミコロンは常に必要であり、セミコロンが付随しない閉じ中括弧はマクロ本体の一部として扱われる。スクリプトマクロを含む属性の値は常に引用符で囲う必要がある点にも注意されたい。

CDATA属性の処理手順は次の通り。

  1. SGMLパーサが、「&gt;」等のあらゆるSGML実体を処理する。
  2. 次にスクリプトエンジンがスクリプトマクロを評価する。
  3. この結果得られた文字列が、最後に、次の処理を行うアプリケーションに渡される。

マクロ処理は、文書の読込み(あるいは再読込み)時点で行われるが、文書サイズの変更や再描画などの時点では行われない。

推奨しない例:
JavaScriptを用いた例を幾つか示す。最初の例は、文書の背景色をランダムに変更する。

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

夜に読まれる場合に背景を暗くしたい場合もあろう。

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

次の例ではJavaScriptをクライアント側イメージマップのcoords属性設定用に用いている。

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

今度の例では、documentプロパティに合わせて画像のサイズを設定している。

    
<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属性では単引用符または二重引用符でどのように値を囲えるかについて示す。属性文字列を単引用符で囲った場合は二重引用符を属性文字列に含めることができる。属性文字列に二重引用符を用いるもう1つの手法は、&quot;を二重引用符として使用することである。

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

B.8 フレームに関する注意

目標フレーム名が一意であるという保証がないため、与えられた目標名のフレームを探し出すために現在使われている手法を参考に記しておく。

  1. 目標名が、規範文書が規定する予約語の場合、定義通りに適用する。
  2. 予約名以外の場合、当該リンクを含むウインドウにおいてフレーム階層の深さを優先して検索する。名前が正確に合致する最初のフレームを用いる。
  3. 前段階で合致するフレームが発見されなかった場合、各ウインドウの前面から背面に向けて名前合致検索を行う。完全一致する名前に遭遇した時点で、即座に検索を終了する。
  4. それでも該当するフレームが無かった場合、新しいウインドウを開いてこれに目標フレーム名を割り当てる。

B.9 アクセス性に関する注意

ここで述べる代替テキスト生成アルゴリズムは、W3CのWebアクセス性イニシアチブグループ[WAI])が制作している、障害者のWebアクセス性向上のためのガイドライン文書群に従う。 現在3つのガイドライン群がある。

B.10 セキュリティに関する注意

アンカー、埋込み画像、その他パラメータURIsを含むすべての要素は、ユーザの入力によってURIの逆参照が為され得る。この場合、 [RFC1738]の6にあるセキュリティ問題を考慮する必要がある。 フォームをサブミットする要求に広く用いられる手法――HTTPとSMTP――は、機密保持に関してほとんど何の保証もしない。 重要な情報を扱うフォーム、特にtype="password"のINPUT要素を扱う場合、コンテンツ提供者は、機密性が保たれないことと、利用者に向けて機密性の問題へ注意を喚起することとに留意する必要がある。

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

ユーザエージェントは、ユーザが明示的に送信を求めたファイル以外のものは送ってはいけない。 HTMLユーザエージェントは、 INPUT要素のvalue属性が示すと考えられるすべてのデフォルトファイル名に適合することが求められる。また隠しコントロールはファイルを指定してはならない。

本仕様は、データの暗号化に関するメカニズムを含まない。安全なデータ伝送に用いる他のあらゆるメカニズムが存在する場合、これを処理する必要がある。

いったんアップロードされたファイルは、処理エージェントがこれを適切に処理・格納する必要がある。


訳者代表: 内田明 (UCHIDA Akira)
email: uchida@happy.email.ne.jp