広告

好ましいHTML文書を書くための方法と考え方

ここでは、多くの人が快適に情報を得ることのできるウェブページを作るために 必要な考え方と方法について述べてゆきます。

目次

好ましいHTML文書とはどのようなものか

ここでは「好ましいHTML文書」の条件として次のことを挙げます。

絵が動いたり音が鳴ったりするページも良いでしょう。 しかしそれらは上の条件を満たすようなマークアップがなされていなければ 無用の長物になりかねません。

私が上の条件を挙げた理由は後の節でそれぞれ詳しく述べます。また、 WWWの特徴からすると、上のことは「好ましい」というよりは本来ごく当たり前で ある筈のことです。

なお、私の考えは Lynx Enhanced Pages の思想から多分に 影響を受けています。What It Means To Be Lynx Enhanced をお読みになることをお勧めします。

以下の節では、好ましいHTML文書を書くために必要なことを説明して いきます。その前に、HTMLの入門書を紹介しておきましょう。

正しい入門

好ましいHTML文書が書けるようになる入門書として、HTML入門 第2版――WWWページの作成と公開 をお薦めします。この本はページの読み手の立場に立 ったページ作りを教えてくれる良心的な解説書で、定評のある入門 書(HTML入門――WWWページの作成と 公開)の改訂版です。

WWWで読めるものとしては、簡単で正しいHTMLの書き方 (戸田将さん)が良いでしょう。ごく簡単なHTMLの説明 (神崎正英さん)もおすすめです。

HTMLの入門書は数多く出版されていますが、誤解に基づいた不正確な記述を しているものも少なくありません。気を付けましょう。

マークアップのポリシー

この節では、好ましいHTML文書を書くための基本的な考え方を二つ 述べます。

内容に即したマークアップ

HTMLのマークアップは文書構造を明示するためのものです。 見出しは見出しに、段落は段落にと、内容に即した適切なタグ付けをすべき です。表示した時の見栄えを指定するかのような書き方をするべきでは ありません。それは次のような理由からです。

タグの付け方には厳密な規則があります。例えば、見出しの中に段落を入れる (具体的には<H1>...<P>...</H1>とするなど)ことは できませんし、アンカーの終了タグ</A>を省略することは できません。この規則を決めているのがDTD (Document Type Definition、文書型定義。SGMLの用語)です。 これを読むにはSGMLの知識を必要としますが、HTMLのことを 詳しく知りたいのであれば是非とも読みたいところです。手前味噌ながら、 HTMLのDTDを読んでみよう (矢野) 等を参照して下さい。

タグ付けの規則に違反する書き方をした場合、どのように表示されるかは わかりません。 ウェブブラウザがHTML文書を整形するときにはあまり厳密な解析は行わないため、 構文的に誤ったところがあっても適当に表示されてしまうのですが、 そのいいかげんさはブラウザによって異なります。 このため、Netscape Navigatorではページの著者が 意図した通りに表示されたが実は文書内に誤ったタグ付けをした箇所があり、 Lynxで同じページを見たら変な表示になってしまう、 ということはあり得ます。 というか、実際よくあります。つまり、ブラウザでは文書のタグ付けが 適切かどうかはチェックできません。タグ付けのチェックについては「HTML文書を検証する」の節をご覧下さい。

たとえ構文的に正しくても、見出しの中に文章を書く(<H1> ... </H1> の中に延々と文章を入れるなど)などのように内容に そぐわないマークアップをすると、見る側の環境によっては非常に汚くなって しまいます。

このようなことが無いためにも、内容に即した、規則に従った適切なタグ 付けをすることが必要なのです。「私のブラウザでこういう表示になるから」 という理由でタグを付けるべきではありません。

もし適切にタグを付けたのに表示がおかしいとしたら、それはブラウザの 責任です。適切にマークアップされた文書を読みやすくきれいに整形すること こそブラウザの役目だからです。

また、適切にマークアップされたテキストには、単なる表示以上の活用の 可能性があります。例えば……

もっといろいろな活用法も考えられるでしょうが、そのためには まず文書のタグ付けが適切であることが必要なのです。

内容に即したマークアップのためには、要素名(タグ名と言った方が分かり やすいかもしれませんがあまり正しくありません)の意味を理解しておきましょう。 例えば、PはParagraph(段落)、H1〜H6のHはHeading(見出し)、HRはHorizontal Rule (水平線)に由来しています。 こういったことを知っておけば、<H3>...</H3> の中に文章を入れることはおかしいということが分かるでしょう。

ブラウザに依存しないページ

ときどき「Netscapeで見て下さい」のように書かれたページを見かけます。 しかし、特定のブラウザでないと見られないようなページは基本的には 公開すべきでありません。主に次のような理由からです。

世の中にはいろいろなウェブブラウザがあります。最近はNetscape NavigatorMicrosoft Internet Explorerが多いようですが、Mosaicが好きだ、 Netscapeはダメだという人もいます(例えば津村一昌さんのMosaic vs Netscape (リンク切れ))。ちなみに筆者はLynxを常用しており、Netscapeは 見栄えの確認をする時だとか画像が中心となる情報を見て回りたい時だとかに 「よっこいしょ」と立ち上げる程度にしか使いません。

「これこれのブラウザで見て下さい」と要求することは、せっかくその ページを見ようとした人をがっかりさせてしまったり、ときには怒らせたり してしまうことになりかねません。

また、特定のブラウザに依存したページは、WWWの最大の特徴とも言える ハイパーテキストリンクの有用性を下げてしまいます。例えば、甲という ブラウザでしか見られないページと乙というブラウザでしか見られないページ とがあったとして、この二つの間にリンクを張ることを考えて下さい。

特定のブラウザに依存しないページを作るためには、ブラウザのメーカーが 勝手に拡張したタグ(いわゆる「Netscape拡張」等)に依存しないことです。 何が標準のタグで何が独自拡張かはHTMLの入門書等に書いてある筈です。 まともな入門書なら、の話ですが。

マークアップの詳細について

個々のタグの使い方などについて、注意すべき点をいくつか挙げてみます。

見出し(heading)のレベル

<H1>〜<H6>は文字の大きさを指定するタグでは ありません。これらは、そこが見出しであることを 示すタグです。数字は階層的なレベルを示します。

多くの場合H1が文章全体の見出し(要するにタイトルと同じ)を表し、 以下、H2、H3、…と数字が増えるにつれて、章や節といった、 より下位の構成要素の見出しを表します。LaTeXを知っている人には 「\section や \subsection と同じだよ」と言えば済むでしょう。

- RFC 1866、"5.4 Headings"によれば、 H1〜H6は全て単に章や節の見出しであり、H1を文章全体の見出しとして 扱うようなことは書かれていません。だからH1にタイトルを書くのは 不適切と言えるかもしれません。ただし、タイトルを「文章全体に渡る章 (のようなもの)の見出し」とみなせば、H1にタイトルを書いても間違いとは 言えないと考えられます。

例として(やや珍妙な例ですが)、次の文書(の一部)を見て下さい。 ここでは便宜上、字下げを付けています。

<h1>ももたろう</h1>

    <h2>第一章  出発まで</h2>

        <h3>はじまりはじまり</h3>
            <p>むかしむかし、あるところに…。

        <h3>桃太郎の誕生</h3>
            <p>ある日、おばあさんが…。
            <p>桃を割ろうとするや否や…。
            <p>「ぼくはこれから鬼退治に…」

    <h2>第二章  鬼が島へ</h2>

        <h3>旅の仲間</h3>
            <p>桃太郎は犬と猿とキジに…。
            <p>「きびだんごは岡山名物」…
(以下略)

文章の階層構造を表すことを考えると、H2の後に(H3をとばして) H4が現れる ようなことはちょっとおかしなことです。ちなみに、HTMLチェッカのjweblint ではこれに対して警告を出すようになっています。なぜ警告が出るのかわから なかった人もいるかもしれませんが、それはこういう理由からなのです。 (もっとも、HTMLのDTDで定められている文書構造としては、どのレベルの 見出しがどういう順番で出てきてもいいことになっているのですが……)

なお、見出しタグの中に文章を延々と書くと、見る側の環境によっては 非常に見辛くなってしまいます。このタグはあくまでも見出しとして使う べきです。

<P>の使い方

見出し(heading)と並んで最も誤解されていると いっていいタグが <P> (paragraph、段落)でしょう。 これの正しい使い方は、 一つの段落を<P>...</P>で囲むのです。 ただし終了タグ</P>は省略できるので(「タグの省略について」の節を参照)、段落は <P>から始まると覚えても良いでしょう。

HTMLの古い決まりでは、段落の終わりを<P>で表す ようになっていました。しかしHTML 2.0以降ではこの書き方は不適切といえます。 今でもこの古い方の書き方を見かけることがありますが、現行の決まりに 従って書くべきです。

なお、「<P>は一行空けることを指示するタグである」 などという解説は不正確です。それはHTMLの決まりではなく(HTMLは整形の仕方を 定める言語ではないので)、多くのブラウザはそのような整形をするというだけの ことに過ぎません。段落の始めを(一行空きでなく)一文字下げるように 整形するブラウザがあっても一向に構わないのです。

<IMG>にはALTテキストを適切に付ける

ALTの必要性

HTMLでは、種々の出力媒体で活用できるような文書を作ることができます。 グラフィカルなブラウザで表示されるだけとは限らず、文字端末に文字ベース のブラウザで表示することもありますし、音声出力されることもあります。 これこそ「マルチメディア対応」ですね。:-)

そうしたページを作るために必要なことは、インラインイメージを表す IMG要素でALT属性の値を指定することです。ALT属性は、 文書の読み手が画像を表示できない(表示しない)場合に、画像の代わりの (ALTernative)文字列を指定する属性です (「画像の説明」では必ずしもありません)。 <IMG SRC="fig1.gif" ALT="[図1]"> と書けば、テキストブラウザでは画像の代わりに「[図1]」と表示されます。

IMGのALT属性を指定することの必要性は今までにも多くの人が 主張してきました。例えば次のようなページがあります(この他にもまだ あるでしょう)。ぜひ読んでみて下さい。

こういったページを読めば、IMGにはALTを付けなければ ならないのだということがわかるでしょう。テ キストブラウザを使う人は決して稀ではありませんし、グラフィカ ルなブラウザでも画像を読み込まずに使う人は大勢います。くどい ようですが、ALTは重要なのです。すべてのIMGにALTを付けるよう にしましょう。なお、HTML 4.0ではALT属性の指定は必須となって います。

ALTのかっこいい付け方

ALTテキストを付けるうえで考慮すべきことは、画像の代わりに その文字列を置いて整形したときに文書として体をなす ようにするということです。絵の説明やファイル名などを書いても 意味がないことも多くあります。

いくつか例を挙げてみましょう。(参考: HTML IMG tag ALT attributes)

文字のみでどう整形されるかは頭の中で想像してもいいのです が、LynxEmacs-w3と いった文字ベースのブラウザで実際に見てみるとよいでしょう。こういった ブラウザを使える環境にない人は、Lynxでどう見えるかをWWW上で確認できるLynx-Viewの ページを使ってみましょう。

アンカーの指定の仕方

<A>...</A> の範囲(A要素)がアンカーです。 HREF属性とNAME属性のどちらの値を指定していてもアンカーなのですが (一つのアンカーでこの両方の属性の値を同時に指定することもできます)、 ここでは主にHREF属性の値(即ちリンク先)を指定する場合の話です。

アンカーとして「ここ」「こちら」「here」等を指定することは 良くないスタイルだとされています (HTML入門――WWWページの作成と公開 (前掲)第4章)。

例を挙げます。同じ内容を表している次の二つの文を比較してみて下さい。

  1. 詳しい情報はここをクリックして 「最新の彗星観測情報」を ご覧下さい。また、用語集はこちらですので ご利用下さい。

  2. 詳しい情報は「最新の彗星観測情報」 をご覧下さい。また、 用語集を用意したのでご利用下さい。

2番目の書き方がより自然で読みやすいのは明らかでしょう。 1番目のように書くべきではありません

アンカーに指定する文字列は、飛び先にあるものを適切に表すものにすべきです。 目安としては、アンカーであることを示す目印(色が変わるとか)が無くなっても 文章としておかしくないようにと考えればよいでしょう。 アンカーがあっても文章は文章ですから、 文章として変でない文章でなければなりません。

また、飛び先のページのURLのみを書いてアンカーとしているものを ときどき見かけますが、これはあまり良い方法ではないでしょう。 URLは単に場所を示しているに過ぎませんから、URLをその文書のタイトルで あるかのように扱うべきではありません。

<A>について、文法的に良くない書き方をいくつか 挙げてみます。次のいずれも、ブラウザによっては実際に不都合が生じることが あります。

これらが間違いであることの詳しい理由は、HTMLのDTDを読んで みよう(矢野)の2.3節「例3: アンカーの宣言を読む」をご覧下さい。

HREF属性の値として記述するURLについて言うと、ディレクトリを指すURLの 場合は最後に `/' を付けることが必要です。詳しくは、「ホーム ページ」のウソに書かれています。

HTML以外のテキストや画像へのリンクの場合、TITLE属性でリンク先の題を 指定することができます。<A HREF="example.txt" TITLE="An Example">のようにすれば、リンクをたどって テキストファイルを表示させたときに、TITLE属性で指定したタイトルも一緒に 表示されます。タイトルが付いていた方がちょっと嬉しいですよね。

<TABLE>をどうしよう

表(TABLE要素)はHTML 2.0では定義されていません。 HTML 3.2以降では採用されていますが、ブラウザによっては完全にはサポート されていません。

普通に考えればそのようなタグは濫用すべきでないのですが、 「表であることが自然な場合」にtableを使いたいと思うのはもっともな ことです(レイアウトのためにtableを使うなどは論外)。 このような場合、tableを使ったバージョンとそうでないバージョンの 両方の文書を用意しておくという手があります。あるいはなんとかtableを 使わずに済ませることができるかも知れません。もしtableが 無いとにっちもさっちもいかないという場合には、断り書きをした上で table使用バージョンのみ用意するのが妥当でしょうか。

結局ケースバイケースということになりますが、内容に 即したマークアップブラウザに依存しない という二つのポリシーの兼ね合いで決めることになるでしょう。

タイトルに日本語の文字を使ってよいか

一部のブラウザでは、TITLE要素に日本語の文字を使うと 文字化けしてしまってタイトルが読めないということが起こります。 このため、TITLEに日本語の文字を使うべきでないと いわれることがあります。これは確かに一理あります。

しかし、本文のテキストに日本語の文字を書いていいのにTITLE だけは日本語を使うなという決まりはHTMLにはありません (国際化 版HTML 2.xおよびHTML 4.0以外のHTML文書に日本語の文字を書いて はいかんというのであれば、それはそれで筋が通っているのですが)。

日本でWWWがこれだけ普及している状況を考えると、日本語の文字で 書かれたタイトルが読めないというのは、ブラウザを作る側の怠慢と言われても 仕方ないのではないでしょうか。

実際問題としてタイトルが読めないのは嫌だというのはわかりますが、 上のようなことから私はTITLEに日本語を使っています。(もっとも、 私が普段使っているLynxでは日本語TITLEも当然のように表示できるからという こともあるのですが…)

TITLEは単にブラウザに表示されるだけでなく、ブックマークの一覧 (ホットリスト)やサーチエンジンの検索結果等に使われたりもします。 内容を適切に表現するタイトルを付けるべきです。

DOCTYPE宣言を付ける

DOCTYPE宣言はその文書で使用するDTDを宣言するものです。といっても 分からない人もいるかと思いますが、とりあえず「使用するHTMLのバージョンを 明記する」ものだと思って下さい。

最も基本的なHTMLであるHTML 2.0に従う場合は、文書の先頭の行に、下の例のように 書きます。その次の行から <HTML> ... などのように おなじみのタグを書き始めます。

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

HTMLでは厳密にはラテン文字しか使ってはいけないことになっ ています。この点を改善するため、HTML 2.0の国際化版が作られま した(HTML 2.x, RFC 2070)。HTML 2.0に準拠しかつ文書中に日本語の文字を用 いる場合にはこれを使うのが良いでしょう。この場合のDOCTYPE宣 言は次のようになります。

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

また、HTML 3.2を使う場合には次のようなDOCTYPE宣言になります。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

ただしHTML 3.2はRFC 2070と違って国際化版ではありません。 HTML 3.2の次のバージョンであるHTML 4.0(コードネームCougar) ではRFC 2070のような国際化が施されています。

HTML 4.0のDOCTYPE宣言は次のようになります。今後はHTML 4.0 を使って書くのが良いでしょう。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

DOCTYPE宣言を書く以上は、そのバージョンのHTMLの決まりに 正しく従って下さい。HTML 2.0を使うと宣言しておきながら CENTER要素などを使ってはいけません。

今までHTML文書を書いていたがDOCTYPE宣言というものは知らない、 という方もいるかも知れませんが、これは何も目新しいものではありません。 SGML文書には必須といって良いものです。RFC 1866にもある通り、 HTMLはSGMLの適用例の一つとして定義されており、HTML文書はSGML文書です。 ですからHTML文書にはDOCTYPE宣言が必要なのです。

ちなみに、User Agent (ブラウザ等)は、 DOCTYPE宣言のない text/htmlメッセージについてはHTML 2.0のDTDが 宣言されたものとみなすべし、との注記がRFC 1866にあります。

mailto-link

HEAD要素の中に、次のようにしてあなたのメールアドレスを書 いておきましょう。これでそのページの著者へのメール連絡先を表 します。

<LINK REV=MADE HREF="mailto:somebody@foo.bar.jp">

こうしておくと、Lynxでは = キーを押してそのペ ージの情報を表示したときに "Owner(s)" としてそのメールアドレ スがURLの形で表示されます。また、c キーを押すとそ のアドレス宛にメールを送るモードになります。いずれはLynx以外 のブラウザでもサポートされるようになるでしょう(なるといいな あ)。

LINK要素は見慣れないという人もいるかと思いますが、ちゃんとHTML 2.0で 定義されています。これはHEAD要素の中にだけ現れ得るものなので、 TITLE要素の前にでも(後でも構いませんが)書いておきましょう。

それにしても、私のようにmailto-linkの警告をenabledにしてjweblintを 使っている人って少ないのかなあ……と、ふと思う。

フレームは使わない

フレームを使わざるを得ないのは余程特殊な場面だけでしょう。普通の ページであえてフレームを使うだけの利点は見あたりません。一方で欠点は いろいろとあります。

対応していないブラウザに対してはNOFRAMES要素として文書本 体を記述しておくのですが、ここに「フレーム対応のブラウザで見 て下さい」としか書いていないようなページは困りものです。もし フレームがないと原理上不可能というページなら(そんなページは まず滅多にないでしょうが)、その旨の説明があるべきです。

<BLINK>は使わない

<BLINK>は見づらいだけなので使わないで 下さい。語句を強調したいのなら<EM><STRONG>を使うのが筋です。ちなみにこの <BLINK>は一部のブラウザのみのローカルな仕 様です。

<!----->、<! comment >、<!-- comment --!> は間違い

HTMLの正しい注釈は次のように書きます。(RFC 1866, 3.2.5 Comments より)

  1. `<!' ではじまる。

  2. それに続いて0個以上の注釈が書かれる。各注釈は -- で はじまり、文字列がそれに続き、次に -- が現われたところで終わる (最後の -- までが注釈)。 各注釈の後には空白を入れることができる。ただし、先頭の `<!' と一つめの注釈の間には空白を入れることはできない (`<!--' は正しいが `<! --' は駄目)。

  3. `>' で終わる。

つまり、<!-- 注釈1 -- -- 注釈2 --> のような書き方も できます。ただし -- の数が合わないといけません。 <!----> は正しく閉じられた 注釈になりますが、<!------> ではコメントが閉じられて いません。分かりますか?

もし分からなければ、「注釈の中に `-' を2個以上続けて 書いてはいけない」と覚えておくのが無難です。理解したとしても、間違いを 起こしやすい <!----------------> のような書き方は しない方がよいでしょう。

なお、上の規則からすると、<!-- comment --!> の ような書き方が間違いであることは明らかです。これを注釈として扱ってしまう ブラウザもありますが、だからといって間違った書き方をすべきではありま せん。

注釈が閉じられていないと、文書の途中から最後までが 全て注釈として扱われ、ブラウザに表示されなくなってしまいます。甚だしい のは文書の先頭に <!-- foo --!> などとある場合で、 本文全体が注釈とみなされてしまい、ページが全く表示されません。 私はそういうページをときどき見かけるのですが、ページを作っている人の ブラウザでは誤った注釈が(困ったことに)注釈として扱われてしまっているの でしょう。

書き方ではなく用語の問題ですが、HTMLの注釈<!-- ... --> はタグではありません。<! ... >の形はSGMLでは「宣言」と 呼ばれ、SGML宣言や要素宣言や属性宣言などがあります。注釈もこれの仲間で、 注釈宣言(comment declaration)と呼ばれます。

むやみに強制改行しない

普通に文章を綴るうえで <BR> (強制改行) が必要になることはあまりありません。「ここからここまでが一つ の段落」とタグで指定しておけばブラウザは自動的にきれいに整形 してくれますから、ブラウザが改行すべき位置をわざわざ手動で指 定する必要はないのです。文書の構造と体裁とを切り離して考える のがHTMLの基本思想です。

強制改行の濫用はHTMLの長所を損なうことがあります。例えば、 <BR> を続けて書くと空白行ができるブラウザ がありますが (そうでないものもあります)、これを利用して語句 の上下に空白を空けて「見出し」を作るべきではありません。HTML を処理するプログラムはそれを「見出し」とは認識できないからで す。ブラウザが目次を作ったり検索システムがインデックスを作っ たりするうえで見出しは重要な役割を果たします。見出しを表す要 素 (H1〜H6要素) として正しくマークアップする必要があります。

これは何も「見出し」に限ったことではありません。段落にせ よ、リスト (箇条書き) にせよ、強制改行を使わずに適切にマーク アップしておけば、スタイルシートによって表示方法を柔軟に変更 したり、特定の種類の要素だけに対して操作したりということが可 能になります。

また、不要な強制改行は表示のうえでも問題になります。1行ご とに強制改行したりすると次のようなことになります。

ブラウザで整形する前の、いわゆる「ソース」での改行文字の 扱いについては、HTML文書中の改行 文字について (矢野) をご覧下さい。

HTML文書を検証する

先に述べたように、ウェブブラウザによるHTML文書の解析はいいかげんな ものです。これは、間違ったHTML文書でもそれなりに表示できてしまうので 便利といえばいえるのかも知れませんが、HTML文書の検証の役には立ちません。

SGMLでは、文書の適合性を検査するためにパーザ(parser)を用います。 これはDTDに従って厳密に解析していき、無事に解析が終わればOK。もし途中で 構文的な違反が見つかればアウトというものです。HTMLはSGMLの適用例の一つ なのですからパーザを使えば良さそうなものなのですが、不幸にも(と、私は思う) そういう習慣はありません。

本来、ウェブページを書いて公開するまでの流れは次のようであるべき でしょう。

  1. HTML文書を書く。

  2. パーザで検証し、誤りがあれば文書を訂正する。

  3. 公開する(ブラウザで閲覧される)。

パーザではありませんが、HTML文書の誤りをチェックするツールがいくつか あり、手軽に使うことができます。日本語に対応しているものとして、 Neil Bowersさん作のWeblintを石川雅康さんが日本語化したjweblint (Weblint 97)が有名です。また、Another HTML-lintというツールもあります。

こういったツールは必ずしも厳密な解析は行わないようですが、 ただ単にDTDと照らしての検証以上に踏み込んだ親切な(お節介な?)チェックも してくれます。例えばjweblintでは、アンカーとして「ここ」「こちら」 「here」を指定すると警告を発します。また、タグが大文字か小文字かに 揃っていないと警告を発するというような趣味的な項目もあり、 こういった警告は好みに応じて自由に抑制することができます。 なお、Weblint 97のパッケージに含まれている「警告メッセージ一覧」は HTML文書を書くうえで参考になるので、 一度目を通しておくことをお勧めします。

また、Windows用のHTMLチェッカでwbpacというものも あります。

ウェブ上で利用できる、SGMLパーザを使ったHTML検証サービス として、Libra というものを私が作っていますので一度お試しください。SGMLパー ザの入手先も併せて載せておきました。

HTML文書を検証する手段としてはこのようなツールを使うこと がほとんど唯一の手段といえます。必ずチェックをかけて、誤りが ないことを確認してから文書を公開するようにしましょう。 jweblintにはWWWから利用できる公開ゲートウェイもあるので、自分のマシンにインストール する前に試してみることもできます。


補足編

タグの省略について

HTMLのタグには省略可能なものもあります。 これについて少し説明します。

まず、HTMLのタグを命令だと思っていたら、その考えは捨てて下さい。 「タグ = 命令」説では、<HEAD>のようなタグの存在や タグの省略などをうまく説明できません。実際にもタグは何も命令してはいません。 文書を構成要素ごとに切り分け、その要素が何であるか(見出し、段落、題、 などなど)を説明するような目印としてタグは存在しています。

タグの省略が許されているのは、そのタグが無くても要素の区切りが 厳密に推論できる場合です。例えば、<P> で段落が始まって、 終了タグ </P> が現われることなしに次の <P> が現われたらどうでしょうか。 <P> ... </P> は入れ子にすることはできませんから、 新たな <P> が現われた時点で前の段落が終わったことは 明らかです。このため、終了タグ </P> が省略できるのです。

ある要素のタグが省略できるかできないかはDTDの要素宣言に書 かれています。HTMLのDTDはHTMLの仕様書に含まれています (HTML 2.0ならRFC 1866の "9.1 HTML DTD")。

例えば、</P>と同様に省略が許されている タグには、</LI></DT></DD><HTML></HTML> などがあります。

ちなみに、HTML・HEAD・BODYの各要素は開始タグも終了タグも 省略することができます。これらのタグを書かないとHTML文書とし て正しくないと書かれている本もありますが、誤りです。

タグの省略は入力の手間が省ける半面、HTMLの仕様で定義され ている文書構造を把握していない人にはわかりづらいという難点が あります。例えば段落があったとして、段落の終了タグ </P> が現われずに <UL> が現われた場合、段落の中にリストが含まれていると誤解される可 能性があります。実際には、HTMLの文書構造では段落の中にリスト を含むことはできないので、<UL> が現われた 時点で段落は終了していることになります。

省略可能なタグであっても書いておいた方が読む人にとっては わかりやすい場合もあると言えますが、</LI> をいちいち書くのはさすがに目障りな気がします。別に決まりがあ るわけではありませんが、私はHTML・HEAD・BODYの各要素について は開始タグも終了タグも省略せずに書くことにしています。

タグの省略に関してはもう一つ、終了タグを書いてはいけない というケースもあります。IMG・BR・HRなどのように要素内容が空 である要素については終了タグを書いてはいけません。開始タグの みが使われます。

誤用される「ホームページ」

「ホームページ」という言葉をWWWのページ一般を指す言葉として 用いるのは誤用です。この意味では「WWWページ」「ウェブページ」のように 言うべきです。

現在、日本では「ホームページ」という語は次の3通りの意味で 使われています(発生順)。

  1. WWWブラウザを起動したときに最初に読み込まれるページ。

  2. 一群のページの最初に見るページ(すなわち welcome page。 トップページとかフロントページと呼ぶ人もいる)。

  3. WWWのページ一般。

「ホームページ」というのは本来的には1番目の意味の言葉です。2番目の 意味はそこから派生したものでしょう。2番目の用法では「ホーム」の意味が 残っていますが、3番目の用法ではもはや、何が「ホーム」なんだかわかり ません。

3番目の意味での使用はマスコミ等で最近盛んに行われていますが、あくま でも誤用であり、好ましくありません。"HP" と略すことは特に嫌われます (コンピュータ関係でHPといえばヒューレット・パッカード社のことです)。

WWWのページ一般を指す語としては、「WWWページ」とか、(World Wide Webのページですから) 「ウェブページ」などと呼ぶのが妥当です。 英語では web page という言い方が多いようです。

なお、上に挙げた2番目の意味での用法は、本来は正しくありませんが、 「ホーム」の意味が残っているので許容範囲と考えられます。

この項の参考文献:


参考文献


広告

1996年12月 初版公開, 1998年4月11日 最終更新, 2004年2月21日 リンク修正
矢野啓介 (Email: yano@moon.email.ne.jp)
権利・文責等は諸注意のページによります。