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

この文書を印刷するには

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

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

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

イントロダクション

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

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

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

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

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

Webのエチケット

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

• 作品に署名しよう -- 特にウェルカムのページにはぜひ
• 進捗状況を明記しよう

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

ストラクチャ（構造）

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

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

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

• 読者が感じとるストラクチャ
• 重なり合うツリー構造という考え方
• 個々の文書はどれくらい大きくするべきか
• 参照すべきか、それともコピーすべきか

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

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

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

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

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

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

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

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

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

重なり合うツリー構造

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

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

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

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

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

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

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

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

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

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

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

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

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

• オンライン・ヘルプの場合は、メニューが他の項目へのアクセスを提供します：24行に収まるように小さくするのが良いでしょう。文字端末ブラウザを使って確認して下さい。
• 文章として読むドキュメントの場合は、A4で半ページから5ページまで。

参照、それともコピー？

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

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

• その情報が更新された場合、あなたは何らかの方法でそのことを知り、新しい情報をコピーするか、あるいは古くなった情報をいつまでも使うかどちらかになる。
• もしあなたがコピーの方が使いやすいと感じたとしても、それは相対的なものであることを忘れないで下さい。別の場所から利用する読者は、オリジナルの方が身近に思うかも知れません。もしオリジナルにアクセスするのがとても難しいのなら、その本来の掲載場所として別のサーバー（自分のサーバーを提供しても良いですが）を見つけることができます。

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

• もしその情報が、例えばニュースの記事のように、なくなってしまう可能性のあるものなら、コピーを取っておかなければならないでしょう。
• 特定のバージョンを参照したい場合、それは将来変更されて、アーカイブにも保存されないかも知れません。

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

• インターネットのFAQ(Freequently Asked Questions)リスト
• RFC (Request For Comments -- Internet Standardsなど)
• 主題別情報リスト
• いわゆる「ベスト」URL集。あなた個人の、特定の関心に基づいたリストを作って下さい。その方がずっと値打ちがあります。

ドキュメントの内部で

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

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

• 作品に署名する
• 進行状況を明記する
• リンクを本文の流れに埋め込む
• コンテキストから離れても分かるタイトルを用いる
• 機種に依存しない表現

• 標準的なHTMLを使う
• スタイルシートを使う

• 印刷することも考慮に入れて書く
• リンクに関わりなく読めるように書く
• メカニズムについて書くのではない

サインしよう！

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

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

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

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

情報の状態について

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

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

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

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

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

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

• 文章や用語がそれ自身で意味を成すように注意すること。ドキュメントの冒頭が「次に我々が考えることは...」とか「この問題に対する唯一の解決策は...」のようになっていると、明らかに混乱を来たします。
• しばしば最初の言葉は文脈に依存しているので、そこからバックグラウンドの情報にリンクしておくことができます。たとえば、WWWプロジェクトのドキュメントでは、WWWという略語が最初に出てくるときはだいたいプロジェクトの中心となるページにリンクしています。
• ドキュメントの冒頭もしくは末尾にナビゲーション用のヒントを置いておけば、分かりやすい指示になります。このドキュメントの末尾はその例になっています。

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

タイトル

ドキュメントのタイトルは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という言語で表されます。そこにはドキュメントの表示に用いられるフォントや段落の形、スペースの設定といった情報は含まれていません。

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

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

例えば：

• 常に見出しタグを順番に使用すること。レベル１の見出しをひとつだけドキュメントの先頭に置き、必要ならレベル２の見出しをいくつか、そしてさらに必要ならレベル３の見出しをそれぞれのレベル２の見出しの下に配置します。レベル２見出しの表示方法が気に入らなかったら、クライアント［ブラウザ］の設定を調整してください。決して、［レベル２をとばして］レベル３の見出しに変えてしまわないように。
• 文書の形を整えるために余分なスペースや空行を設けないこと。ただし、PREタグを使った整形済テキストの部分は除く。
• 特定のブラウザの機能を前提とした文章を書かないこと。マウスを使わない環境の人には「ここをクリック」というのは無意味です。「リンクを番号で選択してください｣というのが行モードのブラウザを使っている人を無視しているのと同じことですね。リンクはそのままにしておいてください。普通、利用者はどのようにしてリンクを選択するかちゃんと知っていますから、そのような指示は退屈なものです。

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

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

標準的なHTMLを使う

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

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

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

スタイルシートを使う

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

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

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

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

• スタイルシートを一つ用意すれば、たくさんの文書でそれを利用できます；
• そうすれば、ブラウザがスタイルシートをキャッシュするので、ダウンロードの時間を節約できます；
• スタイルシートを変更するだけで、全ての文書の体裁を一気に変更することができます；
• スタイルシートの言語はHTML言語から独立です：それは独自に拡張することができ、将来はHTMLだけでなく他の文書記述言語（DTD）にも適用するということもあり得ます；
• スタイルを別のシートにまとめることで、HTMLがすっきりするので、機種に依存せず、障碍のある人々が利用可能なページ作成がしやすくなります；
• 文書の印刷向けに、別のスタイルシートを用意することも可能です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

そして、

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

のように記述し、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ドキュメントを複数の異なるブラウザで読んでみて、機種依存が無いことを確認する
• 読者の傾向を観察する。これはサーバーのログファイルを分析することで可能になります。ある部分が読まれていないとすると、読者は間違ったところを探している可能性があります。読者がある一定の道筋を行き来していることが分かるかもしれません。彼らが何を求めているかが推測できれば、リンク周りの手がかりをもっと使いやすく改善できるでしょう。（利用者に関する情報を削除するまでは、ログ情報は秘密扱いにすること）。
• 読者からの批判や提案を受け入れる用意があるかどうか、またその場合読者はどこに連絡すべきかを明記すること。
• 人々に、ドキュメントを使って課題を解決し、その成果についてレポートしてくれるように依頼してみる。もしうまく行かなかった場合は、人々な何を探したのか、そもそもそれはドキュメントに記述されていたかどうかを確認すること。

許容できるコンテント

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

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

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

教育的なスタイル

なぜ「なぜ？」が必要か

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

• 科学的な好奇心がなかったら、科学の発見はなかっただろうから。
• 民主主義は「見識ある市民」（informed public）に支えられているから（原則として、市民は直接的にまた間接的に決断をしなければならないから）
• 疑問をもたない個人はだまされたり操られたりすることがあるから
• 我々の社会は、お互いの中に、うつろいやすい条件で組み込まれた一連の仮定に基づいて構築されており、不断の見直しによってのみ、この仮定と信頼の枠組みは、われわれが深刻なトラブルに陥ることがないよう、きちんと一貫した状態で維持されることができるから。

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

背景となる参考リソース

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

• All about the various HTML Specifications
• A Beginner's Guide to writing HTML
• World-Wide Web server software - a list of pointers
• Web Etiquette -- for Server Administrators (now part of this guide)
• The Web Designer, N Laviolette. Many references
• The Sevloid guides to Web Design and to HTML John Cooke, 1997 (

Personal views:

• Thoughts on style from Jorn Barger.

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

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

• J.K. Cohen's Style Rules for Web Pages see number six.
• Jack Lynch's Grammar and Style Notes.
• H. W. Fowler, Modern English Usage.
• Thomas Pinney, A Short Handbook and Style Sheet.
• Keith Ivey's English Usage Page.(link may not work 1996)
• Webster's Unabridged Dictionary, 1986.
• The Basic English Handbook. M. W. Taylor, Cuyahoga Community College, 1995(link ok? '97)

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

• The Sevloid Guide to Web Design, John Cook, 19967

• Patrick J Lynch, Yale/AIM, "Web Style Guide",

著作権

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

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