HTML概説

3rd Edition.


2.HTML as SGML in Brief



2.1.この章の「はじめに」


2.1.1.あやしいたとえ話

舞台設定。あなたは、はじめて銀行に来て、振り込みをする。振り込みの仕方がわからないので、フロア案内をしているお姉さんに方法を質問する。すると、お姉さんはこういうだろう。

「あちらにある用紙に、必要事項をご記入ください。」

必要事項? ふとみると、その用紙は既に罫線などがひいてあり、その桝目を説明するための見出しが書かれている。挙げ句に、記入台には「記入例」が書かれている。なるほど、このとおりにやれば、はじめてのアナタでも必要書類を作成できるわけだ。

ここで、アナタが備えていなければならない能力は、「記入例を読み解く」能力だけである。(文字が読める、とかそういう馬鹿なハナシは省略するよん。)


2.1.2.HTML文書を記述するために必要な背景知識

1章で「SGMLの文書作成は2段階に分けられる」といった。先のたとえを用いるならば、第1段階は「記入用紙と記入例を作る」であり、第2段階は「記入用紙などをみながら、実際に文書を記述する」である。

HTMLでは、W3Cが第1段階を済ませている。その結果提供されているのが、作成済みの「文書型定義(DTD: Document Type Definition)」と「SGML宣言」だ。SGML宣言は「使ってよい文字」「開始タグに使う記号」などを定義するものであり、ほとんど意識する必要はない。さしあたっては忘れていてよい。一方、文書型定義は「存在する要素」「書いてよいある要素の順番」などを定義するものであり、逆むきにいえば、「HTML文書」は文書型定義の定めるルールにしたがって書かれていなければならない。つまり、すんごく重要だ。

さて、貴方が銀行に行った時に記入例を見ながらそのとおりに文章を書くように、HTML文書を書く時には文書型定義を見ながらそのとおりに(そこから逸脱しないように)書かなければならない。このようにいわれると難しそうだが、「文書型定義を読んで書く」=「記入例のとおり書く」のだから、別に難しいことではない。

すると、アナタが備えていなければならない能力は、「文書型定義を読み解く」能力だ。以降では、読み解き方を解説するために、あえて「文書型定義を記述する」さまを紹介する。


余談。

ここで多くの人は「文書型定義を覚えなければならない? そんなハナシははじめて聞いた」というだろう。でも、確かに必要なのだ。もっとも、文書型定義のすべてを知っている必要はない。僕が挙げる点だけ知っていればいい。そして、それは何も難しいものではない。

でも、既存のHTML入門書をひっくり返しても、「文書型定義の読みかた」なんて単元はないだろう。それもそのはず、それらの本はHTMLについてほとんど何も知らない人が書いているのだから。既存のHTML本には救いがたいほど間違いが多いのだが、その原因は「SGMLに関する知識が無いから」だと思われる。たぶん。

ちなみに、W3Cの仕様書(HTML3.2と4.0)もRFC1866(HTML2.0)も、その始めのほうの単元でSGMLの説明をしてる。HTML4.0仕様書では、僕が書くよりもたくさんの説明を載せている。結局、これがないとHTMLは理解できないのだ。

SGMLについて(特に文書型定義について)学ぶのは、絶対に有益だ。決して回り道ではない。どちらかというと、トータルとして近道だ。

というわけで、頑張って勉強してください。



2.2.SGML in brief

カンタンな文書の例として、何がいいだろう…私は、「名刺」を選んだ。以降では、「名刺」を例にSGML的な文書型定義構築の模様と、そのインスタンスの記述の模様をお見せしよう。


2.2.1.「名刺」を分析する

名刺のデザインにはさまざまなものがある。けど、デザインをとっぱらってしまって「本質的に、内容的に、何が書かれているのか」だけに注目すれば、どの名刺も似たようなものだ。すなわち、「肩書き」「名前」「連絡先」というパーツ(要素)で構成されているのが「名刺」だろう。

[名刺]

その出現順序や回数はさまざまだとおもうが、ここでは思いきって次のように定義してしまおう。


2.2.2.「名刺」の文書型定義

(1)文書型定義の内容

文書型定義は、ずばり「要素の出現順序」と「要素を記述できる回数」を記述するものだ。なお、SGMLでは、とある要素は別の要素の集合として定義される。ある要素を構成する要素を、その要素の子要素という。この言葉を使って説明すれば、「文書型定義は、ある要素の子要素について、定義を延々と書き連ねたもの」となる。

(2)具体例

具体的に行こう。先の「名刺」は次のように記述される。

<!ELEMENT 名刺 - - (肩書き*、名前、連絡先+) >
<!-- [解説]
	順序:肩書き、名前、連絡先の順
	回数:0以上(*)、1、1以上(+)
-->

(注:<!--から-->の間は、文書型定義における“コメント”です。)

では、個々を解説しよう。

ELEMENTは「要素を定義しますよ」というキーワード。その直後の「名刺」が、これから定義する要素の名前である。

「名刺」の後のハイフン2つは、開始タグと終了タグの省略可能性を示している。ここでは、両方とも「省略不可能」。ここに「o」(小文字のオー)が書かれている場合、文脈によってはタグを省略できる。詳しくは後述。

その後ろのカッコ()のなかには、記述してよい子要素の定義だ。ここの中に、子要素の順序と回数が書かれている。順序は「,」(書いたままの順番)とか「|」(順不同)といった記号で記される。回数は、コード内のコメントのとおり、*(0以上)、+(1以上)、? (0か1)という記号で示される。何も無ければ「1」ね。

さて、以上で説明は終わりだ。たったこれだけのことを覚えてしまえば、文書型定義は読める。簡単でしょ。(注:繰り返すが、皆さんは文書型定義を読めればいいのであって、書ける必要はない。)

(3)入れ子の定義の行き着くところ

さて、ある要素は子要素によって定義される。ということは、今度はその子要素を定義しなければいけないわけだ。…定義するのはいいが、これではどこまでいっても定義が終わらないのでは? 

というわけで、入れ子の終着点を紹介する。次の3つの場合に、定義は終わったことになる。

  1. 子要素が「#PCDATA」の場合。この「#PCDATA」は「普通のテキスト」を意味している。つまり、具体的に表示されるモノが「#PCDATA」だと考えてよい。逆に、「#PCDATA」を子要素に持たない要素には、テキストは書けないことになる。(注:孫要素のことは別にしてね)
  2. 子要素が「EMPTY」の場合。この場合、その要素は「空要素」であり、終了タグは存在しないことになる。HTMLでは、HR要素やIMG要素が空要素である。(注:たまに「エンプティタグ」という単語を書いている本があるのだが、そんな用語は存在しない。)
  3. 子要素が既に定義済みの要素である場合。その要素は再帰的に定義されていることになる。ただし、どこかのとおりみちのなかに#PCDATAや空要素が存在しないと、無限ループに陥ることになる。

能書きはさておき、「名刺」の定義を続けよう。面倒くさいので、「肩書き」も「名前」も「連絡先」も、子要素は「#PCDATA」ということで済ませよう。いや、面倒くさいからではないぞよ、それが論理的だからだぞよ。

<!ELEMENT 肩書き - - (#PCDATA) >
<!ELEMENT 名前 - - (#PCDATA) >
<!ELEMENT 連絡先 - - (#PCDATA) >

これはまとめて次のように書いてもOK。

<!ELEMENT (肩書き|名前|連絡先) - - (#PCDATA) >

これですべての要素の定義が末端にたどり着いたので、文書型定義は完成したことになる。

(注:厳密には、各要素のとりうる“属性(Attribute)”に関しても定義が必要。でも、これはSGMLそのものの解説書ではないから、あえて省略。)


2.2.3.「名刺」インスタンスを書いてみる

では、完成した文書型定義にしたがって、SGML文書を書いてみよう(注:正しい用語としては「SGML文書インスタンス」という)。

文書インスタンスでは、文書中のどの部分がどの要素であるのかを、開始タグと終了タグを用いて明示する。親要素に対する子要素は、要素の入れ子によって表現される。

論より証拠。というわけで、とっとと「名刺」インスタンスを書いてみよう。

最上位の要素は「名刺」。というわけで、インスタンスの始めは、有無を言わさず「名刺」。

<名刺>
</名刺>

名刺の中には、「肩書き」「名前」「連絡先」がやってくる。このインスタンス例では、ぜんぶひとつずつにしておこう。

<名刺>
	<肩書き></肩書き>
	<名前></名前>
	<連絡先></連絡先>
</名刺>

「肩書き」などの子要素は#PCDATAなので、具体的な文字列を記入しよう。

<名刺>
	<肩書き>あやしい表現者</肩書き>
	<名前>すみけんたろう</名前>
	<連絡先>jy3k-sm#!#!asahi-net.or.jp</連絡先>
</名刺>

ちなみに、肩書きはなくてもOKだし、連絡先は2つあってもOKなのだ。いじってみよう。

<名刺>
	<名前>すみけんたろう</名前>
	<連絡先>jy3k-sm#!#!asahi-net.or.jp</連絡先>
	<連絡先>電話もあるけど、ナイショだよ</連絡先>
</名刺>

以上で、文書インスタンスの書き方の説明はオシマイ。簡単でしょ? 


鬱憤晴らし。

このように、SGML文書インスタンスの記述は、銀行や役所に行って書類を書く時に「記入例」を見ながら行うように、「文書型定義」を見ながらそのとおりに書けばいいのだ。文法について悩む必要はない。答えはすべて文書型定義にあるのだ。

既存のHTML本は、文書型定義の読み方を教えないばかりか、その存在にすら言及しない。それで正しい文書インスタンスが記述できるはずが無い!



2.2.4.文書型定義のバージョン違いと文書型宣言(DOCTYPE宣言)

ところで、「名刺の定義」って1種類で十分だろうか? いやいや、そんなことはない。たとえば、連絡先として「電話番号」「e-mail」を区別したい場合だってあるだろう。

このように、本質的には同じもの(「名刺」)のマイナーチェンジを表現するのに、「バージョン違い」という表現をすることがある。先の「名刺」の定義を「normal.dtd」とし、次に、連絡先に関するバージョン違いの文書型定義「alternate.dtd」をつけてみよう。

こちらのバージョンでは、「連絡先」要素はひとつしか許されない。ただ、その子要素として、順不同、個数1以上で「電話番号」あるいは「e-mail」を書くものとする。

<!ELEMENT 名刺 - - (肩書き*、名前、連絡先) >
<!-- [解説]
	順序:肩書き、名前、連絡先の順
	回数:0以上(*)、1、1
-->
<!ELEMENT (肩書き|名前) - - (#PCDATA) >

<!ELEMENT 連絡先 - - (電話番号|e-mail)+ >
<!ELEMENT (電話番号|e-mail)- - (#PCDATA) >

この文書型定義にしたがってインスタンスを書くと、こんな感じになる。

<名刺>
	<肩書き>あやしい表現者</肩書き>
	<名前>すみけんたろう</名前>
	<連絡先>
		<e-mail>jy3k-sm#!#!asahi-net.or.jp</e-mail>
		<電話番号>電話はナイショよ</電話番号>
	</連絡先>
</名刺>

書く方はそれでよい。でも、読む方はこれだと困らないだろうか?  そう、ひとこと「名刺」といっても、どのバージョンの名刺のつもりなのだかわからなければ、真の意志の疎通はできない。この2つだとほんの少ししか違わないから気にならないけど、それでも「normal.dtd」しか知らない人にとっては、「このe-mailって要素はなんなんだ? 」ということになる。

そこで、文書インスタンスの一行目には、その文書インスタンスがしたがっている文書型定義を明示するものを添付しなければいけない。それを「文書型宣言(DOCTYPE宣言:これも略せばDTDだ)」と呼ぶ。

<!DOCTYPE 名刺 SYSTEM "http://foo.bar.com/dtd/alternate.dtd">
<名刺>
	<肩書き>あやしい表現者</肩書き>
	<名前>すみけんたろう</名前>
	<連絡先>
		<e-mail>jy3k-sm#!#!asahi-net.or.jp</e-mail>
		<電話番号>電話はナイショよ</電話番号>
	</連絡先>
</名刺>

ハナシの説明上、「バージョンを明確にするために」と説明をすすめたが、ヴァージョン違いが存在しない場合でも、文書型宣言は「必須」である。だって、文書型宣言が無いと、インスタンスがHTMLなんだか名刺なんだか判断できないじゃない? 


2.2.5.HTMLの文書型定義のバリエーション

1998年6月現在、オープンになっているHTMLの文書型定義には2.0、3.2、4.0の3つのバージョンがある。その文書型定義の特徴の紹介と、対応する文書型宣言を紹介しよう。

(注:HTMLのヴァージョンは、上位互換ではない。HTML2.0として正しいHTML文書インスタンスが、そのままHTML4.0として正しいとは限らない。)

また、これ以外にもISO-HTMLという試みがあります。これは結構意欲的な「論理構成バリバリ」のHTMLです。いつ公式になるのだろう? それとも、すでに公式なのか? 

◆HTML2.0
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
あるいは
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

1995年12月、RFC1866。文書構造、インライン画像、リンクなど、もっとも基本的なHTML文書を定義している。なお、HTML1.0に相当する公式の仕様は存在しない。すなわち、HTML2.0成立以前は公式の文書型定義が定められておらず、HTML文書の記述ルールにかなりの混乱があった。(この混乱を助長したのがNetscape社だ。悪党め! そう、悪党はMicrosoftだけじゃないんだぜ。)

(注:厳密には、HTML2.0にはサブバージョンがあり、それに応じて複数の文書型定義とDOCTYPE宣言が存在します。くわしくはRFC1866をご参照ください。)


なお、HTML2.0の国際化(internationalization:i18n)バージョンであるHTML2.x(RFC2070)というものもあります。そう、標準のHTML仕様では、厳密には日本語などを通せないのです(僕はSGML宣言に明るくないのでわからないのだけど、#PCDATAにも駄目なの? )。もっとも、「日本語対応のWWWブラウザ」は、公式仕様がどうなっていようと日本語を通すので、僕はここまでは気にしないことにしています。態度が中途半端で申し訳ない。でも、2.xファンは多いようなので、ひとこと。

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

なお、HTML4.0では、はじめからi18n対応になりました。ようやく。


◆HTML3.2
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
あるいは
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 //EN">

1997年1月、W3C Recommendation。HTML3.2は、Netscape社などの独自仕様の要素(TABLE、FONTなど)や独自属性(BGCOLOR、ALIGNなど)をHTML2.0に追加したものだと考えればよい。

HTML3.2よりも前に、HTML2.0を大幅に拡張するHTML3.0が検討された。脚注とか数式とか、大胆な拡張がこころみられたのだが、そのギャップの大きさのために(? )3.0は成立しないまま終わった。そのいくつかは、HTML4.0、MATHML(だっけ? )などに吸収されている。XMLという新たな基軸も、この失敗から生まれたものかもしれない。

(注:たまに、「HTML3.0の文書型宣言をつけていれば、HTML3.0でかいたHTML文書もOKだ。」と考えているひとがいるらしい。それは間違い。既に破棄された仕様は、破棄されたのだからダメ。これが許されるなら、自作文書型定義でかいたHTML文書だって許されてしまう。もっとも、XMLやSGMLであれば、当然自作文書型定義もOKだ。)

◆HTML4.0
HTML4.0-strict:
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
HTML4.0-transitional:
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
HTML4.0-frameset:
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN">

1997年12月、W3C Recommendation。

HTML3.2では、FONT要素など、直接にスタイルを規定する要素がいくつか採用された。でも、SGML的な観点からいえば、これは「望ましくない事態」だ、文書構成要素は文書における意味(「肩書き」「連絡先」など)に基づいて定義されるべきであり、FONT要素などはダメダメなのだ。しかし、すでにデファクト・スタンダードとして広まっている以上、これらを無視するわけにはいかなかった。

そこで、HTML4.0にはStrict、Transitional、Framesetのサブバージョンが制定された。StrictはFONT要素などのスタイル規定系要素・属性を破棄した厳密なバージョン(個人的には、BやIが残っているのが気に入らない)。Transitionalはスタイル規定系要素・属性を残したルーズなバージョン。Framesetは毛色が異なり、フレーム表示のHTML文書に使われる特別な文書型定義。

なお、Transitional(過渡的)という名前が示すとおり、今後はStrictに移行するべし! である。スタイル指定はスタイルシートで行いましょう。

HTML4.0の本当の新基軸は、文書の国際化考慮(言語指定、右がき左がき、など)とアクセス性考慮(メディア指定、キーボードショートカットなど)だ。その他にも、スタイルシートとの連携・マルチメディアオブジェクト・スクリプト・フレームの採用があげられるが、それらは「HTML以外のものとの連携」に過ぎない。(注:にもかかわらず、巷のHTML4.0本のほとんどは「国際化」も「アクセス性」も取り上げない。それのどこがHTML4.0なんだ? )

(注:また、テーブル、フォームの表現力が圧倒的に豊かになった。個人的には、TABLEは複雑になりすぎていると思う。それはさておき、既存のHTML4.0本は、このTABLEの新概念についてあまり言及していない。それのどこがHTML4.0本なんだ? )


鬱憤晴らし。

既存のHTML本の中には、文書型定義のなんたるかも教えないくせに、文書型宣言だけ教えるものがある。しかも、「とにかくこのとおりに文書型宣言を書けばOK」という。おおまちがいだ!

文書型宣言は、「この文書はこの文書型定義にしたがって記述しました」という宣言である。宣言とそれが指す文書型定義が食い違っていては意味が無いのだ。多くの本がHTML3.2の文書型宣言をつけた文書でMozilla拡張を利用していたり、HTML2.0の文書型宣言をつけた文書でHTML3.2を書いたりしている。冗談じゃないぞ! 文書型宣言を見ずに、あるいは知らないまま書いた文書に文書型宣言をつけるのは止めてくれ

あげくに、WYSIWYGエディタのなかにも、内容と合わない文書型宣言を添付するものがある。それだけでなく、「公開されていない文書型定義を指す」文書型宣言を添付するものもいる。(注:IBMのHomePage Builderは最低。なお。MSのIE4.0でHTML文書を「Save As」しても、へんな文書型宣言がつく。)

文書型宣言は、「ただしいHTML文書だ」と発言するための免罪符ではない。きちんと意味を理解してから記述しておくれ。



2.3.HTML in brief


2.3.1.HTMLの文書型定義:簡略版

さっきから「文書型定義を読むのなんてカンタンだ」といってきたが、実はHTML4.0の文書型定義を全部よむのは大変困難だ。そこで、概念を明確にするために、枝葉を切り落として単純化することにした。つまり、このテキストで説明するのはHTML4.0Strictのサブセット文書型定義(すみけん自作)だ。完全なサブセットだから、この文書型定義にしたがった文書インスタンスは、絶対にHTML4.0Strictの文書型定義を満足する。文書型宣言もHTML4.0StrictのものをもちいてOKだ。

まずは、もっとも外枠の定義だけを示す。始めに出てくるのは、「HEADおよびBODY要素」と「blockおよびinline系要素」だ。

<!--HTML4.0のサブセット。
	インスタンスはHTML4.0-StrictとDOCTYPE宣言して構わない。
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
-->

<!-- 最上位の要素は「HTML」-->
<!ELEMENT HTML o o (HEAD, BODY) >

<!ELEMENT HEAD o o (TITLE) >
<!ELEMENT BODY o o (%ブロック系要素;)+ >
<!-- この%付きの「名前」は、「要素のグループ」の名前であり、
      HTML文書中にはそのグループ内の要素を記述する。
      C言語の#defineマクロ展開に似ている。
      具体的な要素は、本文中で紹介する。
-->

<!ELEMENT TITLE - - (#PCDATA)>

<!ELEMENT %ブロック系要素; - - (%インライン系要素;)+ >
<!ELEMENT %インライン系要素; - - (#PCDATA | %インライン系要素;)+ >
<!-- [解説]
	順序:#PCDATAあるいは%インライン系要素;のどちらか一方、
	   の1回以上の繰り返し
	回数:1、の1回以上の繰り返し
-->

<!--
	本当は「%ブロック系要素;」と「%インライン系要素;」の
	実体を定義する必要があるのだが、ここでは省略する。
-->

2.3.2.要素の分類

(1)HEADとBODY

HTML文書の要素(パーツ)は、おおきく「HEAD」と「BODY」にわけられる。HTML要素の直下には、これらがこの順序にひとつずつ存在しなければならない。

HEAD要素は「ヘッダー情報」に相当する部分。文字コードとか連携するスタイルシートとかの情報を入れ込むのだが、差し当たっては「TITLE要素」だけが「ひとつ、必須」だと覚えてくれればよい。

BODY要素は「本文」に相当する部分。基本的には、表示されるのはこちらがわだけ。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
	<TITLE>
		文書のタイトルを書く
		(できればラテンアルファベットで)
	</TITLE>
</HEAD>
<BODY>
	本文!
</BODY>
</HTML>

以上で枠ぐみ終了。(注:HTML文書インスタンスでは、余分な空白やタブや改行は、いくらいれても文書の意味を左右しないことになっている。詳しくは3章にて。)


注。

HTML3.2のBODY要素の属性には、表示テキストの色を指定するものがあった。そのせいか、途中でテキストの色を変えたいと思ったのだろうか、ひとつのHTML文書中にたくさんのBODY要素をかいている人がいる。しかも、BODYを開きっぱなして閉じないのである。そういうのはダメダメなので、そのつもりで。

ちなみに、その属性は4.0Strictでは破棄された。そんなものを使わなくても、スタイルシートを用いれば、要素ごとに前景色と背景色を指示できる。たとえば、見出しだけに背景画像をセットすることも可能だ。みなさんもスタイルシートを使いましょう。


(2)blockとinline

BODY要素の子要素は、おおきく「block系要素」と「inline系要素」にわかれる。(注:わたしは大文字小文字を区別しないで入力するきらいがある。BLOCKとかBlockと出てきても、blockと意味は変わらないので、そのつもりで。)

「block系要素」は、「段落」や「見出し」など、あるていどのまとまりの文を表現する。その子要素は、1つ以上のinline系要素である。(注:モノによっては、block系要素を子要素に持つblock系要素も存在する。詳しくは3章にて。)

「inline系要素」は、「強調語句」など、文の一部を構成する特殊な部分を表現する。その子要素は、表示される文字そのもの(#PCDATA)あるいはinline系要素の1つ以上の繰り返しである。便宜上、このテキストでは#PCDATAもinline系要素として数えてしまうかもしれない。

なお、例外的に、HTMLの仕様はblock系とinline系の標準の表示形態を規定している。block系要素は、その開始と終了で改行する。inline系要素は、その開始と終了で改行しない。(もっとも、この表示に関する約束も、「WWWブラウザ標準のスタイルシート設定を、このようにしてね」というものだ。また、ユーザのスタイルシートを用いて変更することも自由だ。)


鬱憤晴らし。

既存のHTML本は、このblockとinlineについて言及しない。仕様としてBLOCKQUOTE要素や見出し要素はblock系だから、その前後で改行されるのはあたりまえ。なのに、block系の性質に言及しないから、「BLOCKQUOTEタグの前後には、自動的に<BR>が挿入される」なんてむっちゃくちゃな説明をする本が現れるわけだ。しかも、ひとつやふたつではない。トホホ。(注:BRは「(強制)改行」ね。)

また、既存の本は「記述できる子要素には制限がある」ことを説明しない。だから、inline系であるSTRONG要素(いや、B要素かな)のなかに複数のP要素(段落)をいれたりするわけだ。「要素、子要素」という概念が頭に無くて、「タグで見栄えの指定範囲を記述する」と考えているから、こんな馬鹿なことをしてしまうんだぜ。



2.3.3.block系要素

見出しと段落さえ書ければ、文章は書ける。そして、書いた文章をHTML文書として整形するのは容易である。というわけで、まずは見出しと段落について。残りのblock系要素は3章で。

(1)heading要素(H1〜H6要素)(見出し)
<!ELEMENT (H1|H2|H3|H4|H5|H6) - - (%inline系要素;)+ >

見出しとは、あとにつづくいくつかの文章の内容を端的にまとめたものである。いやいや、こんなこといわなくても、皆さん見出しの何たるかはご存知だろう。

HTMLでは、見出しは見出し要素として扱う。見出しレベルに応じて、H1要素〜H6要素をもちいる。(注:たまにH7要素があるといわれるが、W3Cの公式仕様には存在しない。)

見出しレベルとは、部、章、節、項ってやつだ。僕は「ポイント式」がわかりやすいのでオススメ。ずばりいって、見出しの前の「1」とか「1.1」を想像したほうが、見出しレベルとHx要素の関係は理解しやすい。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
	<TITLE>愛しのプリンス</TITLE>
</HEAD>
<BODY>
<H1>1.プリンスとの出会い</H1>
	<H2>1.1.岡村靖幸の存在</H2>
	<H2>1.2.LOVESEXYにおけるアナステジア</H2>
	<H2>1.3.カリスマ</H2>
<H1>2.プリンスの作品の特徴</H1>
	<H2>2.1.リズム</H2>
		<H3>2.1.1.ループグルーブ</H3>
		<H3>2.1.2.アクセント位置</H3>
	<H2>2.2.ハーモニー</H2>
		<H3>2.2.1.動かないメロディ</H3>
		<H3>2.2.2.ハーモニーとアンサンブルが展開を支配する</H3>
</BODY>
</HTML>

見出しをどう表示するか、見出しレベルの違いをどう表現するかは、スタイルシートおよびUAに一任されている。HTMLの仕様書は、それについてなにも規定しない。だって、そもそもHTML文書ってソースで読んでもいいんだぜ。上の例ソースをみて、「読みにくい」と思う人は何人いる? 


警告。

多くの本は、「H1〜H6は文字のサイズを規定する」というデタラメを書いている。また、見出しレベルの違いに相当するのだと言及した本であっても、「H1からH6まで、順に文字サイズが小さくなる」というデタラメを書いている。これらはすべて「MOSAIC系の標準ではそうなっている」に過ぎない。

なお、(Mozilla拡張にしてHTML3.2で迂闊にも採用されてしまってHTML4.0Strictで破棄された)FONT要素(inline系)をもちいると、任意の文字の色とサイズを指定できる。ここではSIZE属性の値が大きいほど文字サイズが大きくなる。馬鹿な本は、「Hxで文字サイズを変更する場合には、1のほうが大きい。FONTでは、7の方が大きい。この違いに注意してね。」などと書く。クレイジー!

また、Hx要素の子要素にはblockは書けない。にもかかわらず、本の例ソースで、目一杯PやBLOCKQUOTEをHxで囲っているものを発見するのは難しくない。同様に、inline系であるFONT要素でblock系を囲っている例もある。もちろん、そんなのはダメダメだ。

これだけ乱れた環境にあって、普通の人がHTMLを理解できないのは当然のことかもしれない。


(2)P要素(段落)
<!ELEMENT P - o (%inline系要素;)+ >

段落とは、一定の意味的関係においてまとめられた文の集合である。日本語の場合、普通は「改行と一文字分のインデント」にはじまり、「改行」におわる。この段落を、HTMLではP要素として扱う。つまり、P開始タグによって始まり、P終了タグによっておわる。

<H1>1.プリンスとの出会い</H1>

<H2>1.1.岡村靖幸の存在</H2>

<P>有頂天のケラさんが、ラジオで「岡村靖幸のことを嫌い」といいながら、オカムラの曲をずいぶんかけてたんですよ。「どんなことして欲しいの僕に」とか。そんで、なんとなくココロに引っかかってたんだな。</P>

<P>あるとき、宝島(昔は音楽雑誌だった。その次にはファッション雑誌であった。今はエロ雑誌ですね)の新譜紹介コーナーで、岡村靖幸の新作「家庭教師」がベタほめになっていた。そこで、そのアルバムをレンタルCD屋さん(なつかしい響きだ)で借りて聞いたところ、これがまたすばらしい作品だったのだ。</P>

<P>そののちの宝島における岡村靖幸インタビューを読むと、彼はPRINCEの大ファンで、その音楽をかなり取り入れているという。それが僕がPRINCEを意識した最初の瞬間だ。</P>

<H2>1.2.LOVESEXYにおけるアナステジア</H2>

<H2>1.3.カリスマ</H2>

ただし、HTMLのP要素は、その子要素としてinline系しか許していない。つまり、段落の中にリスト(UL要素、OL要素)などのblock系要素をいれこめないということだ。自然言語だと、リストなどを挟んでハナシをつづけるといった表現があると思うが、それはHTMLではできない。できないものはできないので、黙って従うこと。(注:役所の転出届け用紙をみて、「あれ、ここには家族の写真をのっける欄がありませんよ」などといいだす人はいないだろう。それと同じで、HTMLであるかぎり、仕様に従わなければならない。いやだったら、XMLしたまえ。)

ところで、P要素の終了タグは、場合によっては省略できる。現在のHTML4.0までの仕様をみれば、100%省略できる。ただ、省略している人が、その意図を正しく理解しているとは限らないので注意が必要だ。詳しくは3章にて。


うんちく。

段落の表現は、かならずしも「改行+一文字分のインデント」であるとは限らない。それは単に日本語文章表現の慣習に過ぎない。たとえば、ラテンアルファベット圏では「改行+タブ」だったり、「改行+始めの一文字だけ装飾文字」だったりするわけだ。また、日本の新聞だと「▼記号を付けるだけ、改行なし」ってのもある。

以上の表現は、すべてスタイルシートで実現できる。同じHTML文書に各国語用のスタイルシートを添付して、読み手に選択させることだって可能だ。それを実現するには、ちゃんとソース中の段落が「P要素」として表現されていなければならない。それが「HTML+スタイルシート」の利点なのだ。(HTMLは見栄えを担当せずに意味だけを書く、スタイルシートには見栄えだけを書く。)

そのような思想を無視して、HTMLソースで「BRで段落を表現」などと馬鹿なことをしていると、その文書は融通が利かないものになる。こんなのはダメダメだ。

ついでに、スタイルシートを添付しておこう。

P:lang(jp){
	display:block;
	margin-bottom:0em;
	text-indent:1em;
}
P:lang(en){
	display:block;
	margin-bottom:1em;
}
P:lang(en):first-letter{
	font:2em fantasy;
}
P:lang(jp).NEWSPAPER{
	display:inline;
}
P:lang(jp):before.NEWSPAPER{
	content:"▼"
}

(3)もうできた!

ところで、直前の例ソースをみて、すでにHTML文書が完成していることに気がついたかな? そう、HEADやBODYの大枠を整えて、見出しと段落さえこしらえてしまえば、文章そのものは完成なのだ。

以降では、inline系要素を用いて豊かな文章表現を行う術を紹介する。でも、すでに文章そのものは記述できるって事実を忘れないように。


2.3.4.inline系要素

(1)STRONG要素(強調)

文章をつらつらと書くだけだと、やっぱりメリハリに欠けるよね。あんまりタルいと、大事なところを見落とされてしまう。だから、あらかじめ「ここは強調したいんだよ」という部分はソレとして明示しておくべきだ。その部分に相当する要素がSTRONG要素です。

<P>有頂天のケラさんが、ラジオで「岡村靖幸のことを<STRONG>嫌い</STRONG>」といいながら、オカムラの曲をずいぶんかけてたんですよ。「どんなことして欲しいの僕に」とか。そんで、なんとなくココロに引っかかってたんだな。</P>

HTML(というかSGML)では、文書記述者がすべてのニュアンスを明示しなければならない(表現の矛盾? )。いやいや、それはどんな文書でも同じか。というわけで、強調したい部分はSTRONG要素なのだから、それを明示するようにしてね。

(それ以外の要素については、3章にて。でも、普段はSTRONGだけ知っていれば事足りるはず。)


老婆心、プラス鬱憤晴らし。

「文字が大きいから見出し」ではなく「見出しだから文字が大きい」という考えかたをしよう、ってのはもうOKですね。ということは、「太字だから強調」ではなく「強調だから太字」と考えて欲しいわけです。つまり、STRONGのかわりにB要素(太字を直に指定する要素)を使うのはダメダメだ。B要素とI要素は4.0Strictでも採用されているが、僕は完全撤廃が望ましいと思うね(Transitionalならともかく、Strictにはいらないだろう)。

また、あくまでもSTRONG要素は「強調」であって、必ずしも「太字」になるのではない。スタイルシートを用いれば、STRONG要素の見栄えを「背景色に淡い赤、文字は黒、太字でサイズは本文の1.2倍」なんて指定もOKだ。いいかね、あくまでもHTMLは意味合いを指定するものなのだ。見栄えはスタイルシートの仕事。MOSAIC系の束縛から逃れるために、みなさんもスタイルシートを使うようにしておくれ。


(2)CLASS属性

ところで、ひとこと「強調」といっても、実際にはいろんな強調理由があるはずだ。たとえば、「人名だから強調したい」「日付だから強調したい」「感情むきだしだから強調したい」などの理由。

その区別のためには、ニュアンスごとに要素を用意すればよい。でも、それでは活用が煩雑になる。そこで、HTMLは「CLASS属性」にてニュアンスを表現することにした。(注:W3Cが想定したCLASS属性のうち、すみがもっとも重要だと思うのがこれです。この使いかたが「絶対」ではありませんが、すみは「これが絶対だ」と主張します。)

ええと、<STRONG CLASS="NAME">僕</STRONG>の誕生日は<STRONG CLASS="DATE">2月24日</STRONG>、「ににんがし」の日です。</P>

おっと説明し忘れた。要素の属性とは、個々の要素の特徴を表現するものだ。開始タグの中に入れ込んで記述する。終了タグには書かない。どの要素にどんな属性が用意されているのかは、文書型定義中に明示されている。このテキストでは、必要最小限しか教えないので、そのつもりで。

さて、CLASSをつけると何がうれしいか。まず、SGML的には、「伝えたいことが明確になる」のがうれしい。次に、スタイルシート的には、「クラスごとに表示を調整できる」ので、うれしい(DATEはイタリック、NAMEは前景背景反転ってのもOKだ)。ということで、ぜひCLASS属性を上手に活用してほしい。

なお、CLASS属性の値は、あなたが勝手に自由に付けてよい。ただし、ラテンアルファベットと数字とハイフンだけにしておくのが安全だと思われる。たぶん、ワイドキャラクタ(日本語文字など)はマズイ。


老婆心、プラス鬱憤晴らし。

ちなみに、この2つは独立した事象ではない。スタイルシートで表現をいじれるのは、文書構成が明確に明示された場合だけなのだ(原理的には)。CLASSによってより構成がはっきりしたから、表示もいじれるようになるのね。まちがっても、表示をいじるためにCLASS属性をつけるんだ、と思わないように。

また、CLASSの値には「DATE」「NAME」(「強調する理由」)などを選ぼう。より正確には、「文書の意味合いを表現するもの」を選ぼう。

最悪なのは、<STRONG CLASS="RED">なんてふうに、属性値に「期待する表示効果」に相当するキーワードをいれてしまうことだ。こいつは、FONT要素やB要素を使うのと同じくらいダメダメだ。


さてさて、このCLASS属性は、BODYの子要素のほとんどすべてに用意されている。もちろん、Pやheadingにもある。たしか例外が2・3あったのだが、そんな要素は普通は書かないので、省略。

(3)それ以外のinline系要素

inline系要素のうち、文書を記述するのに実際に記述するのは、STRONGと次のものだけだろう。

CITE要素
引用のタイトルなどに相当
Q要素
引用語句に相当。quotation。ただし、block系の引用ブロックBLOCKQUOTEとの使いかたの違いに注意。詳しくは3章にて。

これ以外のものは、フォームやアプレットを埋め込みたい時に利用するものだけだ。私はそういうものは使わないので、教える必要を感じない。ということは、説明しない^^;

ところで、ビンカンな人なら気づいていると思うが、「画像(IMG要素)」と「アンカー(リンク、A要素)」が紹介されていない。そう、これらはWebを高名にした重要なモノだ。だから、3章で詳しく説明する。

(4)望みのinline系要素が無い場合

さて、「このなかにお望みのinline要素が無い」という人はいないだろうか。「私は“誕生日”っていう要素が欲しい」とか、ワガガマな人はいないだろうか。HTMLは拡張を許していないし、だからといってXMLするほどでもないはずだ。では、そのワガママに答えるにはどうしたらいいのだろう? 

まずは、CLASS属性を利用することを覚えて欲しい。「誕生日だから強調したい」のであれば、STRONG要素でCLASS=BIRTHDAYとでもすれば意図は完全に表現できるはずだ。そう、ほとんどの場合は「強調したい」のだから。

それでは気に入らない時は、必殺のSPAN要素を利用して欲しい。SPANは「それ自体には意味が無い」という変わった要素だ。というか、CLASSによって性格を決めるように想定された要素だ(注:ちょっと過大解釈アリ)。<SPAN CLASS="BIRTHDAY">2月24日</SPAN>とすれば、もうカンペキだ。

ちなみに、同様の意図で用意されたblock系要素がDIV要素である。(注:仕様を理解していない本だと、DIVは「Pと違って余分な改行をしない段落」とか「左右の位置決めを指示するためのブロック」などと紹介されているが、それらは全く持って間違いだ。)

こうしてみると、HTMLだって十分拡張できるのではないか? 私はそう思っている。


なお、CLASS属性による違いを表示にも反映させたいならば、スタイルシートを用いることになる。というか、HTML文書にはスタイルシートを添付するのが当たり前なのだ。みなさんもはやくスタイルシートを使ってください。



2.4.文法チェックのススメ


2.4.1.ありがちなミス

文書型宣言を正しく付けよう、ってのは既に言ったとおり。あと、「引用でもないのにBLOCKQUOTEになっている」ってな系統は省略。また、タイプミスなんてのは当たり前すぎるので省略。閉じるタグの/忘れなんてのも略。ここではHTMLの知識が足りないために起こるミスを紹介しておこう。

(説明の都合上、ここまでて紹介した要素以外の要素も使います。)

あ、そうそう、3章で解説するんだけど、「要素名、属性名のラテンアルファベットの大文字小文字は区別されない」「属性値は""で囲む」ということで。

(1)要素の入れ子構造が壊れている

HTML(というかSGML)文書インスタンスは、常に要素の入れ子で記述する。要素の中に要素があるのだから、要素1の開始タグの中に要素2の開始タグがある場合、絶対に要素2の終了タグは要素1の終了タグよりも先にくるわけだ。

しかし、馬鹿なHTML本では、こんな最低限のことすら書かれていない場合がある。下手すると、例ソースでこのようなミスを犯していることがあるのだ。(注:そういう例は、B要素(太字)とかI要素(イタリック)とかが多いので、ここではあえてそいつらを使おう。)

<P>そうなのだ、僕は<B>(太字)音楽マニアであり、<I>(太字+イタリック)芸術鑑賞マニアであり、</B>(イタリック)あげくに「語る」</I>のが大好きなのだ。

このような誤解は、HTMLを「タグで表示の調整を指示するもの」だと勘違いすることから始まる。実際、B要素とかI要素が正当なものであるならば、こんな記述をしたくなっても不思議ではない。でも、(これらの要素はHTML2.0の時代から正式採用されているけれど)BやIはHTMLにとって「邪道」なのだ。それらではなくSTRONGやCITEを意識すれば、この記述のまずさをすぐ理解できるだろう。

先と同じことをやりたいなら、要素を小分けにすればよい。一部のHTML本では、こんなような「逃げ方」を紹介しているだろう。

<P>そうなのだ、僕は<B>(太字)音楽マニアであり、</B><I><B>(太字+イタリック)芸術鑑賞マニアであり、</B>(イタリック)あげくに「語る」</I>のが大好きなのだ。

でも、こんなものを書きたいと考えているのは、HTMLを理解していない証拠だ。発想自体を変えよう。文書構成を記述する中では、こんな不自然な文脈は登場しないはずだ。この例のBをSTRONGに、IをCITEに置き換えてみよう。変でしょ? 

<P>そうなのだ、僕は<STRONG>(太字)音楽マニアであり、</STRONG><CITE><STRONG>(太字+イタリック)芸術鑑賞マニアであり、</STRONG>(イタリック)あげくに「語る」</CITE>のが大好きなのだ。

(2)書けない子要素を書く

すでに見てきたように、ある要素の子要素に記述できるものは厳密に定義されている。

ルールの基本を確認しておこう。

これを逆に書くと、こうなる。

ということは、複数のPをH3で囲ったりBで囲ったりするのは間違いだ。このミスも、HTMLを「タグで見栄えを指定するものだ」と誤解することで多発するものだ。

<H3>

<P>それでね、僕はね、…

<P>いやいや、それは違うんだな…

</H3>

こういうおばかさん以外にも、次の点には注意されたい。


2.4.2.文法チェッカーの紹介

そんなヘボミスは、文書型定義を脇に置きながらお役所仕事的に文書インスタンスを書いていれば、絶対に発生しない。HTML文書記述ルールを暗記する必要はないが、ルールにしたがって書かかなければいけないことだけは頭に叩き込んでおいて欲しい。可能なら、机の前の壁にでも、文書型定義を印刷して張りつけておいて、つねに参照するようにすればよい(注:このテキストが提示する簡易文書型定義であれば、印刷しても紙一枚におさまるだろう。そいつを活用して欲しい。)

でも、自助努力だけで頑張るよりも、文法チェッカー(+作法チェッカー)を利用したほうが楽ちんだろう。個人的にはAnother HTML-lintをオススメする。このチェッカーは、次の特徴を兼ね備えている。

ちなみに、Another HTML-lintは、かのRingserverプロジェクトのオープンラボのひとつとして公開されている。


2.4.3.文法チェッカーがチェックしてくれないこと

(注:2.4.1と異なり、よく見られる間違いを指摘するわけではありません。いうなれば、2.4.3は「杞憂」です。)

(1)使いかたの正しさはチェックできない

プログラムを覚える時には、次のようなことを肝に命じることを叩き込まれる(と思う)。

「プログラムの内容が間違っていても、文法さえ正しければ実行可能プログラムは生成される。たとえば、2次方程式の解を解くプログラムを、「x=y/a+b」などとデタラメに記述したところで、コンパイラや文法チェッカーは「おかしいよ」とは教えてくれない。つまり、コンピュータの吐き出した回答は、あなた自身の発想能力程度にしか信頼できない。」

それとおなじで、HTMLだって、使いかたがめちゃくちゃでも文法が正しいのならば、文法チェッカーは「エラーなし」と答えるだろう。たとえば、P要素のかわりにH4要素で段落を表現しても、文法チェッカーはエラーだとはいわない。そういうことは、すべて貴方の理解力に任されているのだ。

(2)理解の正しさはチェックできない

HTML文書を書く時に、「タグを使ってここからここまでを○○要素だと指定する」などと考えてはいけない。正しくは、「文章のここからここまでが(本質的に)○○要素であるので、それを明示するためにタグを付け加える」のだ。似ているが、よく見ると因果関係が逆になっている。すなわち、「タグを付けたから○○要素になった」のではなくて、「そもそも○○要素だからタグを付ける」のである。

この違いを理解できた人は、「HTMLはタグで文書の見栄えを指定するものだ」という誤った発想から本当に脱却できた人だ。逆に、「HTMLは太字とかイタリックを指示するものでしょ」などといっている人は、このことを理解できない。

(3)「要素が隣接している」と「大きな要素がある」との違いはチェックできない

たとえば、引用ブロック(BLOCKQUOTE要素)を二つ連続でならべることを考えてみよう。

<P>有名な童謡の出だしの歌詞を二つ紹介しよう。

<BLOCKQUOTE TITLE="tiisai-aki">

<P>「誰かさんが、誰かさんが…」

</BLOCKQUOTE>

<BLOCKQUOTE TITLE="awatenbouno-santakurousu">

<P>「あわてんぼうのサンタクロース、クリスマス前に…」

</BLOCKQUOTE>

この二つは独立した引用なので、引用要素は二つ存在するはずである。つまり、引用ブロックは二つ存在することになる。

ところが、「ここからここまでが、引用」という発想をしていると、こんなふうに書いてしまうかもしれない。

<P>有名な童謡の出だしの歌詞を二つ紹介しよう。

<BLOCKQUOTE CLASS="SONG">

<P>「誰かさんが、誰かさんが…」

<P>「あわてんぼうのサンタクロース、クリスマス前に…」

</BLOCKQUOTE>

この違いは、論理的にはすぐ理解できるだろう。でも、文法的には何の問題も無いので、文法チェッカーはこれをチェックできない。しかも、いわれるまで気づきにくい勘違いでもある。


なお、MOSAIC系の表示結果は、どちらも同じになるはずだ。そのため、この違いを意識できる人は少ないだろう。ちなみに、この「すみけんリソース!」をスタイルシート付きで見られる環境にあるひとは、表示結果からもその違いを判断できるはずだ。







ご意見ご要望及び苦情はE-MAILにて

e-mail to : jy3k-sm#!#!asahi-net.or.jp