サイトの構築においてなくてはならない・欠かすことの出来ないのがナビゲーションです。ナビゲーションは文書同士を有機的につなぐリンク（通常はa要素）によって構成・提供されます。ただし、最近ではサイドバーを有用する UA も増えています。将来的には文書のヘッダ内に指定されている link要素によって構成・提供されている情報を有用に機能させることができる UA が登場し、新しいナビゲーションのベースとなりえるかもしれません。もちろん現状でも、Opera をはじめとした、link要素で提供されるリンクに対応している UA はありますが、ただ並べただけの並列的な関係しか示せなかったり実用的なものではありません。
つまり、現状ではウェブサイトの制作者は、ナビゲーションをユーザーに提供するにあたっては、本文、つまりは body要素内にナビゲーション部のリンクを含めて提供する、もしくは frame要素（フレーム）によって本文とナビゲーションを分離して提供する必要があります。そして、どういった形でナビゲーションを提供するかは、ウェブサイトの制作者にその一切が委ねられることになります。しかし、フレームでナビゲーションを提供している制作者の多くは、フレームの抱える問題点を解決できないまま、もしくはその問題点を知らずにフレームを利用していることが多いようです。そこで、本文書ではフレームでナビゲーションを提供する場合の最適化について考えたいと思います。
ひとつのページの表示域を分割してページを表示するフレームを使うことでナビゲーションと本文を分離させ、部分的にユーザビリティを強化してくれます。現状では、フレームによって提供されているナビゲーションほどリンクの利便性を有効に発揮できる最短のナビゲート方法はないと言えます。それだけでなく制作者側からしてもナビゲーションを1つのファイルで共有することができるのでメンテンスが容易におこなえ、更新は最低限の労力で済みます。そう思うとフレームとはユーザーにとっても便利で、制作者側も楽ができるものと思われるかもしれませんが、ナビゲーションの提供にフレームを採用するとなるとユーザー側とウェブサイトの管理・運営側の双方においても以下のような問題点を抱えてしまうことがあります。
frameset要素）の URI しか表示されないため各フレームページの URI の取得が困難になる。まずは、ユーザー視点の欠点から詳しくみていきましょう。
"ユーザーの環境（UA）がフレームに対応していない場合がある"というのは、主要視覚ウェブブラウザで言えば、Netscape Navigator 2.0, Internet Explorer 3.0 のバージョンよりフレーム機能に対応したので、それ以前の Netscape Navigator 1.x系列と Internet Explorer 1, 2 のバージョンが該当します。ただし、今となっては、そんな化石のような古いブラウザを利用しているユーザーは皆無であると考えることができるでしょう。しかし、携帯用機器などでは画面の大きさに制限があるためフレームの機能を一切サポートしていません。そして、そもそもフレーム関係の機能は1996年にリリースされた Netscape Navigater 2.0 が独自拡張で搭載していた機能を規格として取り入れたものであるため、HTML 本来のマークアップではありません。そのため W3C の仕様では、フレームは HTML4.01フレーム設定型DTD と XHTML1.0フレーム設定型DTD にしか定義されていません。そして音声出力や点字出力の非視覚環境は、フレームを使用したページの内容を把握するのが困難であるためフレームを使用したページを苦手とします。
"ひとつの画面に複数の文書を表示しているため印刷が困難な場合がある"というのは、比較的新しいウェブブラウザではオプションでページを指定して印刷できますが、たとえオプションがあっても、その方法を知らない場合など、ユーザーはかなり混乱することになります。またフレームページが一枚に収まらない場合、適切に印刷できないことがあります。この際に制作者側が CSS2 の仕様より定義されたメディアタイプ（"@media screen"）を使用することで、ある程度まではカバーすることができるでしょう。
"フレームを使用していると URI の取得が困難になる"というのは、閲覧するフレーム内のページを切り替えてもユーザーのブラウザのアドレス欄には、フレームの基となるフレーム設定文書の URI しか表示されないためです。その結果、各ページの URI が取得できない（取得が困難になる）ためリンクしにくい・されにくいということが言えます。これでは苦労して制作した努力も報われなければ、せっかく WWW上に公開されている各文書もその情報発信力を最大限に活かすことができません。
次に管理・運営者視点の欠点は、主に SEO に関するものです。
検索エンジンは各ページを巡回し、サイト内の情報を収集します。問題が起こるのは検索エンジンのロボットがフレーム内のページであろうとひとつのページとして認識することです。検索エンジンのロボットのようなプログラムでは、それがフレーム内のページであるのか、そしてそのフレームの構成がどのようになっているのかということまでは正しく認識することができません。
その結果、検索エンジンの検索結果でナビゲショーンが不完全なフレーム内のページへユーザーが訪問してきた場合、ユーザーはそのページから身動きができなくなってしまいます。つまり、せっかくの訪問者を見逃してしまうことになる可能性もあるのです。なおさら検索エンジンのプログラムは被リンクを重視するといわれているため、せっかくのリンクがひとつのメニューページにだけ統一されていては、リンクポピュラリティの向上にもつながりません。ユーザーも URI の取得が困難なため他力での被リンク獲得の機会をも失ってしまっているかもしれません。
ここまで、ユーザーと管理・運営者視点からフレームの欠点を見てきましたが、一方的に悪い面だけを見てフレームでナビゲショーンを提供する方法はダメだと考えるのは早計です。フレームのメリットを享受しながらもフレームの欠点を改善する方法を考えてみましょう。フレームでナビゲーションを提供するかどうかは、制作者の判断に委ねられるわけです。先ほど制作者にとってフレームとは、ナビゲーションをひとつのファイルで共有することができるのでメンテンスが容易におこなえ最低限の労力で済む楽な方法だと言いましたが、これを訂正します。フレームのみでナビゲーションを提供することは楽ができるのではなく、単なる手抜きでしかありません。
フレームのみでのナビゲーションの提供は制作者の怠慢といえます。フレームが楽のできるものだというのは忘れてください。もし、フレームのメリットを享受しながらもフレームの欠点を改善したいというのであれば、フレームは決して楽のできるものではなく制作者の作業量をより増やすものだと心得てください。それでは、フレームの欠点を改善する方法に焦点をあてましょう。
そもそもフレームだけでしかナビゲショーンを提供していないというのが誤りです。検索エンジン経由の際にランディングページがフレーム内ページであっても、フレーム内ページにもしっかりとナビゲショーンをつけていればまったく問題はありません。フレーム内ページにもリンクが張られていれば、サイト内では被リンクもしっかりと獲得できリンクポピュラリティ向上にもつながります。つまり、結局は楽ができるのではなく、フレーム用のナビゲーションと各フレーム内ページ用のナビゲーションまで記述しなければならなくなるため余計に手間がかかることになります。
ナビゲーションを全ページに記述した上で、サイト構成をフレームで固定するのではなく、トップページにフレームで閲覧するか・各々のページで閲覧するかを選択できるようにしましょう。こうすれば最も訪問者が多いであろうトップページからユーザーはコンテンツをフレームで閲覧するか、それとも各ページごとに閲覧するかを選択することができます。こうすることでフレームはよりユーザビリティを強化してくれるものとなり、最短のナビゲート方法としてユーザーに提供できるので、メリットをそのまま享受することができます。
noframes要素はフレームに対応していない環境の場合に表示させる内容を指定することができます。もちろんフレームに対応した環境では、この部分の記述を無視してフレームを表示するのでフレーム対応環境の邪魔になることもありません。重要なのが、この要素内にどのような記述を施すかです。検索エンジンの検索結果画面にはスニペットと呼ばれる、そのページの要約文が表示されます。そして検索でヒットした膨大なページの中から、ユーザーはどのページを訪問するかにあたって、このスニペットの内容が有用であるかどうかが重要な判断材料となります。
そして、noframes要素内の内容はこのスニペットにもなります。しかし、実際に noframes要素内によく記述されている文面はというと、フレームを使用しているのでフレーム対応環境でご観覧ください
といった類の記述内容であり、これでは各フレームの内容となっているリソースの表現している情報の代替にもならなければ、フレーム内の情報にもアクセスできないという結局何の意味も成さない内容を記述しているだけです。noframes要素を上手に使えば有用なサイトであるかの判断材料とも成り得る上に、フレーム非対応環境用のナビゲーションにも成り得ます。この2点を考慮した上で noframes要素内に記述する文面は次のようにするといいでしょう。
noframes要素を検索結果のスニペットとフレーム非対応環境のナビゲーションの両方に役立てる例<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"> <html><head> <title>W3G - World Wide Web Guide</title> </head> <frameset cols="150,*"> <frame src="menu.html" title="メニュー" name="menu"> <frame src="main.html" title="コンテンツ" name="main"> <noframes> <h1>W3G - World Wide Web Guide</h1> <p>初学者を対象とする World Wide Web（ワールド・ワイド・ウェブ） における情報技術の解説サイト。</p> <ul> <li><a href="menu.html">コンテンツ一覧</a></li> <li><a href="main.html">トップページ</a></li> <li><a href="sitemap.html">サイトマップ</a></li> </ul> </noframes></frameset> </html>
以上ここまでフレームを採用したサイト構成を最適化する方法を取り上げましたが、フレームを使用することで、必ずつきまとうデメリットがあります。それは、ユーザーの URI の取得が困難になることです。これを改善・緩和できる良い方法は思いあたりません。現状（*）では、フレームを享受するとうことは、イコール、このデメリットも享受しなければならないということを心得てください。
フレームは制作者が楽をするためのものではありません。楽がしたい、作業の効率化を図りたいのであれば専用の技術を利用しましょう。
SSI（Server Side Include）という技術を利用するこでフレームのメンテナンスの容易さとほとんど同じ作業量でナビゲーションの提供を代替することが可能です。SSI を利用することで任意の位置に別のファイルを呼び出し・表示することができます。
<!--#include file="呼び出したいファイル" -->
ただし SSI を使用できる環境が整っている必要があります。レンタルサーバーの形式でスペースをレンタルしている場合は、そのウェブサーバーで SSI の使用が許可されている必要があります。SSI を利用すれば、フレームと同様にナビゲーション部をひとつのファイルで共有することが可能です。ただし、ウェブサーバーによっては httpd.conf の設定によって、SSI を使うには拡張子を ".shtml" のファイルに書き換える必要があるなどの制限が設けられています。しかし、サーバーソフトウェアに Apache を利用しているウェブサーバーで .htaccess の利用が許可されていれば、拡張子に対応する MIMEタイプを上書きすることで、どのような拡張子でも SSI の利用が可能です。
SSI と同様に PHP でも別のファイルを呼び出し・表示することができる includeモジュールという機能があります。PHP を利用する場合も同様に httpd.conf の設定によっては、PHPモジュールを使うには拡張子を ".php" のファイルに書き換える必要がありますが、.htaccess の利用が許可されていれば、拡張子に対応する MIMEタイプを上書きすることで、どのような拡張子でも PHPモジュールの利用が可能です。
<?php include("呼び出したいファイル"); ?>
SSI 同様、PHPファイルの指定箇所に以上のようなソースを記入するだけです。たとえば、拡張子を ".html" のままで PHPモジュールを利用するのであれば .htaccess には次のように記述することで、拡張子 ".html" を PHP の MIMEタイプとして出力対象に設定できます。
AddType application/x-httpd-php .html
なお、XHTML の規格で文書を記述している場合は、XML宣言部分が PHP の宣言と被らないように XML宣言部分を PHP用のコードで記述する必要があります。
<?php echo "<?xml version=¥"1.0¥" encoding=¥"文字コード¥"?>"; ?>
もちろん、SSI 同様に PHP を使用できる環境が整っている必要があります。PHP においては無料でレンタルできるウェブスペースでもほとんど利用が許可されているようです（無料ウェブスペースにおいて .htaccess の使用まで許可しているスペースはほとんどないでしょう）。
フレームのようにナビゲーション部分を固定したナビゲーションを構成・提供したい場合は、CSS を使って視覚的にフレームに似せた、擬似フレームみたいなものを作成する方法があります。擬似フレームを作成するには、要素を任意の位置に配置できる positionプロパティで表示域に対して固定することで、スクロールしても動かないようにする "fixed" を使った方法が妥当なのですが、"fixed" の値に対応していない UA の中にはウェブブラウザ市場のシェアの大多数を占める Windows版Internet Explorer 6 などがあるため、現実的に position : fixed ; を使った擬似フレームを採用するのは無理があります。そこで、Windows版Internet Explorer 6 でも対応している内容があふれた場合の表示方法を指定する overflowプロパティを応用して、現状での UA の対応状況を考慮した擬似フレームを採用した方が妥当です。その作成例は次の通りです。
body {
height : 100% ; margin : 0 ;
}
div {
margin : 0 2% ; border : 1px solid #000 ;
}
.menu {
width : 20% ; float : left ;
}
.main {
width : 70% ; height : 90% ;
position : absolute ;
top : 0 ; left : 25% ;
overflow : auto ;
}
......
<div class="menu">
メニュー部分
</div>
<div class="main">
メインコンテンツ部分
</div>
ただし、CSS で視覚的にフレーム構成を擬似的に再現できたとしても、フレームのようにナビゲーション部をひとつのファイルに共有することで制作者の作業量を減らすことはできません。擬似フレームでは、各ページにナビゲーション部分を記述することになるので作業量が減ることはありません。そこで、これまでに取り上げていた SSI や PHP の includeモジュールなどの別ファイルを呼び出し・表示できる技術と組み合わせることで、作業量を大幅に削減できる上に、見た目もフレームに似せたナビゲーションを構成・提供することができるでしょう。
CMS（Contents Management System）は、サイト内のナビゲーション部分を自動生成してくれるため、ページが追加されるたびに関連するページにリンクを追加するといった煩わしい作業から解放されます。CMS のシステムには xoops, Wiki, Movable Type や WordPress などのウェブログソフトでお馴染みのコンテンツ管理ソフトを利用したものがあります。CMSソフトを利用すれば、作業はテキスト等の記述だけに専念することができるので、作業が大幅に減少することでしょう。最近は、CMSソフトの設定部分の自由裁量も増え、多くの制作者が CMSソフトを採用し、サイトを構築している事例が増えています。ただし、SSI や PHP 同様、利用しているウェブサーバーで CMSソフトを使用できる環境が整っている必要があります。