Style Guide for online hypertext
オンライン・ハイパーテキストのためのスタイルガイド

©Tim BL 1992,93,94,95 All rights reserved.
Translated by M. Kanzaki. See notes.
原文はhttp://www.w3.org/Provider/Style/を参照。

このガイドは、効果的にあなたの知識を読者に伝えることができるWWW ハイパーテキスト・データベースの作成を支援するために構想されました。 これは、読者のコメントと多くのオンラインドキュメントの提供者の要望に基づいて準備されてきたものです。部分的に個人の嗜好やあるいは一般常識のようなものに影響されていることろもありますが、論点全体としては待ち望まれてきたものなので、ここに提供することにしました。

このガイドは順を追って読むように構成されていますが、これにとらわれる必要はありません。内容は次のようになっています:

以上のリストは、個別の読者からのコメントを除き、このガイドの内容すべてを列挙したものです。

この文書を印刷するには

読者からのコメントを除く全体を長い1ページにまとめたものを印刷用に用意しています(ただし、リンクがきちんと働かないことがあり、正しいHTMLの書式に則っていません)。

この文書へのコメントを歓迎します。

ご意見歓迎します。「the Style Guide for Online Hypertext」かこのURLを書いて [スタイルガイドへの意見であることが分かるようにして] timbl@w3.org にメールしてください。作者は他のスタイルガイドや、会社のハウス・スタイルガイドのURL、あるいはあなたのお気に入りのスタイルに関する書籍(あるいはハイパーテキスト)にも関心を持っています。
(なお、翻訳についてのコメントはwebmaster@kanzaki.comまで)

イントロダクション

あなたはこれから何らかのオンライン・ハイパーテキストを書こうと(あるいは生成しようと)しています。ハイパーテキストというのは、いろいろなことができるので、ちょっと怖じ気付いてしまうかも知れませんね。ご心配なく。好きなようにシンプルなドキュメントを書けばよいのです。いろんな意味で、シンプルなほどより良いのですから。

これから別々に分かれた多くのファイルを書くことでしょう。それらのファイルはお互いに、あるいは外部の文書とリンクし合い、最終的な作品を構成することになります。

あなたの作品は「ドキュメント」と考えて良いでしょう。紙の場合はそれをその通り呼びますが、オンラインの場合は個々のファイルをドキュメントと呼ぶことが多いようです。本との対比でいえば、ドキュメントは一つの章や節に、あるいは脚注に相当します。このガイドにおいては、その全体を作品と呼ぶことにします。

ドキュメントは情報を取り上げる単位です。どんな時点においても、一つのドキュメントは利用者のコンピュータに完全に読み込まれます。また普通は、ドキュメントとはあなたが一度に編集する分量でもあります。もっとも、優れたエディタを使えば、同時に複数のドキュメントを開いておくことはできるでしょうけどね。

このガイドは、ストラクチャについての章では、手持ちの材料をどうやってドキュメントにまとめるかということについて考えます。別の章では、材料を ドキュメントの内部できちんとまとめる方法について考えます。

Webのエチケット

Webをより使いやすく、より混乱を少なくしてくれる慣例がいくつかあります。サーバー管理者、すなわち ウェブマスター webmaster として知られる人(この用語はこのページで創り出されました。下の説明を参照)として、あなたはこれをあなたのデータに適用するように務めなければなりません。 このガイドは、全ての情報提供者により多くのアイデアを提供してくれます。特に

を読んでください。サーバー管理者は以下のようなことをそれぞれのサーバーについてセットアップする必要があります:

外来の訪問者のためのウェルカムページ

あなたの発信するデータに特別なストラクチャを持たせる必要はありません: あなたがいちばんいいと考えるようにそれを発展させればよいのです。 しかし、それぞれのホストに、そこにどんな情報があるのか(ポインターによって)他の人が素早く理解できるようなドキュメントを用意しておくといいですね。 それから"/"という名前をそのドキュメントに結びつける「パス」行を、デーモンのルール・ファイルに用意しておきましょう。 ホストにどんなものがあるかという要約と同様に、関連するホストへのポインターも良い考えです。

お帰りなさい?

サーバーのウェルカムページはしばしば「ホーム」と呼ばれます。なぜなら、利用者にとってそれをホーム(デフォルト)ページとして使うのは良い選択だからです。「ホーム」ページという用語は、ブラウザが起動するときに最初に表示する場所を意味します。けれども、このことで混乱しないでください。2つの異なる概念があるのです。

ウェルカムページは、あなたのサーバーを初めて訪れ、そのコンテンツの概要を知りたいと思う人を歓迎するところです。それはあなたのホームページとよく似た目的を持っていますが、対象としている利用者が異なります。しばしば、別々のものを用意するのは事態が混乱するだけなので、組織の中の人もウェルカムページを自分たちのホームページとして用いています。少なくともこうすることで、確実に組織内の公の目を意識することにはなるわけです。 私自身はこのような方法は採っていません。なぜなら私はホームページに個人的なものをたくさん放り込んでいるので、組織のウェルカムページや、私自身の「ウェルカム」ページである自己紹介欄にそうしたものを置きたくはないからです。 ウェルカムページはあなたのサーバーがそもそも何であるかを説明しているかも知れません。それはローカルの利用者のためのホームページにはスペースの浪費です。ですから、あなたはローカルの利用者のために別のホームページを用意しようと考えることもあるでしょう。

あなたのサーバーのエイリアス

もしあなたが本格的なサーバーを運営していたら、それ(コンテンツ)は今のマシンのよりも長い寿命を持っているかも知れません。インターネットのドメイン名管理者にサーバーのためにエイリアス(別名)を設定してもらうよう依頼しましょう。そうすることで、あなたはサーバーを"mysun12.dom.edu"とする代わりに"www.dom.edu"と参照することができるようになります。ということは、将来マシンを変更しても、エイリアスを変更するだけで、利用者のあなたのデータへのリンクはきちんと生きているということになるのです。

将来(94年3月の時点で)は、クライアントは、もし他のデフォルトが指定されていなければ、ローカルの「www」と名付けられたマシンを探しそのウェルカムページを「ホーム」として使うような機能を備えるようになるでしょう。すなわち、あなたのドメインにおいてそのようなクライアントを起動すれば、適切なスタートページを開くことができるというわけです。

あなた自身へのエイリアス

あなたは「webmaster」という名前のエイリアスをサーバー上に作成するべきです。これによって、あなたのサーバー上で何か問題があった利用者はそのことについて簡単にメールできます。これはメールで問題があった利用者のために用意する「postmaster」エイリアスと同様のものです。

管理を委譲する

サーバー管理者(ルートのパスワードを持っている人)は原則的に、ものごとをオン・オフしたり、事態をコントロールしたりする権限を持っています。しかし、ドキュメントの個別の分野には明確に責任権限を委譲しておくのが賢明です。 たぶんサーバー管理者はデータの実際の中身には一切関知しなのがいいでしょう。その場合彼(彼女)はマシンをきちんと走らせることに専心すればよいのです。

ハウス・スタイル

ウェブは中央の権威を持たずに草の根から広まってきました。そしてこれはとてもうまく働いてきました。これは一つには情報提供者の創造性の賜であり、また彼らが情報を可能な限りダイレクトに生き生きと表現できる自由の賜であったわけです。 読者はこれが提供する多様性を高く評価しています。しかしながら、大規模なウェブにおいては、彼らはまたある種の一貫性も望んでいるのです。

もしあなたが組織の提供する情報を管理する責任者であるなら、「ハウス・スタイル」の長所と、個々のグループや作者に自由にやってもらうことの利点とのバランスをうまく取らなければなりません。 この点についてある決断を下したら、きちんとそれを書き留めておくことが大切です(もちろんそれをウェブに掲載することは言うまでもありません)。

ストラクチャ(構造)

もしあなたの頭の中に読者に伝えたい情報があれば、おそらくそれに関する心理的なストラクチャ(構造)を持っていることでしょう。これは、書物を書くときの章建てのような、ある種の階層的なツリー構造[木構造。太い幹から枝分かれして各々の章、節と展開していく樹木のような構造]になっていることが普通です。

このストラクチャを保っておいて下さい。書物の基本としてツリー構造をもつことは読者にとっての助けになります:これによって、今どの辺りを読んでいるのか見当を付けることが可能になるのです。また、このストラクチャに基づいて、ファイルをディレクトリに分けて整理することができます。

さらに、次のような点に注意しましょう:

読者にとってのストラクチャ

常にあなたが語りかける読者のことを意識して下さい。もし彼らがそのテーマについて初心者なら、作品のストラクチャ(構造)をかっちりとしたものにすることが一般的には役立ちます。そうすれば読者はその知識自体のストラクチャについても学ぶことができるからです。例えば、もしこのテーマは3つの明確な分野に分かれるとあなたが感じているなら、それを教えてあげることは重要です。

一方、もし読者がテーマについて何らかの知識があるならば、彼らはすでにそれについて自分なりの体系を持っていることでしょう。この場合は彼らは、意識するとしないとに関わらず、どこをさがせば何が見つかるかということを知っています。もしあなたのストラクチャが彼らのものと違っていたら、それを強調しすぎることは混乱を招き、読者を遠ざけてしまうでしょう。

この場合は、自分のストラクチャを強硬に認めさせてまわり全体を困らせてしまうことがないよう、ぐっとこらえるべきかも知れません。解決策は2通りあります。

もし、単一のはっきりしたユーザー像が念頭にあり、彼らはひとつの世界観を共有しているというのなら、あなたの考え方ではなくその世界観にぴったり合わせて書くように努力すべきです。

もし、同時に複数のグループを対象に書くのであれば、両方を用意しなければなりません。

参照を用意するときは、不要ならそれをとばして読むことができるように、きちんとその役割を示してあげましょう。たとえば「もし内部でどんな働きがあるかを知りたい場合は、内部についてのガイドを参照」とか「ステップ・バイ・ステップの導入はチュートリアルに用意されています」といった具合です。

両方の読者の視点からリンクを用意して下さい。あなたの作品は単純なツリーというよりもあちこちでつながったものになるでしょうが、きちんとした役割表示があれば、迷子になることはないはずです。

2つの独立したツリーの「出発点」を用意して下さい。例えばあるデータについて、ステップ・バイ・ステップのチュートリアルと、機能的に直接参照できるツリーとを書くことができます。どちらも一番底辺のレベルでは同じデータを持っているのですが、前者は簡単なことを最初に取り上げるのに対し、後者は機能別のグループにまとめられるかも知れません。これはちょうど、一つの書物に何通りもの索引を用意するのと同じことです。チュートリアルは、レファレンスにはない情報を含んでいてもよいでしょう。

重なり合うツリー構造

ここに2つの別々のストラクチャ(構造)を持ったある作品(あるプログラムの関数を説明するものとしましょう)の例を示します:

            チュートリアル                        レファレンス
                 |                                      |
        易しいところからはじめて               +-----------------+
    徐々に難しいところに進みましょう           |                 |
                 |                       機能別グループ      ABC順のリスト
                 |                             |                 |
          処理内容に即した実例                 +-----------------+
                 |                                      |
      それぞれの関数の具体的な使用例    <--->    関数の構文の定義

初心者は左上から出発し、順に下に向かって進んでいきます。何かについて詳細が必要になったら、使用例まで進んだ上でそこからリンクを辿って定義の記述を読むことができます。彼の視点で見れば、彼はツリー構造になった作品を読んでいることになります。実際に彼は、ある特定の関数を調べてさらにその使用例に目を通す上級者と、同じ情報を読んでいるのです。

個々のドキュメントの大きさ

ここでいちばん重要なのは、ドキュメントは明確なコンセプトを伝えるものでなければならないという点です。一つの考えを、単にサイズを小さくするというためだけに2つの部分に分割するというのは、あまり良いことではありません。逆に、明らかに別々の考えを、単にドキュメントを大きくするために寄せ集めることも、いいとは言えません。

一つのドキュメントは、脚注のように小さなものの場合もあります。

ドキュメントのサイズには2つの上限があります。一つは、長いドキュメントは転送に時間がかかり 、読者の思考のスピードに合わせて行きつ戻りつすることができなくなるということです。もちろん、これはリンクのスピードによります。

もう一つの制約は、長いドキュメントをスクロールするのは大変だということです。文字端末を使っている読者は、一般に、数画面以上を読むことはできません。多くの場合、彼らは最初の画面に表示されるものだけを読んで、興味がないもののためにスクロールするのはごめんだという感じです。読者はまた、巨大なドキュメントの先頭に取り残されて、おあずけをくらうことになるのです。

グラフィック端末をもつ読者は、普通スクロールバーを使って長いドキュメントをスクロールして読みます。スクロールバーを少しだけ動かしたときは、ドキュメントも少しだけ動いて、もとのウインドウに表示されていた部分の多くはまだ画面に表示されているべきです。これによって読者はドキュメントをざっと読むことができます。もしドキュメントが大きすぎると、スクロールバーをちょっと動かしただけでどこにいるのか分からなくなり、基本的に読むことができなくなるのです。

長いドキュメントの利点は、スクロールバーを使う読者にとっては、中断することなく一気に読むのが容易であるというところです。ドキュメントがそのように書かれていればの話ですが。

さらに、たくさんのリンクを作って(あるいは生成して)、内容が変更されたときにはそれらを最新に保つという苦労がありません。もしリンクを作るのが大変なら、目次ページへのリンク一つだけにしておくのがよいでしょう。ブラウザによっては、「next」「previous」ボタンで、リストに従ってドキュメントを順番に読んでいくことができるものもあります。

(実際は、普通ちょうど1頁分ずつ上下にスクロールすることができるはずですが、これは文字端末を使うのと同じ感じを与えます)

そういうわけで、ドキュメントのサイズに関する大まかなガイドは:

参照、それともコピー?

どこか別の場所にある情報について言及する情報システムを構築する場合、コピーする前に十分な注意を払うことが必要です。

元の場所にあるままの方が良い理由を挙げてみましょう:

コピーする方が良い理由としては次のようなものがあります:

次のようなものの、あなたの個人的なコレクションに言及するのは慎重に。これらはよく整備されたコレクションがたっぷり存在しています:

ドキュメントの内部で

スタイルガイドのこの章は、web上での情報取得の単位である「ドキュメント」の内部におけるテキストの配置を取り上げます。(いまのところ未完)。

次のセクションを参照してください:

サインしよう!

情報を最新に保つ上で重要な要素は、その作者にたどり着けるということです。ハイパーテキストでこれを実現するのは簡単です竏瀦K要なのは、作者についてのページへのリンク(あるいは、単に作者の電話番号)を用意することだけ。

あなた自身についての、メールアドレスと電話番号の入ったページを作ってください。あなたが内容に責任のあるすべてのファイルの最後に、小さな注(あなたのイニシャルとか)を入れ、そこから自己紹介のページにリンクします。ADDRESSスタイル(多くは右寄せで表示されます)はこの目的に便利です。

作者のページはまたdisclaimer(断り書き)、著作権表示など、法律や慣習にしたがったものを書いておくのにも適した場所です。これによって、メッセージそのものを、長ったらしい署名でぐちゃぐちゃにしなくてすみます。

(もしWorldWideWeb.appハイパーテキストエディタをお使いなら、このリンクを標準のページに設定して、新規文書の一番下に自動的に現れるようにすることができます)

情報の状態について

内容が確定した情報もあれば、急いでかき集められてまだ不完全なものもあります。どちらも読者にとっては有益なものですから、不完全な情報や古い情報を提供することはちっとも恥ずかしいことではありません竏窒サれは入手し得る最善のものかもしれないのです。しかし、それがどのような状態のものかを明記することは忘れないでください。最後に更新されたのはいつ? それは完成版? その適用範囲(scope)は? 例えば電話帳なら、どんな人がそこに掲載されているのか?

必ずしもすべてのドキュメントに状態の説明が必要というわけではありません。作品の概観のページに何かが記述されていればそれで十分です。

もちろん、書き方からもテキストの状態を感じとることができます・・・スペル間違い、大文字の抜け落ち、それにラフな文法といったものは、みんな非公式なノートであることを示唆しています。細心の注意が払われた「shall」や「should」の使用や、長い大文字化された名詞句(Long Capitalized Noun Phrases=LCNPs)は、少なくとも国際標準化機構(ISO)の標準文書の雰囲気を醸し出してくれるでしょう ;-)

日付を明記しよう

場合によっては、制作年月日と最終更新年月日を作品に加えておくことが有益です。(これはサーバーをちょっとプログラムするだけで自動的に可能なことだという点に注意してください。)

この情報を付加することで、のちのち読者が古くなった情報を調べて時間を無駄にしなくてすむかどうかという点を考えてください。

リンクを本文の流れに組み込む

オンラインテキストが順を追って読まれる文章を書くのと大きく違うのは、読者がどこからやってくるか分からないというところです。例えあなたがそこには1個所からしかリンクを設けなかったとしても、別の誰かはまさにその部分を参照したいと思うかもしれず、彼自身の作品からあなたの作品のその場所にリンクするかもしれません。ですから、あなたは読者があなたの考えた順路にしたがって作品を読むはずだと考えることはできないのです。

もちろん、チュートリアルを書く場合は、本来の読者のために、一つのドキュメントから次のものへの流れをあなたの考えの通りに保つことは重要です。出し抜けに飛び込んでくる利用者のことまでいちいち考慮してはいられないでしょう。しかし、そういう人のためにも何か手がかりを用意し、途方に暮れることがないようにしておくのは賢明です。次のような方法が考えられます:

さらに、あなた自身がいつかそのドキュメントを再利用するかもしれないと考えながら書くことは有益でしょう。いつか、そうなるかもしれません。

前後関係を示すアイコン

アイコンはナビゲーションを大いに助けてくれます。作品を通して一貫したアイコンが用意され、常に(「トップ」ページにいるときを除いて)トップページにリンクされているということは、とても効果的です。これは一石二鳥の効果があります:これは作品に一貫性を与え、読者はいつその内部に入り、いつそこから出ていったかということが理解できます。また、それは読者に、トップページにすばやく戻る手段も提供するのです。

同じことを節にもあてはめれば、各ページの冒頭(あるいは末尾)に小さな一列のアイコンを用意し、最初のアイコンは作品のトップに、2番目は章の先頭に、そして3番目は章の中の節に戻るなどとすることができます。

(このスタイルガイドは、作者が画像を扱えないハイパーテキストエディタを使用してきたため、長い間アイコンがありませんでした。いずれ改善するつもりです竏稚bl)

タイトル

ドキュメントのタイトルはTITLE要素で指定されます。TITLE要素はドキュメントのHEADの内部に記述しなければなりません。

ドキュメントにはタイトルが一つだけ存在します。これは、かなり広いコンテクストにおいて、ドキュメントの内容を表すものでなければなりません。

タイトルはドキュメントの本文の一部ではありませんが、ドキュメント全体を構成する要素の一つです。その内部にはアンカー、段落指定、ハイライト[などのタグ]を含むことはできません。タイトルは履歴リスト中でそのノードを特定したり、ウインドウ表示のときの名前としてなどに使われます。普通は、ドキュメントの本文表示には現れません。タイトルと見出し[Hnタグ]を比べて見ましょう。タイトルはできるだけ64文字以内に納めるべきです。多くのアプリケーションはタイトルをウインドウのタイトルバーやメニューで表示しますが、そこには限られたスペースしかないからです。タイトルの長さに制限はありませんが(ほかのデータから自動生成されるかもしれませんから)、情報の提供者としては、長すぎる場合は後ろを切られてしまうことを理解しておかなければなりません。

使い方の例

適切なタイトルとは、

    <title>Rivest and Neuman. 1989(b)</title>

とか

    <title>A Recipe for Maple Syrup Flap-Jack</title>

とか

    <title>Introduction -- AFS user's Guide</title>

のようなものです。適切でないタイトルとは、その文脈においてしか意味が分からないような

    <title>Introduction</title>

とか、長すぎるもの

    <title>Remarks on the Quantum-Gravity effects of "Bean
    Pole" diversification in Mononucleosis patients in Developing
    Countries under Economic Conditions Prevalent during
    the Second half of the Twentieth Century, and Related Papers:
    a Summary</title>

などです。

機種に依存しない

あなたの書くハイパーテキストはHTMLという言語で表されます。そこにはドキュメントの表示に用いられるフォントや段落の形、スペースの設定といった情報は含まれていません。

この結果、あなたのドキュメントはテキスト端末を含むあらゆる機種において適切に表示されるという、大きな強みを持つことになります。

利用者はそれぞれ異なったスペース設定やフォントを用いているということに注意を払わなければなりません。見出しやリストのような構造を表す要素[タグ]を正しい用法で使うように注意してください。たとえあなたの画面上での表示が気に入らなくても、不適切な要素[タグ]を使ったり、空要素[タグ]によってスペースを捏造して見かけを整えようとはしないこと。結局それは、ほかの利用者のところではまた違うように解釈され、とても奇妙に見えるかもしれないからです。多くの場合、利用者は各要素の表示方法を変更することができます。

例えば:

さらにドキュメントのテストの項も参照。

これらのガイドラインに従うと、あなたの画面上ではあなたの望むとおりの表現にはならないかもしれません。けれども、おそらく読者はより幸せなはずです。

標準的なHTMLを使う

あなたの書くハイパーテキストはHTML言語によって保存されます(あるいは、少なくとも、インターネット上を送られます)。現在(1991-1997)のところ、HTMLを自ら書く人もいる一方で、HTML文書の制作に、ハイパーテキスト・エディタのようなツールを使う人もいます。

どのような種類のHTMLタグを使うべきでしょうか? あなたは、あなた自身もしくは使用しているソフトウェアが作り出すHTMLの種類について、意識的であるべきです。

第一の理由は、世界中のソフトウェアが等しく理解できる標準的なHTMLを注意深く使うということは、さきほど検討した「機種に依存しない」文書を作るということになるからです。

将来にわたる保証

第二の理由は、あなたとしても作成しているデータが将来においてもきちんと利用できるものであって欲しいだろうということです:将来のソフトウェアの進化によって影響されないものが望ましいはずです;あなたの文書の寿命(likely life)は、一考に値するものです。たとえそれが内容的には古くなったとしても、もし5年、10年、20年のうちに一般的な利用者には読めないものになってしまったとすると、その損害はいかばかりでしょうか? 同じことが、あなたが「仮想ハイパーテキスト」竏停・言い替えれば、その場でハイパーテキストを自動生成するプログラム竏停・を書いている場合にも当てはまります。そのようなプログラムは、あなたの会社や仲間の日常活動の一部ともなり得るものであり、もしそれがうまく機能すれば、長い間にわたって使えるものになるのです。

「拡張されたHTML」のある種の機能を使ってみたいという誘惑はあるかもしれません。しかしそれは、データを読んだり生成したり処理したりするのに、特定の会社のソフトウェアを使うことを、排他的にかつ効果的に、要求するものなのです。 けれども、独自ネットワークからインターネットへの移行のために、また独自OSからそうでないものへの移行のために、企業が多大なコストを払ってきたことを思い出してくれる人もいるでしょう。会社の資産や製品は、時間とともにダイナミックに変化するものです。ですから、あなたが後継者に課すことになるかもしれないコストのことも考えてください。

  • どんな人があなたの文書を読もうが関係ないというなら、どんなものでも好きなタグを使えばよいでしょう;
  • もし文書の有効期間が本当に短く、読者もはっきりしているのなら、読者が使っているブラウザのことだけを考えて書いて構いません;
  • もし現在から将来にわたって全てのソフトウェアがあなたの文書を読めるようにしたいと考えるなら、最新のW3Cの勧告となっているHTMLを使ってください(1997年7月時点ではHTML 3.2であり、まもなくHTML 4.0となります)。
  • もし、古いソフトウェアでもきちんとあなたのドキュメントを読めるようにしたければ、最新版の一部分だけを使うようにする必要があります。例えば、HTML 2.0のタグだけを使うというように。

HTMLの標準はWorld Wide Web Consortiumによって制定され、ドキュメントはTechnical Notesから入手することができます。この分野の開発の最新動向は、W3C HTML activityをチェックしてください。

あなたの文書がある標準に適合しているかをテストするツールはいくつもあります。それらを利用してみるのも良いでしょう:もし自分でHTMLを書くなら定期的に、編集ソフトを使っているならときどきでいいと思います(あなたのドキュメントをテストするも参照してください)。

他のフォーマット

明らかに、同様の理由から、画像、アプレット、アニメーション、音声、ビデオその他についてもどんなフォーマットを使うかについては注意を払う必要があります。画像については、1997年の時点で、GIF97とPNG[JPEGの誤りか?(訳者注)]は安全確実であり、PNG(GIFの強化版)も受け入れられつつあります。しかし、どの標準が信頼できるかを調べるのはこのガイドの範囲を大きく超えるテーマです。新聞・雑誌はこれらの評価に重要な役割を果たしてきましたし、W3C、IETF、ISOなどの機構による保証も重要です。

スタイルシートを使う

では、HTMLのタグは本来の目的にしか使わないという苦行を自らに課したとして、どうやってページを「クール」にすればよいのでしょうか?

スタイルシートを使ってください。スタイルシートはブラウザにページをどのように表現するべきか指示するファイルです。音声合成ブラウザに、異なるタグをどのように発音すべきか指示する音声スタイルシートまであります(間もなく登場予定 -1997)。

現在スタイルシートとして推奨されているのは「Cascading Style Sheets (CSS)」言語です。将来は他の言語も利用可能になるかもしれません。これを使うと、色、フォント、配置、それに何かがどこにどのように表現されるべきかなどについて、HTMLで可能なことよりもずっと多くのことを指定することができます。

スタイルを別の文書で定義しておくとどんな良いことがあるのでしょうか? いくつかの理由を挙げておきます:

スタイルシートを使って楽しんでください。さらに、会社の中やシリーズの出版物で、それらを使うことによって、文書の特定の状態と特定のスタイルを関連づけるようなルールを決めましょう。

さらに、CSSに関するより詳しい情報も参照。

印刷可能なハイパーテキスト

理想の世界では、紙は必要なくなっているかもしれません。理想に近い世界では、人々はドキュメントのハイパーテキストを書き、さらに全く別の紙バージョンも書き上げる時間があるかもしれません。しかし、現実の世界では、おそらく印刷用のドキュメントとオンラインドキュメントを同じファイルから生成したいと考えることでしょう。

たとえば、HTMLファイルがマスターで、これをもとにして長い一つのファイルを作り、できたらTeXに変換して印刷するというようなことを考えましょう。最初はそんなこと考えないかもしれませんが、いつかそうしたくなるかもしれません。

文中でオンラインの視点からの参照を使わないようにしてください。「ここをクリック」よりも優れています。実際のところ、ここでも機種に依存しない形態について述べているわけですね。

残念ながら、それぞれのドキュメントに署名し、前後関係のリンクを用意するという推奨すべき習慣は、印刷物にとっては往々にして邪魔になってしまいます。もちろん、共通のフォーマットにきちんとしたがっていれば、それを機械的に取り除くことは可能ですが。

たとえば、このドキュメントによせられるコメントで最も多いのが印刷しにくいという内容です。そこで私は、ちょっとしたスクリプトを使って、全体を1ページにまとめたバージョンを作成し、表紙ページからそこへのリンクを用意しました(スクリプトは私がふだんあまり使わないSedのものです。私は各ページの先頭と末尾にルールを設けておいて、スクリプトはそれを使って印刷には不要な部分を切り落としています)。

あなたの(ハイパー)テキストを読みやすく

これは、私がよく目にする、そしてあまり好きではない、ハイパーテキストのスタイルを巡る2つの問題について少々文句をつけようというものです。

一つ目は「ここ」症候群です。すなわち:

    これこれに関する情報は _ここ_ をクリックすると入手できます。

というもの。この場合、「ここ」はリンクになっています。このスタイルは全くもって奇妙奇天烈です。「ここ」をクリックするには、*本当に* ここでいいのかどうかを確かめるために、周囲を見回さなければなりません。声を大にして言いますが、HTMLページを作成するにあたっては、クリックする場所は、それが指し示す内容のタイトルのようなものにしてください。すなわち、

    _これこれ_ に関する情報が用意されています。

そして、

    _検索の方法についての情報_ が用意されています。

のように記述し、

    検索の方法についての情報は、_このリンク_ を選択してください

とは書かないようにしてください。

これほど問題ではないけれども、まだおかしいのは、内容を示す語句をリンクとして使っているのに、依然としてリンクについて述べている場合です:

    _クレジット_ ページと _技術的詳細_ へのリンクがあります。

こうではなくて、次のような書き方を心がけましょう:

    貢献してくださった _さまざまな方々_ に深く感謝します。
    このシステムの _技術的な詳細_ を用意しました。

つまり、HTMLページを、リンクをたどらずに読んでも意味がとおるようにせよということなのです。

メカニズムについて書かない

インターネット上のサービスのお知らせは、たいていの場合、FTPやメールサーバーの使い方などの、情報を取得する方法についての情報のページが付け加えられています。WWWはこうしたものが不要になるよう設計されているのです。

こうした説明をなくして、次のようなリンクを残しておこうという誘惑に駆られることでしょう:

    以前はFTP、NFS、メール経由でしか利用できなかった大きなFTPのアーカ
    イブを、WWWで利用できるようになりました。ここには数多くのパブリッ
    ク・ドメイン・ソフトウェアと著作権が切れたテキストが納められてい
    ます。

ウェブは、FTPとかNFSとか竏淡WWについてすら竏鋳mる必要が無い、あるいは知りたいと思わない人々が読者なのです。ですから、次のように書く方が望ましいといえます:

    このアーカイブには数多くのパブリック・ドメイン・ソフトウェアと著
    作権が切れたテキストが納められています。

話の主題に集中して、仕組みやプロトコルについては語らないほうが、テキストを短くすることができ、人々により読んでもらいやすくすることができます。

ウェブを前提として書く場合でも、リンクは使うものであって、それ自身について語らないでください。たとえば:

    これについてもっと知りたい場合は、ホームページにリンクしている
    チュートリアルを読んでください。

というのは、次のように書いた方が明らかに優れています:

    詳しくはチュートリアルをご覧ください。

別のありがちなケースは:

    チュートリアルには草刈りについて、草刈り機の砥ぎ方、そして
    草刈り機の購入方法についての章があります。

読者を引きずり回さず、目的地に直接ジャンプできるようにしてください!

    チュートリアルには草刈りについて草刈り機の砥ぎ方、そして
    草刈り機の購入方法についての章があります。

ドキュメントをテストする

ある意味でハイパーテキストは書物と同様で、校正が必要です。またある意味でそれはプログラムと同じく、テストをしなければなりません。少なくともドキュメントが対象としている読者グループから何人かを選び、それを読んでもらってフィードバックを受けるようにしましょう。ほかのアイデアとしては:

どの程度テストするべきか?

テストには時間がかかります。どの程度テストするかは、ドキュメントに求めるクオリティによります。読者とあなたの時間と労力のバランスを取るということです。もしドキュメントが何かのアイデアを「売る」ものなら、あるいはあなたがドキュメントを売ったりサービスを提供したりする立場なら、できるだけ読者にとって読みやすいものを作ろうとすることでしょう。もし多くの人があなたのドキュメントを読むなら、あなたが少し時間をかけることで多くの人の時間の無駄を防ぐことができるでしょう。

しかし、もしあなたが他の人は関心を持ちそうにないシステムのあまり光の当たらない部分についてドキュメントを作っていたり、あるいはとにかく何かの情報があるだけでも読者はラッキーだと思えば、テストに時間を費やする理由はありません。その情報が必要なら、目指す情報にたどり着くために少々余分な苦労をしてリンクをたどり、あなたの書いたことを理解するべきであるといってもいいでしょう。これがもっとも効率的な方法かもしれないのです。私がこの点を強調するのは、一瞬の間だけ頭に浮かび、急いでファイルに走り書きされ、後の代まで伝える必要はないという情報が非常にたくさんあるからです。このような情報は、洗練されていない形でも利用できるようになっている方が、形が整っていないからといって隠されているよりもずっと有益です。電子技術が発達する前は、出版の労力が大きいためこのような情報は日の目を見ず、クオリティの高くないものを出版するのは無益で読者を侮辱するものとみなされていたのでした。こんにちにおいては、あらゆるレベルの「出版」が存在し、クオリティの高いものも急ごしらえのドキュメントも、いずれもそれぞれの価値を持っているのです。けれども、読者を失望させないために、こうしたものへの参照を用意するときは、ドキュメントのクオリティを明記しておくことが重要です。

サーバーのログファイルを観察すると、どのドキュメントが実際に読まれているかということが分かります。あなたの時間は、これらのドキュメントのクオリティ向上にあてることで最も有効活用されるというわけです。もちろん、ログファイルの分析自体も時間を食いますけどね。

HTMLをテストする

もしハイパーテキストの編集ソフトを使っているなら、ファイルは常に正しいHTMLで構成されているはずです。現在は、しかしながら、多くの人がHTMLファイルをテキストファイルとして編集し、マークアップを自分で挿入しています。もしあなたがそうしているなら、HTMLの文法チェッカーを通してみるとよいでしょう(W3CのHTMLについてのページからいくつかのリンクがあります)。新しいHTML生成ツールを使うときは、いちどそのアウトプットをテストしてみるのも良い考えです。クライアントリストのページには、いくつかのブラウザ(HTML編集機能をもったものもあります)へのリンクと、別のリストへのリンクがあります。

許容できるコンテント

スタイルガイドの他の章では、テキストのレイアウトや構造について取り上げました。ここではちょっと脱線して、スタイルという言葉の範囲を拡大して、ウェブに掲載される情報の実際の内容としてどんなものなら許容できる(acceptable)のかといったことを考えてみましょう。

ウェブは社会一般の知識を網羅することを狙いとしており、特定のフォーマットやレベルに限定されることはありません。ですからそこでは走り書きのノートから百科事典までどんなものでも見いだせる可能性がありますし、そのスタイルやマナーもさまざまです。しかし、情報は広く一般にアクセス可能となるわけですから、まさにその素材が出版(公表)されるという理由において、なにがしかの許容範囲という考え方が存在します。

インターネット上では、ニュースとメールはごく非公式なメディアであると考えられ、そこではある程度の自由が認められます。しかし、公開されたウェブ上のドキュメントには、誰がリンクし、あるいはたどりつくかは知り得ません。国によっては、法律上の規制や情報に関する倫理コードが存在することもあります。私は世界的な検閲を支持するつもりはありませんが、だからといって次に挙げるようなことがあなたの書くドキュメントに当てはまるかどうか、考えなくてよいというわけではありません。

適切なクレジット

ある作品の見つけやすさは、特にウェブ上では、どこで参照されるかという点に依存しています。もし学術論文がある事象の説明を目的としていながら、関連する作品への言及を欠いていたら、学術規定(academic code)によってきちんと参照するように要求されるでしょう。

商品を販売する商用サーバーは、そのようなコードには拘束されていません:競争相手の製品へのリンクを見いだすことはないでしょう。ですから、あなたの一連のサービスは公平であることを旨としているのか、もしくは商用目的で利害関係があるのかをはっきりと示してください。どちらの情報もひとびとから歓迎されるものです。しかし、何か他のものの仮面をかぶった宣伝というものは歓迎されません。

許容できるコンテント

ポルノグラフィは、一般に受け入れ難く違法とされるコンテントのうち、最もよく議論の対象となるものです。他にもあります:誹謗中傷、著作権やそのほかの知的所有権を侵害するもの、犯罪行為を助長するものなどはやはりやめておくのが賢明です。これを考えるには次のものを念頭においてください:

  • あなたの読者
  • あなたの時間、機材、接続性といったものを提供してくれる人々
  • あなたの国の政府

あなたの読者に害があると考えられるところでは、そこへのパスが警告のページを経由するようにし、そのページに関連するURIは同様の警告なしでは決して配布しないようにすることで、あなた自身と読者をある程度守ることはできます。もちろんこれは、絶対に安全とはいえません。

W3CのPICSはあなたのページをあなた(あるいは他の誰でも)がその許容度を格付けできるようにするということを目的としています。親や教師が、格付けを使って子どもにとって適切な内容を選別できるようにしようというものです。この技術は1996年には商業ベースで利用可能になることが期待されています。

許容できる用語法

許容できない用語法とは、許容できないコンテントの最も単純な形態です。基準は国によって異なります:アメリカにおいては厳しいものになっています。次に挙げるのは、徹底的でも完全でもありませんが、避けるべき種類の用語法のチェックリストです。

性差別的
男女どちらでも構わないときに、男性もしくは女性を指し示す言葉を使う用語法。利用者のことを「彼」とか「彼女」とか読ぶのは、どちらも好ましくないとされます。
「アダルト」
性的な風刺やあからさまな用語は、あきらかに「ノーノー」です。
人種差別的
民族を表すポリティカリ・コレクトな用語法(差別的でないとされる表現)は、人によってずいぶん違うようです。これは強く意識されるものなので、注意を払っておくのが賢明です。
宗教上の仮定をする
宗教について議論することは理にかなっていますが、読者がある特定の宗教を信仰している、あるいはしていないと不用意に仮定することは危険です。

教育的なスタイル

「なぜ?」ボタン

ジェウェル・コッブ(Jewel Cobb、科学者、教育における少数派の権利のための活動家)は私にK-12教育(義務教育)のためにハイパーテキストを作成している人に助言するように求めました。私が即座に思いついた最も重要なことは「なぜ」のリンクでした。もしこどものためのFAQというものがあるとすれば、それは「なぜ?」です。考えてみてください。ウェッブ上で、熱心な教師たちが長年にわたってせっせと「なぜ」ボタンを用意し、それらがその説明にリンクされているとしたら?

子供たちが「なぜ?」と尋ねることを奨励するのは重要なことです:それは科学的な好奇心にとどまりません。規則について、やたらと浴びせられる所説について、宣伝について、あるいは何か変だと思われるあらゆることについて、彼らは「なぜ?」と問いかける権利を持っているということを学ばなければなりません(なぜ?)。

大人でも同じく「なぜ?」と問いかけることを忘れてはなりません。われわれは、質の高い答えをもたらしてくれるハイパーテキストを作成することで、これを奨励することができます。

理論的根拠の検証を置き去りにしては

私たちが観察することがらについて「なぜ?」という質問に答えようとすることができるのなら、私たちが決定することがらについてはもっと多くのことを答えられるでしょうか? 私たちが物事を構築し、デザインするのですから、私たちはこの過程の産物を、その時の行動の理由にたいする試験的なポインターという形で注釈することができるのです。

フレッド・ブルックス(Fred Brooks)はThe Mythical Man Monthの中で、「第2システム効果(second system effect)」ということを述べています。すなわち、新しいシステムを設計する人は、最初のシステムのあらゆる問題を注意深く排除するけれども、最初のシステムの設計者が注意深く回避したあらゆるミスを犯してしまうものだと言うのです。 仕様と計画がその背景に「なぜ」のツリーを備えていれば、自分たちはもっとうまくできるという性急な感覚に身を任せてしまうことなく、注意深い考えによって変化できる可能性が高くなるでしょう。

「どのように」そして「なぜ」のツリー

ある目的を達するために、人間のあるいは電子的な何らかのシステムを構築するとき、「なぜ私はこれをしているのか?」の反対の問いかけは「私たちはどのようにこれを行うか?」ということです。

我々はあるプログラムを書くために人を一人雇う

これは2つの質問に対する答えを教えてくれます:「我々はなぜ人を雇うのか?」そして「どのようにして我々はプログラムを書き上げるのか?」。 「なぜ」の関係は「どのようにして」の関係の反対にあたります。 「なぜ」のリンクを可能な限りさかのぼれば、ある行動に対する完全な理論的根拠にたどり着くはずです。「どのようにして」のツリーを反対にたどれば、それがどうやって成就されるかの処方箋を手に入れることができるでしょう。「どのように」と「なぜ」のリンクを構築することで、はじめから正当化されたプランを作ることが可能になるのです。

なぜ「なぜ?」が必要か

なぜと尋ねることができるのが重要だというのはなぜ?

(もしこれが優れたハイパーテキストなら、科学、社会、政治、倫理、哲学に関する、よく調べられたリンクが用意されているはず竏窒オかし、これはそうではないので用意できていません。関連する素材についてのご教示を歓迎します)。

背景となる参考リソース

オンライン・ハイパーテキストのためのスタイルガイドを読むにあたって参考になるほかのドキュメントをいくつか挙げておきます:

Personal views:

このリストはまだまだ完全なものではありません。今日(1994)の時点でもウェブ・サイトの構築やHTMLの書き方に関する書籍はたくさん出版されています。それらに共通してみられる欠点があるとすれば、みなある特定のブラウザを想定しているという点です。気に入ったものを手に取ってみてください。たいていは刺激的であり、良いアイデアを得ることができるでしょう。ウェブを見て回り、自分で考え、ガイドについて私にメールをください。

以下のレファレンスは1996年8月23日に Charles Gaudette <acgolf@novagate.com>から示唆してもらったものです。作者は未確認です:

その他の未確認リソース:

著作権

原文の著作権はティム・バーナーズ=リー氏にあります。引用は自由ですが、いかなる形態においてもこの著作物の複製を作ることは、著作者の書面による同意無しには禁止されています。 http://www.w3.org/People/Berners-Lee/を参照してください。

この日本語訳に関しては、オリジナル同様に引用・紹介は自由ですが、転載・再配布などはできません。当ドキュメントへのリンクは、言うまでもなく自由です。