Tips『新世紀エヴァンゲリオンSS/FFをHTML化する人のために』

はじめに

本稿はちまたにあふれる『新世紀エヴァンゲリオン』にかかわる二次創作小説、いわゆるSSやFFを快適に読んでもらうための小技を示すことを目的とします。私は一読者として楽しく快適に人々の作り上げた世界をのぞき見ることができればなによりの幸せであると考えています。そのために『新世紀エヴァンゲリオンSS／FFを読む人のために』を書いたわけですが、やはり読者側が努力しても、材料そのものには変わりがないので限界があります。できることならもとのリソースを閲覧しやすいものとしていただくのが一番。というわけで、本稿を公表します。初歩的なHTMLの書き方については、有用なリンクを文中で紹介します。なんらの高価なオーサリングツールも必要としないので、サイトの管理者のかたはぜひ試していただきたいと思います。本稿がエヴァンゲリオン二次小説サイトの管理者、投稿者のなんらかの一助になればそれにこしたことはありません。

目次

• はじめに
• 妥当なHTMLを書く
• 物理要素は排除する―font要素を中心に
• 段落を表現する―p要素とbr要素
• 論理要素の誤用は避ける―blockquote要素など
• 見栄えはスタイルシート で制御する
• リンクナヴィゲーションを用意する
• HTML Validatorで確認する
• テキストブラウザで確認する
• インターネットリソースの意味と概念を理解する
• おわりに
• 有用サイトへのリンク一覧
• 付録・日本語における意味段落・形式段落とHTMLにおけるbr要素・p要素

妥当なHTMLを書く

すでに『新世紀エヴァンゲリオン』がはじめて放送されてから6年半あまり。セカンドインパクトも起こらずに21世紀に突入しました。不人気だった第弐拾五話および最終話の補完からはじまったSS/FF界の隆盛はインターネットの勃興期と重なり、当然それからしばらくの間に「伝統」が形作られました。その結果、現在もこの世界のHTMLは1997年1月のHTML 3.2ベースで、Netscape Navigator 4.xで閲覧することを想定する古いものとなってしまいました。みなさんがなんらかの解説書やWebで学んだHTMLの多くはこの古いHTMLであると思われます。HTML3.2は、わずか11ヵ月後の同年12月のHTML 4.0(99年12月に改訂されHTML 4.01が現行版）で、すぐに非推奨要素となってしまった（つまり使うべきではない）、さまざまな見栄え制御にかかわる要素（たとえばfontやcenter、uなど）を一度とりこんだものでした。ところがすぐに非推奨になってしまった見栄えの制御に関わる要素の存在こそが、いわばHTML3.2の「ウリ」のようになってしまい、現在までHTML3.2ベースのあまり読者に優しくないHTMLが生き残ることになったのです。

たとえばfont要素による文字サイズの操作（可読性を損なうほどに巨大なフォントを表示したり、逆に小さすぎるフォントで表示するなど）やbody要素におけるbackground属性による不整合な背景の指定（背景色が黒で文字色が灰色、あるいは赤）などがあります。またbr要素による強制改行の連発（後述）や、blockquote要素の誤用によるインデント（後述）などがあります。しかしHTMLとは本来論理的な意味を記述するものであって、文字の大きさなどの見栄えを記述するものではないのです。たとえば見出し要素(h1〜h6)ならば、そこが見出しであるということを示しており、見出しであるからこそUA（いわゆるブラウザなどの総称）の多くは大きな文字で表現するのです。決して文字を大きくする、ということを示しているわけではありません。ですから文字を大きくしたいからといって、見出しでもない場所を見出しとしてマークアップしてはいけません。そのようなことをしないために、次章以降、見栄えやデザインの質を維持したまま、きちんと意味も表す妥当なマークアップをするにはどのようにすればよいかを説明いたします。

物理要素は排除する

以下は、HTML 4.01においてdeprecate（非推奨）、つまり使わないほうが身のためとされていて、さらに最新版のXHTML 1.1では廃止されている要素です。というわけで、あまり好ましいものではないので、使わないほうがよいし、その方がお互いのためというものです。ここではそれらの非推奨要素がSS/FFサイトにおいてどのように使われるかと、どのようにして代替すべきかを示します。HTML一般については神崎正英さんによるHTML 4.0 – 使わない方がよい要素を参照のこと。なお本章ではFONT要素について特に詳しく述べます。FONT要素は驚くほどの積極性をもって多用されています。厳密な説明は水無月ばけらさんによる鳩丸ご意見番 – なんで FONT は駄目子ちゃんなのかを参照してください。

FONT-パターン１．とりあえず強調

これは非常によくあるパターンです。特に多いのはサイズの変更です。大きい声は大きい字でというのは一見当然のことのようですが、HTMLでは当然ではありません。HTMLは意味を表すようにマークアップすると前章で述べました。これは具体的には次のような意味なのです。大きい声であるから大きい字にするということを、より解釈すると、大きな声だから、強調すべきで、そのために大きな字にすると言い換えることができます。したがって、HTMLで示すべきは、font要素で字を大きくするということではなく、そこが強調されているということなのです。大きい字にしてはいけない、と言っているのではありません。HTMLで字を大きくするのが問題なのです。HTMLで示すのは強調という意味的なことだけで、それを大きく表示したり、あるいは太字で示したりするには、また別の手段CSSが用意されています。つまり意味（強調）と表現（字を大きくする）の分離が重要だということです。では、さらに具体的に見ていきましょう。次のように使用されます。（以下出力サンプルはCSS適用環境でのみ意味あり）。

出力例

これはたいてい以下のようなfont要素が使用されています。

<font size="20pt">あんたバカァ！？</font>

この場合のようなfont要素の使用は一見問題なく見えますが、しかしこれでは当初の目的である強調するということをHTMLでは表現していません。それならどうすればよいでしょうか？ HTMLには「強調」を示すemという要素が立派に存在しています。これを使って、ここでは次のようにコーディングするべきです。

<em>あんたバカァ！？</em>

このようにするとたとえば、Internet Explorerのデフォルトの環境では次のように表示されるでしょう。

出力例

おそらく大きさはそのままでイタリックになっていると思います。これが欧文なら充分に強調をあらわすことができますが、日本語では汚く見えるだけですね。そこでスタイルシートの登場となります。スタイルシートに以下のように指定（詳しくは後述）します。

em {font-style: normal; font-size:20pt;}

その結果、まったく別の表示となり当初の目的は達成されます。このようにすれば、上記の記述をしたスタイルシートにリンクする全てのHTML文書で、em要素でマークアップしたすべての部分が同様に表示されます。いちいち文書ごと、その箇所ごとにfont要素を使用して大きさを変える必要はないのです。

出力例

なおこれでもまだ若干問題が残っています。それは20ptと指定していることです。ptは絶対的な単位で、なにがあろうと20ptで固定されてしまいます。そうするとたいていのブラウザにある文字の大きさを変える機能を使ってもまったく大きさが換わらないので、文字を大きくして読みたいひとや、逆に画面が小さいので字を小さくして読みたい人にあまり親切ではないでしょう。

そのために相対的な単位があります。emやexという単位を使用します。emはベースとなる要素でのフォントの大文字のMの高さを基準として、それに対するの倍率で相対的な大きさを表す単位です。つまり2emとしていするとおおむね2倍の大きさとなります。これをつかえば、元の文字の大きさを変えてもそれに比例して大きくなったり小さくなったりします。なるべく相対単位を使用するべきでしょう。

em {font-style: normal; font-size:2em;}

出力例

本項は以上です。

FONT-パターン２．キャラコメ用色換え

続いてはfont要素による色換えについてです。台詞が延々つづくよう小説で、時に発言者の名前を出さずに色だけで発言者を表現していることがあります。電波系などではテンポが崩れず味があってよいのですが、各発言をいちいちfont要素でマークアップするのは実に面倒なことです。スタイルシートを使えばサイト内のデザインを一括して行うことができます。本項では汎用属性classの使用方法を学びます。以下がサンプルです。

このサンプルは次のようにコーディングされていることが多いでしょう。

<font color="red">あんたバカァ！？</font><br>
<font color="purple">なんでアスカにそんなこと言われなきゃいけないんだよ！？</font><br>
<font color="red">うるっさいわねぇ。下僕のくせにグチャグチャいうんじゃないわよ！</font><br>
<font color="green">相変わらず仲いいわねぇ……</font><br>

まず下のようにHTMLを正すのが吉です。強制改行brではなく段落pを使ってマークアップします。

p要素は段落を示します。段落は段落としてマークアップすべきです（果たして台詞が意味段落を形成するのか？といった疑問については付録で後述します）。ごくまれに、p要素は改行＋一行空きとなどというふざけた説明を見かけますがこれは大嘘です。pはあくまで段落を示す要素です。

<p><font color="red">あんたバカァ！？</font></p>
<p><font color="purple">なんでアスカにそんなこと言われなきゃいけないんだよ！？</font></p>
<p><font color="red">うるっさいわねぇ。下僕のくせにグチャグチャいうんじゃないわよ！</font></p>
<p><font color="green">相変わらず仲いいわねぇ……</font></p>

毎度毎度fontを指定するのが、実に面倒であるうえに、HTMLにおいても非推奨要素を使うことになりあまりいいことがありません。ですからfont要素には沈黙していただきましょう。

<p>あんたバカァ！？</p>
<p>なんでアスカにそんなこと言われなきゃいけないんだよ！？</p>
<p>うるっさいわねぇ。下僕のくせにグチャグチャいうんじゃないわよ！</p>
<p>相変わらず仲いいわねぇ……</p>

それでは続いて汎用属性classを追加してみます。class属性によって各要素をグループ化することができます。

<p class="asuka">あんたバカァ！？</p>
<p class="shinji">なんでアスカにそんなこと言われなきゃいけないんだよ！？</p>
<p class="asuka">うるっさいわねぇ。下僕のくせにグチャグチャいうんじゃないわよ！</p>
<p class="misato">相変わらず仲いいわねぇ……</p>

class属性を指定しても、なんら表示は変わらないと思います。そこでスタイルシートの登場です。スタイルシートに以下のように記述します。

.asuka {color: red}
.shinji {color: purple}
.misato {color: green}

そうすると当初のサンプルの表示のようになります。こちらのほうがHTMLとしてもスマートですし、書いている人間にも誰の発言かがわかります。また、このスタイルシートを適用しているすべてのHTML文書のどこでもclass属性にasukaと指定すれば文字色を赤くすることができます。font要素による指定よりもはるかに合理的でしょう。

.nocss {display: none;}
.asuka {color: red}
.shinji {color: purple}
.misato {color: green}

<p class="asuka"><span class="nocss">アスカ：</span>あんたバカァ！？</p>
<p class="shinji"><span class="nocss">シンジ：</span>なんでアスカにそんなこと言われなきゃいけないんだよ！？</p>
<p class="asuka"><span class="nocss">アスカ：</span>うるっさいわねぇ。下僕のくせにグチャグチャいうんじゃないわよ！</p>
<p class="misato"><span class="nocss">ミサト：</span>相変わらず仲いいわねぇ……</p>

本項は以上です。

FONT-パターン３．理念なきフォント遊び

あまり意味がないので即刻中止すべきです。もし、なんらかの理由があるならそれなりに汎用要素spanやdivを使用して、何とかできるでしょう。また文字のフォントやサイズに絶対的なこだわりがあるならば、PDFなどを用いるべきであえてHTMLを使用すべきではありません。

ともあれ、HTMLでフォントをいじらないでください。スタイルシートでフォントをいじるのであれば、それを見たくない人は見ないという選択をすることが容易です。そこまで配慮してください。

CENTER―意味のない全文センタリングは不可

CENTER要素センタリングしたい文字列を<center></center>で囲むだけでよいため非常に便利ですが、HTML4.01では非推奨ですので使用を控えるほうが無難です。これはalign属性による指定も同様です。スタイルシートによる代替は簡単にできますが、そのまえに一つ注意しておきたい点があります。

もしセンタリングしたいのが見出しなどであればそれ相応の理由といえるでしょう。しかし全文をセンタリングすることは勧めかねます。詩文など短い文が続くのなら良いでしょうが、20字をこえるような文が連なる文章をすべてセンタリングすると非常に読みにくいものになります。横書きの文章では左から右に読み、文章が終わると次の行の先頭に視線がうつるわけですが、次の行の先頭の位置が一定していないと読む際に多大な負担がかかるためです。見出しなど以外の平文の部分はセンタリングをしないほうがいいでしょう。

見出しなどをセンタリングしたい場合は、スタイルシートに下記のように指定します。

h2 {text-align: center}

この指定により、h2要素の見出しは全てセンタリングされます。

段落を表現する―PとBR

SS/FF作家の諸氏にとってもっとも馴染み深い要素がbr要素だと思います。であるにもかかわらず、これが強制改行という要素であることは意外と知られていません。そこのところを理解する必要があります。

段落はpでマークアップする

段落はp要素によって示されるべきで、行末にbr要素を付加することで表現するべきではありません。p要素とは、段落(paragraph)を表す要素です。

この文章は次のようにコーディングされてきました。

 その日、国際連合軍第三方面軍司令部は前代未聞の混乱に陥った。正体不明の物体―のちに使徒と呼ばれる物体の出現であった。統合参謀本部は方面軍司令部にただちに邀撃を指示、特務機関NERVとの協働によってことにあたるよう命令が下された。<br>

 同日1500、司令部は特務機関NERV本部施設内に、作戦指揮本部を設置、方面軍総監部は本部に指揮座を移した。しかし彼らを迎えたのは特務機関NERV首脳部の冷ややかな歓待のまなざしだけであった。<br>

この例では行頭に全角スペースが無意味に入っており（日本語に全角スペースという文字は存在しません。段落の行頭は一字下げするという慣習を全角スペースで表現してきていただけです）、また明確に段落であるにもかかわらず強制改行によって段落を表現している点が問題です。素直にp要素でマークアップすべきでしょう。

<p>その日、国際連合軍第三方面軍司令部は前代未聞の混乱に陥った。正体不明の物体―のちに使徒と呼ばれる物体の出現であった。統合参謀本部は方面軍司令部にただちに邀撃を指示、特務機関NERVとの協働によってことにあたるよう命令が下された。</p>

<p>同日1500、司令部は特務機関NERV本部施設内に、作戦指揮本部を設置、方面軍総監部は本部に指揮座を移した。しかし彼らを迎えたのは特務機関NERV首脳部の冷ややかな歓待のまなざしだけであった。</p>

文中強制改行は読みにくくするだけ

台詞の前後などを除いて、文中でbr要素による強制改行をしてはいけません。たとえば筆者が1行40字として40字ごとに改行を入れていても、36字しか表示できない画面から見れば、36字の行の次には必ず4字の行が入ってしまうからです。下に無理やりサンプルを示しますが、読む気をなくすのは請け合いです。

　台詞の前後などを除き、文中でbr要素による強制改行をしてはいけません。たとえば筆者が一行四<br />

十字として四十字ごとに改行を入れていても、三十六字しか表示できない画面から見れば、三十六字<br />

の行の次には必ず四字の行が入ってしまうからです。下に無理やりサンプルを示しますが、読む気を<br />

なくすのは請け合いです。<br />

これが筆者には次のように見えているとします。

ところが別の環境では次のように見えているかもしれません。

このような危険をあえて冒す必要はありません。文中での強制改行をわざわざするメリットはありません。もし横いっぱいに文章が広がるのがいやなら、スタイルシートにマージンを指定すれば良いだけの話です。

行間はスタイルシートで調節する

行間はスタイルシートで調整します。<br>を一行おきに入れるべきではありません。また、そうしていなくても行間をスタイルシートで調整しておくことは重要です。なぜなら横書きが基本のHTML上で行間がほとんどないと、非常に読みにくくなります。たとえば以下のような文章があるとします。

<p>その日、国際連合軍第三方面軍司令部は前代未聞の混乱に陥った。正体不明の物体―のちに使徒と呼ばれる物体の出現であった。統合参謀本部は方面軍司令部にただちに邀撃を指示、特務機関NERVとの協働によってことにあたるよう命令が下された。</p>
<p>同日1500、司令部は特務機関NERV本部施設内に、作戦指揮本部を設置、方面軍総監部は本部に指揮座を移した。しかし彼らを迎えたのは特務機関NERV首脳部の冷ややかな歓待のまなざしだけであった。</p>

上記の文章は行間を指定していない場合、多くは次のように表示されます。

かなり詰まって表示されているのではないでしょうか。そこでスタイルシートに次のように指定します。

p {line-height: 1.3em}

これで行の高さは、字の高さの1.3倍と指定したことになります（正確にはアルファベットのMの高さの1.3倍）。おおむね1.2emから1.6emくらいが読みやすいでしょう。以下がそのように指定した場合のサンプルです。

論理要素の誤用は避ける

論理要素とは、em（強調）やstrong（特に強い強調）のように、マークアップする部分に対し、論理的意味合いを与える要素のことです。そして、たとえばemは先ほど説明したようにInternet Explorerのデフォルトでは、イタリックとして表現されます。では、ある部分をイタリックにするためにem要素を使用することはよいのでしょうか。否、です。なぜならどのブラウザもInternet Explorerと同様にイタリックで表現するとは限らず、太字で表現するかもしれないからです。ですから、論理的な意味合いを持たせることではなく、見栄えのために論理要素を使用することは避けるべきです。

インデント１-blockquote

最多登場です。おそらくblockquoteのquoteの意味をわかってらっしゃらない方が非常に多いのではないでしょうか。quoteとは引用のことです。blockquote要素は（ブロックレヴェルの）引用を示します。すなわちblockquote要素でマークアップされた部分は、著者によるものではなく引用されたものであることを示すのです。

<blockquote>
  <p>……</p>
</blockquote>

この例では、……の部分は引用であるということを示しています。であるにもかかわらず、エヴァSS/FFの世界では、作品全体が……の部分に突っ込まれていることが非常に多いのです。これはその作品全てが引用であるといっているのです。せっかくのSS/FFなのに、意図していないにしろ、わざわざ引用であると宣言するのは、もったいないことですからやめましょう。それに作品に言及する際に実際に引用しても、あまりにblockquote要素が濫用されてしまっていると本当に引用であるかどうかが疑わしくなってしまいます。

さて、ここまでblockquote要素は引用を示す、と書いてきました。では実際にはどのように用いられるのでしょうか。それはほぼ間違いなく、blockquote要素は左マージンをとるために使用されています。SSやFFにおいて、blockquote要素を引用として用いている例は数えるほどしかみたことがありません。

ほとんどのブラウザは普通の段落（p要素）では左側にマージンを入れません。しかし、横書き文章で左マージンがないと圧迫感を覚え、非常に読みにくい。そこで目をつけられたのがblockquote要素というわけです。たいていのブラウザはデフォルトで引用部分は左側にインデントを入れて（一字下げして）表示するようになっています（これは印刷物と同様）。その結果、字下げしたいがために、引用ではないのに、引用である、ということを示すHTMLが書かれるのです。インデントのために作者自身が引用であると宣言するのは、本末転倒であり、あまり好ましいことではないでしょう。

マージンをとるのはスタイルシートで簡単にできます。特に文書全体に対してマージンを指定したいなら、body要素にマージンを設定してしまえばよいのです。

body { margin-left: 3em; margin-right: 3em;}

この指定で、文書全体に左右に3文字分のマージンが取れます。またこのスタイルシートを適用するすべての文書でマージンがとれますから、文書ごとに全文にいちいち引用などを指定する必要はありません。

インデント２-なぞのul

blockquote要素と同様に、インデントのために使用されます。しかしul要素は順不同のリスト、すなわちいわゆる箇条書きを示します。以下のように使用します。

<ul>
  <li>箇条</li>
  <li>箇条</li>
  <li>箇条</li>
</ul>

各箇条をli要素としてマークアップし、リスト全体をul要素とする、という使い方をします。これをブラウザを通すと次のようになります。

もしあなたがデフォルトの状態でInternet Explorerを使っているなら、リストの部分にインデントがついていることがわかると思います。メジャーなブラウザはデフォルトの状態なら、たいていインデントをつけるというだけのことですが、そのために左マージンのかわりに使われてしまうことがあります。しかしul要素の直下には一つ以上のli要素が必要です。li要素を使用しないで、全文をul要素とするようなことが行われていますが、これは誤りでli要素なしのul要素は完全な文法違反です。やめましょう。

そもそもブラウザはリストにふさわしく表現すれば良いわけで、ul要素で全文を囲ったからといって、必ずしもインデントされるとは限りません。変な挙動をするブラウザでは全ての段落の前にリストのマーカーをつけてしまうかもしれません。

インデント３-dl,dt,dd

こちらもblockquote要素と同様に、インデントのために使用されます。そしてやはり誤用なのです。このセットは定義型リストと呼ばれます。主に用語集などで用いるとされています。以下にように使用します。

<dl>
  <dt>用語１</dt>
  <dd>説明１</dd>
  <dt>用語２</dt>
  <dd>用語２</dd>
  <dt>用語３</dt>
  <dd>説明３</dd>
</dl>

dt要素の語句をdd要素で説明するということを繰り返すリストです。そのために定義型リストと呼びます。ブラウザを通してみると次のようになります。

もしあなたがデフォルトの状態でInternet Explorerを使っているなら、リスト全体、および用語の部分、説明の部分それぞれにインデントがかかっているのがわかると思います。定義型リストもblockquote要素同様の誤用がなされます。すなわちこのインデントを利用して、左マージンを取るために使うという誤用です。

dl要素にはdt要素、dd要素のいずれか最低一つ以上を含まねばなりません。さらにdl要素直下には、dt要素かdd要素しか含むことができません。逆にdt要素やdd要素の親要素はdl要素以外許されません。したがって全文を<dl>〜</dl>にいれて左マージンを取ろうとしてはいけません。同様にdl要素がないにもかかわらずいきなりdt要素やdd要素を出現させて、全文すべてについて<dt>〜</dt>や<dd>〜</dd>にいれて左マージンをとってもいけません。

すべては太字のために-全文strong

すでに説明しましたが、strong要素は、特に強い強調を示します。その結果、ブラウザはたいてい太字にするわけです。さて、ここまで口を酸っぱくしていってきましたが、太字にするためにstrong要素を使うべきではないのです。強調したい部分をマークアップするのです。だいたいstrong要素が全てのブラウザが太字で表現するかどうかはわかりません。strong要素をどのように表現するかはブラウザに任されています。

では誤用例を説明しましょう。全文を太字にしたいとどうなるか。帰結は当然、以下のようになります。

<strong>

  （全文）

</strong>

全文を非常に強調したいというのはそもそも稀でしょうし、論理的には地の文があって、それに対し相対的に強調したい部分をマークアップするのがstrong要素です。したがって、全文をマークアップする必要はどこにもありません。全文を太字にしたいならスタイルシートに次のように指定すればよいのです。強調でもないのに太字にするのはお勧めしませんが。

* { font-weight: bold;}

誤用じゃないけどできればやめてほしい全文PRE

これまでとは違って誤用例ではありません。HTMLにはpre要素という要素が存在します。これは整形済みテキストを指します。改行はHTML上では単なる空白文字として扱われますが、pre要素内では改行してあれば、それをそのまま反映して改行して表示されます。

1行40字程度としてテキスト文書を整形し、これをpre要素の中に放り込んでしまえばいいのです。実にお手軽で、メールをHTMLにするときや、プログラムコードを示す時によく使われます。

ただいくつかはデメリットがあります。まず、改行は必ず改行した場所でするという制約があります。つまり四十文字目に改行するルールで書いてあると、一行三十六文字しか表示できないディスプレイで見ていたり、ウィンドウを四十文字以下にしたとき、横スクロールバーが出現して読むのに苦労することでしょう。pre要素は横幅を固定します。常に横スクロールバーの危険性と隣り合わせということは記憶してよいでしょう。

また作者が一行おきに文章を書いていたりするときは、あまりにすかすかした行間に読者が疲れるのは目に見えています。またさまざまなサイトを自分好みのスタイルで読むためにユーザースタイルシートを設定していても、一行空きのpre要素と空かずのpreが混在すると行の高さを調整しても必ずどちらかが読みにくくなります。このような不都合が生じますので、便利ではありますが、濫用を避けて欲しい要素です。

見栄えはスタイルシート で制御する

現在用いるべきHTMLで見栄えを制御することはできません。HTMLにできるのは、ここからここまでが見出しであり、ここからここまでが段落である、ここからここまでは強調する、といった論理的構造を示すことだけです。しかし、これはそれほど難しいことではないでしょう。おそらく論理構造のみを記述したHTMLを書くことで、想像以上に簡単でシンプルなソースが出来上がることと思います。そのHTMLをUAに通すと、無愛想かもしれませんが、わかりやすい出力が得られるはずです。

ただしスタイルシートを使って、よりわかりやすくするために、見栄えによってさまざまな要素を表現することはできます。以下は、スタイルシートの記述法を簡単に示します。慣用されてきた見栄えに関わるHTMLでの指定をHTMLから排除し、必要であればスタイルシートで代替する方法を前章までに説明しましたが、詳しくは以下を参照してください。

もっとも、スタイルシートを適用しなくても、閲読にまったく支障のないHTMLを書くように常に気を配るべきです。スタイルシートを扱えないブラウザは多数存在します。HTMLで論理構造だけを示しておけば、視覚的表現力におとるブラウザでも、比較的よい出力を得ることができるでしょう。一方で、いい加減なHTMLを書いていると（たとえば後述するように引用でない箇所を引用とマークアップしていたりすると）どのように出力されるか想像もつきません。ですからスタイルシートを適用しないと、なにが書いてあるかわからないようなHTMLを書いてはいけません。限りなくシンプルなHTMLを書くことは、古いブラウザを含めた全てのUAにも優しいものといえるでしょう。

HTMLへのCSSの適用

では、あるHTMLにスタイルシートを適用したい時はどのようにすればよいでしょうか。HTMLへのCSSの適用の方法は主に三つあります。

1. 外部にスタイルシートのファイルを作り、そこへのリンクをはって適用する。
2. head要素内にそのHTMLファイルでのスタイルシートのルールを記述する。
3. 各要素へstyle属性を指定する。

この中で私がお勧めするのは、一つ目の方法です。その理由は、サイト内の全てのHTMLで同一のスタイルシートのファイルにリンクすることで、サイトのデザインを統一的に管理でき、デザインのメンテナンスが非常に用意になるためです。この方法を使っていれば、たとえば文字色が読みにくいので変えて欲しいという要望があれば、スタイルシートファイルの文字色の指定を変えるだけで、そのスタイルシートにリンクしている全てのHTMLで文字色を一括して変えることができます。これがスタイルシートの最大の利点です。

これに対して、二つ目の方法では、そのHTMLファイル内だけしか統一がとれませんし、デザインを変更したい時は全てのHTMLファイルをいじらなくてはなりません。三つ目の方法では、さらに要素ごとに指定を変えねばなりません。これは不合理です。ですから一つ目の方法をお勧めするわけです。

「リンクをはる」というのはHTMLのhead要素内にlink要素で記述するということを指します。具体的には下記の例のようになります。

<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" href="/css/annexe1.css" type="text/css" media="screen" />

一行目の指定は、そのファイルにおいて用いるスタイルシートの言語はCSSであるということを示しています。これは本来WWWサーバが返すHTTPにおいて指定されるべきものですが、HTTPヘッダの設定（要は.htaccess）をいじくる権限をくれるISP（いわゆるプロバイダ）は少ないようなので、とりあえずいれておくのが吉でしょう。

二行目の指定が、「リンクをはる」という行為です。rel属性、type属性はこのままで問題ありません。href属性ではa要素のリンクのときと同様に指定します。最後のmedia属性はそのCSSファイルを適用するメディアを指定します。

CSSの書法とプロパティについて

本節では、具体的なCSSの書き方を解説します。かなり生半可ですから、きちんとしたCSSリファレンスや解説（たとえばKatsuさんによるCSS Reference – K@tsukun’s PAGE!）を適宜参照してください。例を下記に示します。

p {text-indent:1em; margin-bottom:1em;}

このとき一番初めのpをセレクタ、{}で囲まれた部分をプロパティといいます。ひとつのセレクタに対し、複数のプロパティを指定することができ、その区切りは;（セミコロン）です。またプロパティ内部ではtext-indentなどをプロパティ名、1emなどをプロパティの値といいます。プロパティ名と値の区切りは:（コロン）です。

セレクタ

セレクタはプロパティに指定したものをどの要素に適用するかを示します。上記の例では、p要素全てにたいし、text-indent:1emとmargin-bottom:1emが適用されます。

また汎用属性classにたとえばasukaが指定された全ての要素に適用したい時は次のように書きます。

.asuka {color: red;}

汎用属性classにasukaが指定されたp要素（<p class="asuka">〜</p>）に適用したい時は次のように書きます。

p.asuka {color: red;}

さらに文脈上の指定も可能です。下記の例ではblockquote要素（引用）の中にあるp要素はフォントサイズを平文に比べて0.9emにせよ、ということです。区切り子はスペースです。

blockquote p {font-size: 0.9em;}</code>

セレクタにはまだまださまざまなものがありますが、CSS1という現在Internet Explorerが完全に対応している（とMicrosoftが主張している）CSSでは上記が完全に実用的です。その他のセレクタとブラウザの実装状況についてはレファレンスを参照してください。

プロパティ

CSSのプロパティには実にさまざまなものがあります。ここでは、今までに述べたものも含めて、SSやFFを書く上で、必要そうなプロパティを紹介します。ここでは非常に端折って紹介しておりますので、必ず正確なレファレンスを参照してください。

margin

マージンは非常によく使うことになるでしょう。多くのブラウザではCSSに何も設定しないと、左マージンをとりません。これがblockquote要素を誤用させる原因になっています。左マージンはあるていどあった方がいいので、HTMLの内容全体に左マージンをかけましょう。

body {margin-left:3em; margin-right: 3em;}

text-indent

text-indentはブロックレヴェル要素の一行目において、どれだけ字下げをするかを指定します。日本語の段落は一字下げが基本ですので、このプロパティは必須といえるでしょう。p要素は一字下げします。

p {text-indent: 1em;}

font-size

font-sizeは、ある要素（インライン・ブロックにかかわらず）について、表示するフォントの大きさを決定するプロパティです。HTMLにおいてfont要素で調整していたサイズはCSSにおいては、このプロパティを用います。

p {font-size: 1.5em;}

上記の指定は、p要素に対し、1.5emのサイズを適用するということです。

font-weight

display

ぜひ指定したい印刷用スタイルシート

リンクナヴィゲーションを用意する

一般にあまり知られていませんが、HTMLには、link要素によってHTML文書内に、他の文書との関係を明示的に示すという機能があります。たとえばevass02.html（タイトルはエヴァンリオンSS 第二章）のhead要素内に以下のように記述します。

<link rel=" href="/evass01.html" title="エヴァンゲリオンSS　第一章" />
<link rel="next" href="/evass03.html" title="エヴァンゲリオンSS　第三章" />

これは文書の前後関係において、この要素が記述された文書（つまり第二章のファイル）からみて、前の文書はevass01.html（エヴァンゲリオンSS　第一章）であり、次の文書はevass03.html（エヴァンゲリオンSS　第三章）であるということを示しています。ほかにも「上へ」や「最初」「最後」「索引」「目次」「検索」「著作権表示」なども示せます。

一見して非常に便利だと思います。ナヴィゲーション用のlink要素が記述してあるページははなはだ少ない状況です。その原因は単純で、これまでメジャーなブラウザではLynxなど以外にこれを生かす機能がついていなかったためです。しかしMozilla 0.9.5ではじめてナヴィゲーション・ツールバーとしてこの機能が実装されました（Netscapeの次か次の次のヴァージョンでも実装されるでしょう）。たとえば上にあげた例のようにしてMozilla 0.9.5以降で見ると次のようなリンクナヴィゲーションバーが表示されます。

出力例

一つの文書を複数のページに分けているサイトでは、それぞれのサイトごとにどこにナヴィゲーション用のリンクがあるかをいちいち探さなければいけませんでしたが、Mozillaではナヴィゲーションがツールバーとして表示されるので、「戻る」や「進む」と同じ感覚で利用できます。ユーザーのために書かれる連載もののHTMLにはぜひリンクナヴィゲーションを備えておいていただきたいものだと思います。

HTML Validatorで確認する

Validatorにはこんなものがある

逃げちゃダメだ！―呪文としての文書型宣言

Validatorは文書型宣言にしたがって、それぞれのHTMLが文書型宣言で明示されたヴァージョンのHTMLとして妥当なものであるかどうかをチェックして行きます。またブラウザもこれと同様ですから、宣言されたヴァージョンのHTMLにない要素があったりすると、解釈に混乱を引き起こすことになります。正しい文書型宣言をしていない限り、Validatorは役に立たないと考えるべきです。

では、文書型宣言とはなんでしょうか。HTMLにはいくつかのヴァージョンがあります。そのヴァージョンを示すのが、HTMLの冒頭に書かれるべき文書型宣言です。言い換えれば、そのHTMLがどのDTD（文書型定義・HTMLの仕様書ともいえるべきもの）にしたがっているかを示すものです。これを間違えると正しく解釈されないおそれがあります。また文書型宣言がなければただのテキスト文書と解釈されても仕方がありません。HTMLにおいて文書型宣言は必須です。さらに、その文書のマークアップが宣言したい文書型に適合しなければ、文書型宣言を宣言することはできません。文書型宣言が必須であり、正しいマークアップがなされないかぎり文書型宣言をしてはいけないわけですから、HTMLは正しくマークアップするべきなのです。

そういうわけでHTMLの冒頭には必ず文書型宣言をしなくてはなりません。

では以下にメジャーなHTMLの文書型宣言の例を掲げます（かなり広く普及していますがHTML 3.2では日本語を使うことはできませんので、省略します）。

HTMLi18n

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML i18n//EN">

HTML 2.xとも呼ばれます。最初の普及版HTMLであるHTML 2.0を国際化して、さまざまな文字コードを使えるように拡張したものです。このヴァージョンはかなり古く、歴史的な代物とされているので使うべきではありません。また<font>や<table>などのかなりの要素がこのヴァージョンには存在しないので気をつけてください。

HTML 4.01 Strict

<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01には三つのDTDが存在します。その一つ目がStrictといわれるものです。その名の通り、厳格かつ簡潔なHTMLを旨とします。はじめからHTMLを書くなら本ヴァージョンがお勧めです。<font>などの要素は非推奨で、許容されません。またフレームも使えません。

HTML 4.01 Transitional

<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01には三つのDTDが存在します。その二つ目がTransitionalといわれるものです。これは後方互換性を重視したヴァージョンで、非推奨要素も許容されます。フレームは使えません。

HTML 4.01 Frameset

<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">

HTML 4.01には三つのDTDが存在します。その三つ目がFramesetといわれるものです。これからフレームを使用する場合は必ずHTML 4.01 FramesetかXHTML1.0 Framesetを使用する必要があります。ただしフレームによって呼び出されるHTMLがFramesetで書かれている必要はありません。

ISO/IEC 15445:2000/COR 1:2002(E)

<!DOCTYPE HTML PUBLIC "ISO/IEC 15445:2000//DTD HTML//EN">

HTML 4.0 StrictをもとにISOによって制定された国際標準規格のHTMLです。HTML4.01 Strictよりさらに厳格です。「ISO/IEC 15445:2000/COR 1:2002(E)」の前版「ISO/IEC 15445:2000」の日本語版「JIS X 4156:2000 ハイパテキストマーク付け言語（ＨＴＭＬ）」があります。文書型宣言は同様でかまいません。

XHTML 1.1

<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja-JP">

最初の一行はxml宣言、最後の一行はhtml要素に対するXML名前空間の表示です。真ん中の三行が文書型宣言です。XHTML1.1は、HTML4.01 Strictの後継ヴァージョンです。なおこのヴァージョンで、HTML 4.01での非推奨要素はかなり廃止されました。したがって、<font>や<center>などの要素は定義されていないため、使用することはできません。

XHTML Basic

<?xml version="1.0" encoding="Shift_JIS"?>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja-JP">

最初の一行はxml宣言、最後の一行はhtml要素に対するXML名前空間の表示です。真ん中の三行が文書型宣言です。XHTML BasicはXHTMLの各モジュールのうち高度なレンダリング能力を必要としないもののみを使用したヴァージョンで、携帯電話などからの閲覧が想定されています。外部スタイルシートを適用することができますので、高度な表組などを必要としないSSのような簡易な文章ではディスプレイから閲覧する場合でも、これで充分かもしれません。NTT DoCoMo i-mode HTMLはきわめていい加減な規格ですが、こちらはきちんとしたもので、NTT DoCoMo i-mode HTMLをはじめとした携帯電話でみることを想定した各社独自のHTMLもどきもやがてXHTML Basicを基本としたWML 2.0に切り替えられることになっています（WMLの文書型宣言はXHTML Basicとは別）。携帯電話からの利用も想定するなら、これを使うことを推奨します。詳細は、XHTML Basic – 多様な端末を念頭に置いたXHTMLの共通分母（神崎正英さん）や、XHTML Basic仕様書（W3C）を参照してください。

上記のような文書型宣言を文頭に書きましょう。そのうえでvalidatorにかければ、問題点が非常にはっきりすることでしょう。これからHTMLを書く場合、HTML i18nを除くいずれのヴァージョンを使っても、DTDに適合的なHTMLを書けば問題ありませんが、将来への流れを考えるとHTML 4.01 StrictかXHTML1.1、XHTML Basicを使用するのが現実的であろうと思います。

いま手がけている文書をためしにHTML 4.01 Strictとして宣言し、validatorにかけてみてください。もしエラーが大量にでてくるようなら、わりと古いHTMLの作法で書いているということを自覚したほうがよいと思います。

文字コードは正確に

文字コードは正確に指定しましょう。本来はHTML内ではなく、サーバのHTTPヘッダによって指定するべきですが、一応HTMLでもhead要素内にmeta要素を使用して指定しておきましょう。

<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS" />

charsetの部分は、使った文字コードがEUCならEUC-JP、いわゆるJISコードならISO-2022-JPを指定します。この部分の指定が、使った文字コードと一致していない場合、文字化けを起こす可能性があります。

余談ですが、Shift_JISコードやEUC-JPコードにおいて、半角カナを使用することはなんら問題ありません（ゲンドウ用）。

またいかなる文字コードを使用していても、文字実体参照によって文字としてハートマーク(♥＝&hearts;)を表現することもできます。つまりハートマークを入れたい場所に&hearts;と書けばよいのです。たとえば以下のようにコーディングします。

<p>シンジっ、大好きよ&hearts;</p>

このようにすれば次のように表示されます。

img要素を使って文中で無理やり表現するよりましでしょう。詳しくは水無月ばけらさんによるHTML4 で使える文字実体参照を参照してください。

Validatorに頼り切らない

というわけで、ここからさきはいかに文書の論理構造性を強くしていくか、という話ですから、突き詰めようとすればするほど、「目」でみて確認してしまうという習性の限界を感じます。それでもいざ先にすすまんという方は、HTML-lintで100点なら良いのかを参考にして考えていくとよいでしょう。

テキストブラウザで確認する

インターネットリソースの意味と概念を理解する

本章ではインターネットとりわけWWW上の資料の性格について論じます。エヴァンゲリオンSS/FFの世界では、いかがなものかという考え方が常識とされていることに、私は驚きました。本章では、特に公開ということの意味を、インターネットの「公」と関連して考えます。ここまで技術論的にHTMLを論じてきましたが、本章はその技術の裏づけとなる思想について論じる本稿のコアともいうべき部分です。ぜひ読んで理解してください。

可能な限り安定的に供給する

Webサイトの流動性の激しさは、驚くほどのものがあります。ある著作を参照したいとき、書物であれば、著者『書名』出版社,出版年、という形で言及すれば、その書物はほぼ特定されます。しかしながらWeb上のリソースは、URIを提示しても、必ずしもそのURIに参照したいリソースがあるとは限らないというのが現状です。

SSであろうと、SSへのリンク集であろうと、それは著作物で、著作者によって世界に公開された貴重な情報提供です。そして、その情報を自由に批評し、参照することが容易であるのが、インターネットの利点です。ところがURIとリソースの同一性が安定的でないということが、この利点を削いでいます。

サイトという幻想を捨てる

インターネット上では一つ一つのリソースが、リンクによってつながっています。ごくごく当然のことのように思えますが、これは非常に大切なことです。

つまり「サイト」といっても、それは、あるリソース群が比較的緊密な内容的繋がりをもってリンクで結ばれているだけだということです。言い換えれば、HTMLファイルひとつひとつが独立したリソースであって、それぞれに著作者を明記するような物であるということなのです。

「サイト」の幻想を捨てれば、閲覧者にとっての利便性も向上します。

たとえば、Webサイトを持っている作者は、自分の書いたSS/FFの一覧と、それぞれへのリンクを張った文書を提供するとよいでしょう。現状では、ある作者の著作が一つのサイトに集中していることは非常に少なく（これは後述する「投稿」の問題によるものですが）、ある作者の著作を網羅的に閲覧するのは、非常な困難を伴います。各著作へのリンクを用意した一覧を提供すれば非常に容易になります。

そして重要なのは、投稿先のサイトトップにリンクを張るのではなく、著作自体にリンクを張ることです。Webとは蜘蛛の巣なのです。AというHTML文書は、あるサイトBにある作品としてリンクされるだけではなく、作者Cの著作一覧、第三者Dによる「E」というジャンルの著作一覧、あるいは第三者Fによる「好きな作品」の一覧の中からリンクされてよいのです。HTML文書がひとつひとつ独立して意味を持つというのは、そのような意味です。このような自由さこそがWebの利点なのです。これを捨ててはいけません。

したがって、後述するトップページにしかリンクを張ってはいけない、というような要求は不当なのです。

ケーススタディ「投稿」

エヴァに限らず、Web小説の世界では、「投稿」という現象があります。これは、ある人物Ａが書いた著作を、他の人物Ｂの運営する「サイト」に公開してもらう行為を言います。「投稿」という現象は、おそらく小説雑誌への「投稿」がその起源となっていると思われます。この場合は、一般個人に、出版する能力がないため、出版社に「投稿」し、それを掲載した雑誌を刊行してもらうというシステムでした。Web小説の場合は、次の二つのパターンに分けることができます。

• Webサイトを持たない作者が、関連分野のWebサイトに「投稿する」
• Webサイトを持つ作者が、なんらかの目的で、他のWebサイトに「投稿する」

前者の場合は、先ほど挙げた作家と出版社の間の「投稿」と全く同じ構造です。しかし後者は違います。後者の場合、出版社が出版社に投稿するということになります。ここで問題にするのは、この後者のパターンです。

このパターンで一番の問題点は、閲覧者に余計に負担をかけることです。ある作者Aの書いた作品を読みたかったとしましょう。検索サイトで作者Aを検索し、作者Aのサイトに行きます。そして著作リストを見て、読みたいと思った作品がありました。しかし「B」なるサイトに投稿してあるそうです。そこで「B」というサイトに行きます。そして今度は「投稿作品一覧」を見ます。さらに「A」の作品群へ。ここでようやく目当ての作品を見ることが出来るのです。これは明らかに余計な負担でしょう。

さらに投稿の場合、作者が作品内に明確に訂正すべき箇所を見つけていたとしても、投稿先のサイトの管理者にお願いして、訂正したものを再アップロードしてもらわねばなりません。これは管理者の負担を増やしていますし、メンテナンス性が低下することにつながっています。また、投稿先のサイトが後述するように閉鎖されてしまう場合も、投稿作者の意向はあまり反映されません。

したがって、自分のサイトを持っている場合は、投稿はできるだけ避けるべきではないでしょうか。

ケーススタディ「閉鎖」

2002年に入って、かなり多くの「サイト」が閉鎖されています。その理由はさまざまなのですが、Web上にリソースを提供した以上、それが「公開」であるということを常に念頭におくべきです。一度出版された書物を物理的に全て消去するのは非常に困難です。Webリソースは、これとはちがって、公開停止を作者の意図ですぐにできます。しかしながら、たとえばInternet ArchiveやGoogleのキャッシュに保存されて閲覧できる場合は少なくありません。したがって気軽に「公開」し気軽に「閉鎖」できるという感覚は思いこみです。安易な閉鎖は、公開していた情報を消去するという意図を達成できないだけでなく、Webリソースそのものの信頼性を失わせることになるだけです。

「メンテナンスができなくなった」「更新が続けられなくなった」などの理由で閉鎖されるWebサイトがあります。しかし昨今では、無料のWebサービスなども増えています。継続したメンテナンスに自信がなければ、そちらにサイトを公開し、置いておけばいいのです。そのように考えるために重要なのはメンテナンスや更新は書物と異なるWebの特権であり義務ではないということです。メンテナンス、更新が継続されるのは、もちろん好ましいことですが、それができないので閉鎖というのは、あまりに短絡的です。著作物は著作物として評価されるべきであり、その更新可能性やサイトの附随情報によって評価されるべきではないのです。

World Wide Webは、情報が蓄積され続けるという利点があります。公開するということは、公に自分の持っている、あるいは創作した情報を世界で共有すると言うことなのです。ある時点で興味があり、ある時点で興味がなくなった事項については、放置すればよい、そのように考えてください。公開した本人にとって価値がなくなった情報でも、誰かにとって価値がある可能性は、非常に大きいのです。

リンクは自由である

リンクは自由であるべきです。「リンクはトップページに」や「無断リンク禁止」はインターネットリソースの概念上、意味のあるものとは思えませんし、むしろ有害です。リンクをするという行為はリンクをされる側に対する言及行為です。名誉毀損などの問題が無い限り言及は自由であるべきで、それが規制されることは望ましくありません。リンクに関する考え方は、東北大学の後藤斉さんによるリンクについて「リンクは自由!」を参照してください。

サイトの構造変更などでファイル名が代わったりする危険性の回避のために、リンクをトップページに張るよう要請することは不当なことではありませんが、「可能な限り安定的に」という目的から、それほど好ましいとは思えません。URIは、あるリソースに対し、一意であるべきです。

「サイトという幻想を捨てる」で、すでに言及したとおり、ハイパーリンクによって、著作はさまざまな形で参照されることで、その力を発揮します。ある作者の著作一覧、あるジャンルの著作一覧、ある人物の活躍する著作一覧など、いろいろな形の参照が想定できます。そしてあるサイトに存在する著作一覧は、そのうちの一つに過ぎないのです。「トップページのみリンク可」は、そのようなリンクのあり方を阻害するものです。

address要素で著作者を明確にする

最後に技術論に立ち戻ります。ここまで論じてきたようにHTML文書は、そのファイル一つで独立したインターネットリソースです。したがって「サイト」は同一管理者によるある程度のまとまりをもった文書群であるにすぎません。サイト内のある文書を読んだ読者が、必ずしもトップページ（index.htmlなど）を参照するとは限りません。現に私のサイトでも日記のページの合計ヒット数は、トップページの二十倍を超えます。

そのように考えると各文書で、文書に対する責任として最低限、連絡先を明記すべきです。このような用途に用いるためにHTMLにはaddress要素が用意されています。各文書の末尾なりに名前とメールアドレスをaddress要素としてマークアップしてください。address要素は文書型宣言と同じくらい重要だと思ってください。

<address>
2002 © hogehoge(<a href="mailto:hogehoge@hogehoge.com" title="作者にメールを送る">hogehoge@hogehoge.com</a>)
</address>

おわりに

有用サイトへのリンク一覧

日本語における意味段落・形式段落とHTMLにおけるBR要素・P要素

はじめに

本章は付録です。

これまで縷々述べてきたようにHTMLとは、文書の論理構造を人間と同時にコンピュータにも理解しやすい形で記述するための一つの手段です（我々はHTMLそのものを読んでいるわけではなく、UAが解釈したHTMLを、これまたUAの手を借りて画面に表示させたり、音に出して読ませたりして、それを「読んで」いるに過ぎません）。そして、それに応じてさまざまな要素が用意されています。

HTMLの要素を俯瞰して感じられるのは、記述される文書は見出し（Hn）、パラグラフ（P）、強調（em, strong）、引用（blckauote, q）などから構成されるというのが基本になっているということです。これは自然言語においてもきわめて論理性が強く表に出るマニュアルや仕様書、論文などに向いています。しかし小説、特にFFなどの分野の文章が果たして論理的な自然言語の文章を前提として要素が用意されたHTMLで記述されるべきかどうかは疑問が残ります。特に段落の取り扱いには注意を要するのではないかと考えます。

ここまで本稿では、HTMLとしての妥当性を強調してきました。いずれもHTMLとして記述する以上守るべきことです。しかしHTMLにも器というものがあり、全ての自然言語の文章を完全にマークアップするには程遠い代物です。本章では、日本語の小説をHTMLで記述するということで必然的に発生するであろう問題点、段落と改行の取り扱いについて論じます。

FFと段落

これまでFFを数多く読んでいない方でも、いくつかの作品を読むだけで、一段落がきわめて短い、という特徴を読み取ることができるでしょう。一行四十字としても二行を超えることは稀で、一文をもって一段落としている場合も別になんら珍しくはありません（なお、これはネットワーク上のFFに限ったことではなく、少年少女向けの文庫、特に表紙がアニメっぽい絵で描かれた小説でも同様で、紙面の下半分がまっ白に近いのを目にすることができるでしょう）。これも日本語の文章の一つのスタイルと考えられます。ここで思い起こすべきは意味段落と形式段落という言葉です。

意味段落とは意味的に一つのまとまりを持った文章の集まり（ここでは話しの流れ）、形式段落とは、意味的には前後の段落と一つのまとまりをもっているにもかかわらず、なんらかの理由で前後（まとは前・後）が改行され、結果として視覚的に段落として表現されているものをいいます。うまい文章ではありませんが、たとえば以下の例ではどうでしょうか？

空が、重い。

この街にきてから、もう三年。
いつまでたっても雪が降り出す前の、この灰色の空に慣れることができない。
道を行き交う人もみんなコートの襟を立てて足早に去ってゆく。
こんな北の街でも、あの頃は一年中半袖で過ごすことができたなんて。とても信じられない。
寒い。気分が重い。フッと吐いた息が白かった。
白と黒と、そして灰色。モノトーンの街だ。
もともと気分が浮き立つ要素がないのに、街の雰囲気が私の重い気分に追い討ちをかけた。
本当は、好きな街なのに。
でも、もう疲れた。

三年前まで日本中は夏だった。
たとえ北海道といっても、三年くらいでは「冬」への慣れることがでてくるわけじゃない。
電力会社にもガス会社にも公共交通機関にも「雪」への経験を持つ担当者が圧倒的に不足していたせいかライフラインはずたずた。

三つの意味段落と、十三の形式段落があるのが一見してお分かりになると思います。この文章で意味段落のみを表現すると次のようになります。

 空が、重い。

 この街にきてから、もう三年。いつまでたっても雪が降り出す前の、この灰色の空に慣れることができない。道を行き交う人もみんなコートの襟を立てて足早に去ってゆく。こんな北の街でも、あの頃は一年中半袖で過ごすことができたなんて。とても信じられない。寒い。気分が重い。フッと吐いた息が白かった。白と黒と、そして灰色。モノトーンの街だ。もともと気分が浮き立つ要素がないのに、街の雰囲気が私の重い気分に追い討ちをかけた。本当は、好きな街なのに。でも、もう疲れた。

 三年前まで日本中は夏だった。たとえ北海道といっても、三年くらいでは「冬」への慣れることがでてくるわけじゃない。電力会社にもガス会社にも公共交通機関にも「雪」への経験を持つ担当者が圧倒的に不足していたせいかライフラインはずたずた。

いかがでしょうか。すでにお気づきであろうと思いますが、p要素のpとはparagraphの頭をとったものです。paragraphとは、一つの意味的なまとまりをあらわす文の集合ですから、上記の例では、意味段落により近いといえるでしょう。したがって、HTMLでは、後者の例の場合に、それぞれの意味段落をp要素で示すだけでよいのです。前者の場合は、形式段落をあらわす要素がないため、マークアップのしようがありません。

形式段落は不要か？

たとえば神崎正英さんは次のように述べています。

いろいろなところで「論理マークアップ」とか「文書の構造を示すHTML」と言われますが、そのためにはマークアップの対象となる文章そのものが論理的にきちんと構成されていなければなりません。見出し要素タイプや段落要素タイプがうまく使えないのは、文章がそもそも論理的に書かれていないことに原因がありそうです。

まず分かりやすい論理の文章を書く。そして、それをどんな環境でも理解できるように、適切な要素タイプでマークアップする。文章の論理がしっかりしていれば、hn要素タイプとp要素タイプだけで的確なHTML文書を作ることができます。HTMLの些末な用法に頭を使う前に、伝える内容を分かりやすく表現することにエネルギーを注ぎましょう。

まったくもって正論です。同時に次のようにも述べています。

パラグラフは意味の単位であるという考え抜きに“行を変える”という見かけだけを「形式段落」なんぞとしてしまうから、「意味段落」という無理な概念が必要になって小学生を悩ませる。最初から“ひとまとまりの考えを段落として区切って書く”とすれば、こんな奇怪なことにならずに済むものを。

HTML上では、形式段落を表現することはきわめて難しいですし、確かに文章の論理性を重視する立場からは、日本語における形式段落の存在も批判の対象でしょう。

しかしながら、全ての文章は皮相な形式合理性のみに基づいて論理的に構成されるべきものなのでしょうか。特に小説などもそのように構成すべき文章なのでしょうか。そうではないでしょう。小説や詩文では、改行によって一定の「リズム」や「雰囲気」を出すという手段が存在しています。

さらに私は、少なくとも自然言語としての日本語には日本語の文芸として培われてきた伝統があり、その中で意味段落のみで文章は整形されるわけではなく形式段落によっても整形されるという慣習が存在する（たとえば論理的に前後の文章が一まとまりであっても、台詞があれば、その前後で改行を行い、形式段落を形成する）と考えています。それが、作法です。そして、日本語での文芸である以上、小説では形式段落を重視するのは当然で、論理的なわかりやすさのみを追求すべきではないと考えます。

上記の神崎さんの考え方は、HTMLや論文から出発した考え方で、その限りでは正しいものです。しかし小説から出発した時、この考え方が全て妥当するとは言えません。自然言語をコンピュータにも理解しやすいように記述する道具としてのHTMLは不完全なものなのです（なぜなら日本語の小説や詩文における形式段落を適切にマークアップする手段がないからです）。そして自然言語としての日本語で書かれた小説に形式段落は必要なものです。

弥縫策

前節に述べたようにHTMLにおいて、日本語の小説の意味段落と形式段落を適切にマークアップする要素は存在していません。したがって、小説をHTMLで記述するときは、日本語の小説における作法の正しさと、HTMLにおける妥当性の双方を完全に満足させることは不可能と考えるしかありません。

しかしながらHTMLとして記述し、それを解釈するUAによって表現されることを前提とする以上、HTMLの仕様に違反すること（たとえば意味段落に形式段落を包摂させようとしてp要素を入れ子にするなど）はしてはいけません。なぜなら正しく解釈され、正しく表現されることが、期待できなくなるからです。そこで本節では、HTMLでの妥当性を満足させつつ、それにあわせて小説の段落をどのようにHTMLにあわせて妥協させていくかを論じます。

その方法は、伊藤悠さんによる分類に従えば下記の三類型四パターンが存在します。なお、以下で伊藤さんのいう「段落の塊」とは本稿での意味段落に近いもの、「段落」とは形式段落に近いものです。

1. 段落を表示するために<br>タグを、「段落の塊」を表示するために2つの<br>タグを使う。
2. 段落を表示するために<br>タグを、「段落の塊」を表示するために<p>タグを使う。
   1. 段落を表示するためにCSSで行空け属性を抑制した<p>タグを、「段落の塊」を表示するために一行空け属性をもたせた<DIV class=”hogehoge”>タグを使う。（中略）
   2. 段落を表示するためにCSSで改行属性を持たせた*3<DIV class=”hoehoe”>タグを、「段落の塊」を表示するために<p>タグを使う。（以下略：引用者）

この際、どれを用いればよいのでしょうか。第一の方法は無意味に強制改行を連発するだけなのであまり好ましくありません。形式段落にしろ、意味段落にしろ、なんらかの形でマークアップすべきです。

結論から申し上げると、形式段落はあえて表現しないほうがよいのではないか、と私は思うのです。形式段落はパラグラフからは程遠いものですから、それをp要素でマークアップするような3-1のような方法は日本語的コンテクストにおけるHTML解釈の独自拡張に近いといえます。また3-2の方法は、p要素の中にはブロックレヴェルの要素であるdiv要素を包含することになりますが、これはHTMLの文法に違反することになりますから採ることができません。

残るのは、2と3-3ですが、2の場合は強制改行をいれているだけで、形式段落自体はマークアップできていませんし、スタイルの指定もあまりできません。そういうわけでおそらく3-3が穏当でしょう。

3-3の方法を採った場合、CSSを理解するブラウザにはそれらしく表示され、理解しないブラウザは完全に無視し形式段落の部分で改行せずに表示します。以下にまずHTMLのソースの例を示します。

つづいてCSSのソースの例を示します。

以下はCSSを適用しなかった状態です。

以下はCSSを適用した状態です。

これがおそらくは限界です。<span class="kei">は、HTMLとして、そこが形式段落であるということを明示しているわけではありません。なんらかのあるひとまりであるということを示すに過ぎず、ここではCSSをつかってそれが形式段落であるということを無理やり表現しているにすぎません。クラス属性を付加した汎用要素の濫用は好ましくありません。

もしここまで形式段落にこだわらないのならば、いっそのこと形式段落はなかったことにして、意味段落のみをp要素でマークアップするというお手軽で推奨のエスケープルートがあります。

圧倒的にお手軽です！……あれ？日本語の小説に形式段落は必要だったはずじゃ……というわけで次の節ではさらに冒険します。

抜本的解決策

XMLを使用すれば以上述べてきた問題を克服することができます。意味段落や、形式段落、台詞などの要素を独自に導入してしまえばいいのです。そうすると次のような書き方が可能になります。以下body部のサンプル。p1が意味段落を、p2が形式段落を意味します。

しかしすべてを独自の要素で記述すると、スタイルなどをいちいち全て指定せねばならず大変に面倒です。XHTMLははじめっからXMLですから基本的にはXHTMLを使い、独自に導入した部分は最低限に抑えるというスタンスが吉でしょう（なお独自に要素を導入することで、XHTMLではなくXMLとなるのでHTMLの文書型宣言は削除します）。たとえばデフォルトでXHTMLの要素を利用し、独自にevassというXML名前空間接頭辞を利用した場合、以下のようになります（強調した部分が追加したXML名前空間です）。これによって示したサンプルの<evass:p1>のような要素が使用可能になります。

しかしながらこのままでは独自の要素をどのように表現すればよいのかわからないので、スタイルシートについての記述をする必要があります。メジャーなブラウザでXML文書を表示させるには、スタイルシートにXSLを利用して、XSLTによってHTMLに変換し、さらにそこにCSSを適用するというパターンが一般的です。しかし、独自に拡張した部分を表にして表現したり、リンクを設定したりするわけではなく、単にテキスト整形するだけなら、XMLに直接CSSを適用させることができます。

head要素内などはどうがんばっても指定できませんから、XSLTを使うのがやはり常識的というものだとは思います……。これ以上書くとただのXML解説ページになってしまいますので、適当に調べてください。上に書いたもののサンプル（Internet Explorerならきちんと表示してくれるでしょう）。

本章参考文献

• SOPHIAさんによる「p要素 – agenda – 2001/12/16〜31 –」
• 神崎正英さんによる「段落と改行 – 文書の骨格となる基本要素 — ごく簡単なHTMLの説明」
• 伊藤悠さんによる「<p>タグと<br>タグの狭間で。 – bでも十分上にソートされるはず日記／2001/03b」