http://frame.s26.xrea.com/doc/Thinking/02.shtml

右ナビ-左本文 左ナビ-右本文 上ナビ-下本文 下ナビ-上本文 ナビのみ ナビ無し

フレームナビ&段組ナビ

このページの見出し一覧
  1. 段組デザイン
  2. 段組デザインの発想
  3. table,CSS段組における誤った考え方

段組デザイン

段組デザインという言葉を聞いたことがあるだろうか。本来の意味での段組とは、2つ以上のエリアにひとまとまりの文章を流し込むことを意味する。身近な例を挙げるならば、新聞(ウェブサイトは基本的に横組なのでのアメリカの新聞などを想像されるとわかりやすい)の本文がいい例えだろう。無論、新聞だけに限らず雑誌や、あるいは新書版の小説等でも段組を見ることができるだろう。段組のは、長文を読ませる場合において視覚的に見やすくする為に存在している。

段組とは文章を読み易くする為の分割手段だ、ということが理解できたと思う。が、実はこれは得に関係ないので気にとめる必要はない。

しかし、ウェブサイトで飛び交う段組デザインという語句は、tableタグやスタイルシート(以下CSS)でレイアウトを左右分割する手法を指すことが多い。そしてそのほとんどにおいて、分割される内容は『ナビ』と『本文』というまったくの別要素である。よって、それは只のレイアウトデザインだろうと突っ込みを入れたくもなるが、どうやら浸透してしまっているようなのであえてこのサイトでも段組デザインという言葉を使うことにする。

※稀に、table(内のセル)を均等に分割して文章を(表示上は)段組しているものもあったりするが、普通に考えて非効率的であることは言うまでもない。それぞれのボックスが繋がっていない限り段組とは成り得ない。仮にA,Bの2つのボックスがあって、Aボックスに入りきれなかった文章がBへ流れ込む、というものが段組である。言わずともウェブページは可変サイズのメディアだ。Netscapeの独自拡張やこれからのCSSプロパティの拡張で本来の段組は存在はしているが、得に必要性は感じない。私見だが。

段組デザインの発想

関連キーワードで検索するとよくわかるが、CSS段組の解説サイトではtableを使わずに段組というような言葉がしばしば登場する。これはCSS段組デザイン以前、つまりCSSという概念が浸透する前にtable(表組)デザインが浸透してしまったからだろう。では、そのtableを使っての段組という発想はどこからやってきたのだろうか。

table,frameがいつできたのかというリソースは残念ながら筆者のウェブ検索方法では発見できなかった為、tableレイアウト・フレームデザインのどちらが先かということはわからないが、実はこれは取るに足らぬ些細な問題である。両者の表現したい事というのはまったく同じことであり、とどのつまり『片方で伝えたいことの一覧』を示し、『その内容をもう片方へ出力』という単純なシステム(思考)だ。

このシステムを説明するのに最もわかりやすいのがWindows OSの『エクスプローラー』表示だろう。ウィンドウをフレームで2分し、左側にフォルダの構造を全て表示させ、クリックすると右側に内容を示す

逆に(という言い方は適当でないが)Macintosh(OS9.Xまで)では一覧表示で構造表示は可能ながらも、フォルダと『フォルダを含むドキュメント』をちょうどHTMLのリストタグ(ol,ul要素)のように任意で段階的に表示させることができる。そして、フォルダをダブルクリックすると新しいウィンドウでさらに展開、というシステムだ。

簡単に説明すれば、この両者の良い所を融合させたものこそが、ウェブサイトで最もわかりやすいナビゲーションシステムであり、それを最も簡単な手法で表現できるのがフレームだ。

table,CSS段組における誤った考え方

結論から言おう。tableでナビゲーションを段組しようと、tableを使わずにCSSで視覚的に段組しようと、結局はフレームと同じような見栄えにしている(したい)だけなのだ。さらに言えばフレームを使いこなす自信が無いから、或いは、フレームは色々と問題が多いから使わない方が無難だという情報を鵜のみにしてしまっているから、だろう。愚行としか言い様がなかろう。本で例えるならば、全てのページに目次があるのだ。そんな本、誰も買わない。

table,CSS段組における誤った考え方とは則ち、ナビゲーションを段組させて表示させようという発想自体なのである。CSSやスクリプトを用いて表示・非表示の切り替えができるようにすればいい、と考える人もいるかもしれないがそれもどうかと思う。当然、CSS、スクリプトといった(主に)表示上の手助けを行うものはブラウザ側でON/OFFできるし、デザインをCSSのみで行う制作者であれば当然にそのことは考慮しているだろう。『非対応でも閲覧上問題ありません』というメッセージを添えて。そして、多くの場合それは閲覧上の操作性・利便性は無視されている。

では非フレーム環境はどうだろう

フレーム否定派リソースでしばしば言及される問題のナンバーワン候補が『非フレーム環境』問題だ。例により、寄せられた参考サイトを紹介並びに引用させて頂く。問題点が箇条書きでまとめられているので、その問題点の解決手段をを順番に説明しよう。

フレームは訪問者にとって本当に優しいの?より

サイト内ナビゲーションをより良いモノにするため、すなわち訪問者にとって優しいサイト作りをするために、フレームを導入しているサイトもたくさんあります。

まず、結論から言うと、「フレームは、全ての訪問者にとって優しいとは限らない」のです。訪問者のWWWサーフィン環境によっては、全然優しくないことにもなりかねません。

なぜなら、フレームは、

  1. 大きな画面を使うことを前提としている
  2. URLの働きを保持できない
  3. アクセシビリティが低下する
  4. 使えないブラウザが存在する
  5. 印刷時に複数のフレームを印刷できない
  6. お気に入り(ブックマーク)の設定が難しい
  7. ロボット型検索エンジンには引っかからない

という、問題点を抱えているからです。特に1〜3の問題は深刻です。

1.大きな画面を使うことを前提としている問題

先ず述べておかねばならない点として、この問題はフレームに限らずあらゆる段組ナビデザインサイトにも同じことが言える。両サイドのいずれかにナビを置くデザイン上、これはまぬがれない問題である。この問題を指摘している参考サイトでさえ、CSS段組によりコンテンツの表示のために最大限使えるスペースを削っていることからも明らかだ。つまり、重要なのは削ったスペースを開ける手段を読者に提供できるかどうか、を解決できるかどうかがポイントだ。

当サイトではトップページでも説明しているように、各文書の最初に表示されるURLをクリック(選択)して頂くと、内容のみをゆとりを持って参照できるだろう。便宜上、『フレーム外し』と呼称する。※ブラウザ知識に長けた方であれば、任意のフレームのみを参照することもできよう。無論、

まして、noresize属性で、フレームの大きさが変更できなかったり、挙げ句の果てには、scrolling="no" でフレームが画面からはみ出ていてもスクロールできない(ホイールマウスがあれば可能だが)という極悪テクニックを使うのは、論外です。そんなにしてまで、見栄えにこだわりたいのでしょうか?

と説明されているように、そのような使い方は論外。そんなにしてまで、見栄えにこだわりたいのでしょうか?という点ではCSS段組にも同じことが言える。

2.URLの働きを保持できない問題

すでに述べたが、文書のURLを画面最上に記述している。これはサーバー側で自動処理しているのでやりたくても出来ない場合はあるかもしれないが、自力で書いたとして、少なくとも保持できるだろう。方法は簡単だが、これは別項で改めて述べることにする。

ファイル数や読み込み時間の問題も指摘されているようだが、フレーム定義ファイルさえ読み込めばナビ・フレームファイルは通常そのままなので、連続して読むファイルは結局文章ファイルのみだ。HTMLに多量のナビを埋め込むよりも総数としてはるかに容量は抑えられる。ちなみに余計に読み込むフレーム定義ファイルの容量は1キロバイト前後。

リンク絡みの問題に関しては筆者も同意する。いちフレーマーとして心得ておくべし。

3.アクセシビリティが低下する問題

フレームを用いたからといってアクセシビリティは低下しない。noframes要素を正しく記述すれば何の問題もないのである。これまでにも述べてきたが、問題を知り、解決策を知ることが重要なのだ。

『noframesにナビへのリンクを入れる』というのも悪くはないが、移動距離短縮の為、このサイトではnoframes要素(則ちフレーム定義ファイル)には直接ナビのソースを出力させている。ソース自体はナビ(サイトマップ)と同じデータを読み込んでいるのでアンカーが増えた際も自動的に更新される仕組みだ。この詳しい方法も別項で述べることにする。

4.フレームが使えないブラウザの問題

前述の内容で解決する。ただ一点、筆者が調査した際にMacintoshのInternet Explorer5.Xにおいて、ブラウザでフレーム閲覧を拒否設定した場合にnoframesで表示させたリンクが『クリック』できないバグを発見した。常識的に考えて自らフレーム閲覧を拒否設定する人はごく少数、それもサイト制作者がチェック用に使うようなものではあるが、これは無視できない問題だ。初心者が誤って設定してしまうという事もあり得る。フレームサイト制作者はこの事を知らせる注意書きは用意しておいた方がいいだろう。

5.印刷に関する問題

これも先述の『フレーム外し』で解決する。が、問題はそこにあらず。

考えて頂きたいのが「読者はどのような際に印刷をしたいのか?」ということだ。考えるまでもないが、後で読む為だ。紙面に印刷された瞬間、それはWWWを離れて新聞や雑誌と同じ印刷物となる。ここで、文書内ナビゲーションの致命的欠点が露になる。もうお分かりだろう。どのページを印刷してもナビが印刷されてしまうのだ。

CSS2で定義されたメディアタイプ(@media screen)を使用すれば、不要部分の印刷は回避できるだろう。だが、フレームが使えないブラウザの問題があるように、CSSが使えないブラウザの問題もあるのだ。非CSS状態で印刷した場合にどうなるか。この問題を回避できるか。段組サイト制作者は一考されたし。table段組に至ってはもはや救いようもないが。

お気に入り(ブックマーク)の設定に関する問題

『フレーム外し』で解決する。

ロボット型検索エンジンとの相性の問題

これもnoframesを正しく記述すれば問題ない。

前項[ナビの考え方]へ / 次項[フレームサイトはやめよう]へ

presented by (ー..ー;へ