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

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

フレームサイトはやめよう

このページの見出し一覧
  1. サイトという定義
  2. フレーム否定論
  3. フレームサイトは作ってはならない
  4. 選択肢としてのナビゲーション

サイトという定義

ホームページ・ウェブサイト・・・呼び名は様々だが、便宜上ここでは『サイト』と呼ぶ。サイトを作る際、そこには必ず目的(テーマ、コンセプト)がある筈である。そして、ほぼ大多数のサイト制作者がどのようなデザインにしようかな、と考える。その思考の要素はHTMLのバージョンやtableを使ったレイアウトなのかCSSデザインなのかフレームにしようか…など様々なものから選択される。こうして、制作前段階(或いは製作中)においておぼろげなサイト全体像が浮かび上がってくるのだが、あえて言おう。この時点で既に間違っていると。

間違っている、とは確かに大袈裟な言い回しだ。世間一般的な考え方では別に何も間違ってはいないし、それこそ「制作者の勝手だろう」と言われるだろう。しかし、このサイトの目的はあくまでフレームの普及なので、この場においてはやはり「間違っている」と言おう。当然、フレームを否定する考えに対してだ。

フレーム否定論

ウェブ制作関連記事において、「是非、フレームを使いましょう」と奨励するようなものは驚く程少ない。皆無と言っても過言ではなかろう。精々、「うまく使えば便利でしょう」程度の言い回しばかりだ。うまく使う方法は大概適当に書かれている。(例)noframes要素をきちんと記述しましょう、等。

逆にフレームの問題点(と考えられている事)に対しては、事細やかに書かれていたりする。その問題点(否定理由)については、これまでに説明したように以下の4項目に要約される。

  1. 非対応ブラウザ(UA)で表示できない
  2. 分割された際のウィンドウ面積の問題
  3. ブックマーク等の個別リンクの難しさ
  4. taeget未指定による著作権侵害

この問題はtable,CSS段組における誤った考え方ですでに解決策を述べたが、ここで意外と思われる事を提唱しようと思う。それは、フレームサイトは作るな、という事だ。

フレームサイトは作ってはならない

フレームを否定する人の視点はサイト定義としてフレーム形式を選択したサイトに対しての視点である。分かりやすく言えば、悪い所だけを見てそこを言及してるだけに過ぎない。冒頭で記述したように、サイト定義として選ばれるもの、切り捨てられるものが多々存在する。ここでフレームを切り捨てる制作者の考えは、多くの場合、前述の4つの問題点を考慮する為だ。そして、このフレームを切り捨てるという思考こそが、サイト構造・文書の価値・メンテナンス性を考慮していません、とアピールするようなものなのだ。

究極的にサイト構造は『1文書』+『1ナビ』で成立する。文書量が100になれば当然、『100文書』+『1ナビ』となる。それを視覚的にわかりやすくするために繋ぐものがフレームというだけの事。私は「フレームサイトを作りましょう」などという愚かなことは言わない。ナビゲーションとしての「フレームは便利である」ということを述べている。則ち、サイト構造及びナビゲーションの特性を予め計算していれば、読者に対して、同一のデータ(ドキュメント)による複数のプレゼンテーションが可能だと言いたいのだ。

余談になるが、代替CSSというものがある。複数のCSSファイルを予め用意し、ユーザー(読者)に文書情報はそのままで好きなデザインを選択させるというものだ。この機能(思想)自体は素晴らしいものであるし、いずれ必要となればこのサイトでも使用するだろう。だが、便利な反面、この機能を利用したCSS段組サイトには大きな穴がある。

CSSナビ段組の落とし穴

大規模なナビをCSS段組する場合、ナビゲーションはリスト要素(ol or ul)でマークアップされている場合が多い。構造を持ったサイトを示すにはリスト要素はまさに適格なタグだからだ。俗に言う正しくマークアップするstrict志向。それ自体はかまわないが(むしろ推奨する)、問題はこのリストが記述されている位置にある。あるサイトには文書の下(フッタ)にあり、あるサイトには上(ヘッダ)にあり、見出しの下にあったり、と正しいHTMLの割には統一されていない。ただ、視覚上はCSSにより一般的な位置に置かれている。

統一されていないのも無理はない。ナビが文書と完全に結びついてしまっているから、構造上分離できないからだ。そして、HTMLもまた構造を持った文書である。ドキュメント構造記述言語だ。ドキュメント構造にサイト構造を含むからドキュメント構造が破綻、つまり記述位置があやふやになってしまうわけだ。

選択肢としてのナビゲーション

複数の文書群とそれを司るナビゲーションファイル、この二つにフレーム定義ファイルを添えるだけで読者への閲覧手段は大きく幅を広げることができるだろう。

フレームサイトを作るのではない、代替手段としての閲覧方法の一つにフレームがある。あるリソースで「フレームサイトを作る時はフレームではないページも用意しましょう」などという見当違いな言葉を見たことがある。あくまでフレームは手段の一つだ。固執してはいけない。当然、ナビ・フレームの使い方に少々のテクニックを要するが、初心者でもわかるSSIを使った簡単な手法だ。(これに関しては別項にて)

正しいスタイルは一つとは限らない。様々な環境を想定し、使い易いものを読者へと提供するという考え方はユニバーサルだ。そこへ更なる利便性を追求する。ユニバーサルからネオ・ユニバーサルへ。フレームというこれまで軽視されていた『箱』は使いようによっては『パンドラの匣』にも『宝石箱』にもなるだろう。

前項[フレームナビ&段組ナビ]へ / 次項[●●●●●●●●●]へ

presented by (ー..ー;へ