本稿はCSSと画像の表示に対応したPC向け視覚系UA（Internet Explorer など）をご利用になられている方を読者として想定しております。あらかじめご了承ください。
注：本稿を読むにあたり、別画面でver.beforeとver.afterを開いておくことをお勧めします。
「宇治IN茶筒」は2002年2月1日に活動を休止し、その後まもなくWWWから消えたサイトです。幸い、休止にあたり原著者が著作権を主張しないことを宣言されたので、私はミラーサイトを構築しました。またこれとは別に、思い切って全面的にリニューアルした再構成版も作成しました。再構成版作成のポイントは次の3点です。
目標を実現する手段は無数にあります。私の選択は一例に過ぎませんが、リニューアルについて考えるヒントを多く含むものと信じます。
リニューアル前の「宇治IN茶筒」（以下、ver.before）は、56のHTML文書からなる中堅サイトです。リニューアルを考えた時点で、ver.beforeの活動は休止していました。これ以上、記事が増えることはありません。ならば更新され続けるサイトとは異なった発想でまとめ直すべきではないか、私はそう考えました。
サイトのまとめ読み……それは読書に似ています。
「1冊の本のように読み進められる構成」というコンセプトは、こうして決まりました。
ver.beforeの構成を見てみましょう。コンテンツは全部で8つあり、更新履歴、旅行記、話のネタ、掲示板、落書張、リンク、プロフィール、MAILの順に並べられています。サイトの中心をなすコンテンツは旅行記、落書帳、話のネタです。旅行記と落書帳はともに一本ネタですが、サイトの看板は明らかに旅行記の方です。日々の更新には掲示板が利用されており、自信作が話のネタに収録されています。
更新が止まると、途端に重要度が低下するのが更新履歴とリンク集です。これにプロフィールと掲示板のログもあわせて、サイトの補足情報として扱うことにしました。掲示板は話のネタと内容の多くが重複しますし、往時を偲ばせる歴史的文書として扱うのが適当ではないか、との判断です。MAILは既に作者のメールアドレスが死んでいるので、削除します。交流目的の隠しコンテンツもあるのですが、これも削除することにしました。
以上より、再構成版のコンテンツは旅行記、落書帳、話のネタ、etc.の4項目へ整理されました。
ver.beforeではコンテンツ毎に目次が設けられています。大項目→小項目→コンテンツという標準的な3階層の構成です。コンテンツ同士を直接参照するリンクは用意されていません。こうしたサイト内のリンク構造に、サーバ上にあるファイルの階層も対応しています。通常のサイトなら3階層で問題ありませんが、私はこれを1階層に作り変えることにしました。
1冊の本のように読み進められる、というコンセプトを実現するには、
こうした課題を解決しなければなりません。となると、階層構造は不都合が目立つ、と考えたのです。
一方、目次をサイトマップとして機能させることも考え、ひとつの目次からサイト内の全ファイルへリンクを用意することにしました。
ver.beforeでは、34本の話のネタがそれぞれ別ファイルとなっています。これを踏襲しますと、話のネタがファイル数で他のコンテンツを圧倒します。これではサイトの目玉がぼやけるように思いました。「宇治IN茶筒」の看板は旅行記です。質量ともに旅行記が他を圧倒しているので、ファイル数の多寡が原因で旅行記が霞んでしまうのは望ましくありません。そこで、話のネタのファイル数を減らすことにしました。
掲示板に更新された最後の挨拶を追加して話のネタを合計35本とし、これを5本ずつ7ファイルに整理することに決めました。結局、旅行記の6ファイルよりも多くなってしまいましたが、この程度ならばナビゲーションの工夫次第で印象を操作することは難しくありません。
更新履歴、プロフィール、リンク集はひとつのファイルにまとめました。掲示板のログも整理を試みましたが、こちらは結局13ファイルになってしまいました。これもナビゲーションの工夫でファイル数を少なく見せる他ありません。
書籍の特徴は、文書の並べ方に順序があることです。リングファイルなどを利用してページの差し替えが可能な場合もありますが、あくまでも例外といってよいでしょう。しかし書籍の読み方は非常に自由です。パラパラとページをめくって途中から読み出すこともできますし、関連する項目を順不同で興味のあるところから読んでいくことも簡単です。
HTML文書の重大な制約は、リンクのない文書は参照できないということです。Webサイト（＝HTML文書群）の閲覧に書籍と同等の自由度を与えるには、サイト内の全文書にサイトマップを付属しなければなりません。link要素とWWWブラウザの連携によって将来的には実現可能な課題ですが、当面は夢物語です。
そこで、link要素に依らず、従来型のナビゲーションによる擬似的な目標達成を狙います。（注：擬似的とは、「明示的でないためHTMLパーサには解釈できず、人間だけが理解する」ことを指す）
最低限のナビゲーションとして、前後の文書と目次への参照を用意しました。カーソルを「Next→」の位置に合わせ、Page Down、Page Up、Homeなどのキーボード操作でスクロールを行うと、非常に少ない手数でサクサク読み進むことが可能です。
目次から順に次々読んでいくと、再び目次に返ってきますが、無限ループを作る意図はありません。リンク集までで一通り完結しており、だから目次には「直前文書」の参照がありません。ではなぜリンク集の次に目次へ返るかといいますと、読み足りない方にボーナストラックを紹介する、という流れを意識しているためです。漢文の返り読みように、目次を2度利用しているわけです。
ボーナストラックは「掲示板のログ→ver.before→宇治さんの近況」と展開して終わります。これらはサイトを本に見立てた場合、巻末資料にあたります。本文とは異なり、編者としても前から順に目を通すのではなく、目次から興味のある項目のみ参照されることを期待しています。前後文章の参照を利用しないのはこのためです。あまりスマートな処理ではありませんが……。
賛否両論あるでしょう。全文書にサイトマップを添えるのはさすがに大仰なので、次善の策として同一コンテンツ内の文書への参照を用意しています。読書での、近くのページから面白そうな記事をパラパラ探す感覚を再現したかったわけですが、試みの成功を断言する自信はありません。いささか特殊なナビゲーションとなっているので、パッと見では理解できない方が少なくないかもしれません。
一般的な方法は、関連文書をまとめた小目次へのリンクを用意することです。つまり、文書と小目次は分離するわけです。例えば本稿では、パンくずリストを用いて大目次と小目次を参照しています。
話のネタのように、ひとつのファイルにいくつかの項目が含まれる場合、それぞれを参照できるようにしておくと便利かもしれません。関連文書の参照のオプションとしてリストの入れ子で表現しているのですけれども、少し慣れないとその意味に気付かないかもしれません。関連文書の参照自体がアイデア倒れだとすると、文書内項目の参照も再設計が必要になるでしょう。
いずれもver.beforeにはないナビゲーションですが、すんなり理解できる方にはそれなりに便利だろうとは思います。
ver.beforeには100点を超える画像が装飾に使われているのみならず、不可解なマークアップによるファイルの肥大化が目立ちます。文章主体のサイトなのですから、シンプルに軽く作って低速回線でもストレスなく読み進められるよう心がけた方がトクではないでしょうか。
作業としては、ここが最大の山場となるでしょう。
ver.beforeの各ファイルは、ホームページビルダーの「どこでも配置モード」とWordの「Webページとして保存」を利用して作成されています。いずれもファイルの軽量化に向かない方法として有名です。じつはいずれもCSSデザインを悪用しており、無理に無理を重ねてしまうところに特徴があります。
じつはStrictなHTML文書の作成とCSSによるデザインは、ともにブラックボックス化が困難（→補注：ツールの進化）です。CSSを用いてテーブルレイアウトと同等以上の装飾を施しつつ、軽くシンプルなHTML文書を作成するには、どうしても製作者のHTMLとCSSに対する相当の理解が必要とされます。さもなくば、CSSの利用はむしろ悲劇的結果を招きかねません。
ver.beforeのデザイン上の特徴は、コンテンツごとにデザインが変わる、という点にあります。また文字サイズ固定、幅固定、フォント指定など多用されていますが、あまり効果があがっていないようです。HTML文書としての妥当性を調べると、「どこでも配置モード」の悪い特徴（→補注どこでも配置モードの怪）にはまっていることも判明しました。そこで、思い切って以下の決断を下しました。
文書構造について、私の採用した方針を簡単にまとめておきますので、参考になさってください。
この方針がベストだ、というわけではありません。ただ、この程度のことであっても、方針を明確化することで作業がシンプルになります。悩みが減るのです。
また、方針が決まれば大量のファイルに対して複数の文字列を一括置換するソフトを利用することも可能となってきます。ver.afterの作成では、用意したテキストファイルに対して一括置換を行い、head要素、ナビゲーション、footerなどの枠組みを一気に追加しました。本文のマークアップにも一括置換を利用しています。まず改行をp要素に置換し、後から見出しと箇条書きの部分を修正するわけです。
なお、リンク集だけはマークアップの修正によりver.afterを作成しています。テキストファイルに落とすとリンクの設定が失われてしまい、いささか面倒なことになりそうだったからです。一括置換による効率化にとらわれず、臨機応変に対応していくとよいでしょう。
「ValidなHTMLとCSSによるサイト製作が常識となるにはツールの進化が欠かせない」などとよくいわれますが、それは誤りです。現在のハード／ソフトでは自然言語をそのまま解釈できないからHTMLが登場したのです。HTMLを知らない人が正しいHTML文書を作成できる時代が到来するならば、そのときにはもはや（本質的には）HTMLなど必要なくなっているはずです。文章を入力するだけでどこが見出しでどこが段落かを計算機の方で判別できるなら、マークアップは必要ありません。
そもそもテキストファイルから適切な文書タイトルを一意に決めることは不可能です。見出しの階層だって、単純にこうだと決められるわけではない。定義リストなのか見出し＋段落なのか、という問題は製作者の判断なしに解決できない。だからマークアップの必要性は失われず、HTML文書の製作者にはマークアップという概念への理解が必要とされ続けます。
HPBのどこでも配置モードは、「文法的に概ね妥当なHTML文書＋CSSデザイン」というシステムを実現しています。しかしこの意欲的な試みの失敗を認めない人は（HTMLとCSSをある程度理解している方なら）滅多にいません。マークアップという考え方を理解しない人は、どんなツールを使ってもろくな結果を生み出せない、と断言できます。
計算機が絶対に対応できないことをマークアップにより実現しようというのが大元の話なのだから、「ツールの進化により人間はマークアップについて考えずにすむようになる」と考えるのは根本的に無い物ねだりなのです。→本文へ戻る
HPBにはどこでも配置モードと標準モードがあります。どこでも配置モードはページを構成する要素をdiv要素に入れて絶対座標で左上の角を原点として配置します。画像を重ねて配置するなど、従来は実現に手のかかった表現を簡単に扱えるので、IBMではHPBの一番の売りと考えているようです。しかしどこでも配置モードはお勧めできません。重大な問題が3点あるからです。
どこでも配置モードのソースは、要素が作成された順番に生成されます。ですから、もし細心の注意を払って頭から順に作成していったとしても、後から図版を1枚足したなら、それはソース上では最後に出現します。表示位置はposition:absoluteで決めるからどうにでもなるわけですが、それが逆に問題なのです。あるいは、A段落とB段落の間に、新たにC段落を書くとします。表示位置を調整してAとBの間にCを配置するのは簡単です。しかしCは最後に書かれたので、ソース上では最後に登場します。
どこでも配置モードでは、よほど注意していなければ意味の通ったソースになりません。音声系ブラウザでは、ソースに書かれている順番で内容を読み上げます。つまりどこでも配置モードでは、視覚障害者にも利用しやすい文書を作成するのは難しいのです。
実際の作例のソースをいろいろ見ましたが、リストとリストマーカーの画像が全然違う場所にあるなど日常茶飯事で、文章の順番がグチャグチャなのは珍しくもなく、なんか妙に大きな画像があると思ったら、（ソース上では）遠くにある文章の背景用だったりします。現在のどこでも配置モードは欠陥品です。アウトラインプロセッサのような機能を充実させて、ソース上の要素の出現順序を手軽に修正できるようになるまでは使えません。
どこでも配置モードでは、まずdiv要素が用意されます。このdiv要素の大きさと配置を決めてから、その中にあれこれの要素を放り込みます。このとき使われる単位はpxです。div要素の縦と横の長さもpx単位で決定されますので、文字サイズを大きくするとdiv要素から内容があふれます。解決策は文字サイズの固定しかありません。
どこでも配置モードはCSSをすべて<div style="position:absolute; 以下略">という形で出力します。したがって、外部CSSファイルが効きません。ページ単位でデザイン固定のサイトになってしまうのです。よって、「サイト内でのデザイン統一が可能」「サイト全体のリニューアルがCSSファイルの書き換えだけで実現可能」「デザインを考えずにHTML文書を作成可能」というCSSデザインの3大特長がすべてパーです。
どこでも配置モードは、現状ではひどく未熟な技術です。テーブルレイアウトさえ難しいと感じる人のために、どこでも配置モードは作られています。福笑いができる人なら誰でもサイトを作れるわけですから。IBMはサイト作成の裾野を広げようとして、他社が手を出さなかった禁断の方法を使ってしまったのではないですか。CSSを悪用しているのです。→本文へ戻る