ちょっと不思議なテキストレベルの要素タイプ - 仕様書に見るHTML(5)

1.1 ハイライト要素の誕生

黎明期のHTMLでは、見出しやパラグラフ、タイトルといった要素は早い段階で定番となっていましたが、フレーズのマーク付けに関しては曖昧な状態が続きました。初期の資料を見ると、HP1、HP2...（highlighted phrase）といった汎用要素を用いて、HP1は斜字体、HP2は太字という具合に、ハイライトの方法を任意に決めていたようです。

1992年の夏頃からHTMLのDTDをきちんと定めようという動きが出始め、バーナーズ＝リーからその作業を任されたダン・コノリーが、さまざまな文書システムを研究しながら要素タイプの候補を絞り込んでいきました。1992年11月19日のwww-talkメーリングリストで、コノリーは次のように書いています。

What about <HP1> thru <HP5>... should we include them? I'd prefer <em>, <tt>, <cite>, ala TeX. Or we could go with the O'Reilly/Hal DocBook tags: <Emphasis>, <OopsChar>, <wordasword>,<CiteBook>,<Subscript>, <Superscript>.

いくつかの議論を経て、語句をハイライトする要素タイプは、Texinfo（ひとつのソースから印刷用とオンライン用の文書を生成するシステム）のコマンドを参考に定義されます。HTMLのバージョン1ともいうべき1993年のインターネットドラフトでは、Character highlightingのセクションに、その典拠を示す次の一文が記載されていました。

These element names are derived from TeXInfo macro names.

2.1 CODE要素タイプ

HTML4仕様書の定義は Designates a fragment of computer code. です。プログラムのソースコード（の部分）を示すための要素タイプとされており、このままではあまり使い道がなさそうですが、Texinfoのマニュアルにはもう少し具体的なヒントが見られます。

you should use @code for an expression in a program, for the name of a variable or function used in a program, or for a keyword. Also, you should use @code for the name of a program, such as diff, that is a name used in the machine

これによると、codeはプログラム内の式を引用したり、変数、関数、プログラムの名前といったキーワードをマーク付けするときに利用できることが分かります。たとえばHTMLについて説明する本稿のような文書なら

強調要素タイプには<code>em</code>と<code>strong</code>があります。

といった使い方が考えられるでしょう。

2.2 SAMP要素タイプ

HTML4の定義は Designates sample output from programs, scripts, etc. で、プログラムの出力サンプルを示すとなっています。HTML2では、indicates a sequence of literal characters すなわち（単語として意味をなす、なさないにかかわらず）その文字の並びを示したい時に使うとされています。両者の説明にはずいぶん隔たりがありますが、共通しているのは、与えられた字句をそのまま受け取っておけばよい部分のマークアップ、ということになるでしょうか。

Texinfoのマニュアルでは、

Basically, @samp is a catchall for whatever is not covered by @code, @kbd, or @key.

という具合に、他の要素タイプがうまく当てはまらないフレーズにはsampを使うとしています。

2.3 KBD要素タイプ

この要素の定義 Indicates text to be entered by the user. は比較的明快で、HTML2やTexinfoとも矛盾はありません。マニュアルや説明ページで

パスワードを求められたら<kbd>open sesame</kbd>と入力してください

などと書く場合に使えます。"Enter"を押す、といった個別キーの指定も、kbdの範疇と考えて良いでしょう。

2.4 VAR要素タイプ

仕様書の定義は Indicates an instance of a variable or program argument. です。instanceなどと言われると何のことだ？と思ってしまいますが、要するに状況により異なった値となる部分を、変数として仮の名前でマーク付けするわけです。

ユーザ欄には<var>username</var>を入力してください。

kbd要素の例と比較してみてください。HTML2では indicates a placeholder variableと、ずっと分かりやすい表現で定義されています。

2.5 CITE要素タイプ

HTML4の定義は Contains a citation or a reference to other sources. となっています。このcitationとは引用文そのものではなく、その出典の意味なので混乱しないこと。HTML2の定義はもう少し具体的で、to indicate the title of a book or other citation となっています。

blockquote要素やq要素による引用部分と合わせて出典を示すほか、HTML4仕様書の例にあるように参照文献のマーク付けにも利用できます。

More information can be found in <CITE>[ISO-0000]</CITE>.

LaTeXには、\citeコマンドとその引数を使って、本文中の文献名と巻末の文献リストを連動させるという機能があります。cite要素とid属性あるいはtitle属性の組み合わせをスクリプトなどで処理すれば、HTMLでも同様の応用が可能になるでしょう。

3.1 DFN要素タイプ

dfn要素タイプはもともとHTML1ドラフトに含まれていたTexinfoコマンドのひとつなので、いわば復活登板ですね。すでにたくさん種類のあるパラグラフ系要素にわざわざ追加するのですから、その意義を説明しても良さそうなものですが、HTML3.2、HTML4ともにIndicates that this is the defining instance of the enclosed term とそっけないものです。これでは、「definingといっても、用語だけで説明部分をマーク付けしないのに、定義になるのか？」という疑問が湧くのも無理はありません。

これもやはり、Texinfoのマニュアルにずっと分かりやすい説明があります。

Use the @dfn command to identify the introductory or defining use of a technical term. Use the command only in passages whose purpose is to introduce a term which will be used again or which the reader ought to know. Mere passing mention of a term for the first time does not deserve @dfn.

ある用語を最初にきちんと説明している部分で、その用語をdfn要素としてマーク付けします。印刷物ではそういった箇所が太字などで示されており、あとで用語に出くわした時にページをざっと繰ってみるとその定義部分が目に飛び込んでくる、そういった使い方が想定されているわけです。

これだけではブラウザの表示を人間が見る時に役立つだけで、マシンにも理解できるような意味のマーク付けにはなっていません。しかし、dfn要素にidをきちんと与えておくと、HTML文書からこれらの要素を抽出して、索引や用語集を簡単に生成できるというメリットがあります。あるいはスクリプトを使って、ページ内のキーワードを冒頭にまとめて表示するなどの応用も考えられるでしょう。こういった観点でマーク付けを行うと、dfnはとても利用価値の高い要素タイプになります。

4.1 略語を示すABBRとACRONYM

ABBR, ACRONYMの2つはいずれも略語をマーク付けして示すもので、機械翻訳や音声読み上げなど、ウェブの多様な利用を助けるものとされています。

Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers. (9.2.1)

一般には、略語をこれらの要素としてマーク付けし、title属性を使ってそのフルスペル（展開型）を示します。

The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.

ここで問題になるのが、この2つの要素タイプの使い分けです。辞書によれば、acronym（頭字語）とは広い意味では「単語の頭文字をつないで構成したことば」となっています。仕様書でも

Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations like "M.", "Inc.", "et al.", "etc.".

と記されていることから、頭文字はacronym、省略形はabbrかと思われるのですが、その直後に

<ABBR title="World Wide Web">WWW</ABBR>

という用例が示されており、混乱を招きます。

これは、acronymの狭義の定義「（NATOのように）つないで発音されるもの」に従ったものと考えることもできます。事実、仕様書には発音を意識した記述がありますし、WAIのメーリングリストでもabbrとacronymの発音による使い分けに関する意見がたくさん見られます。しかし発音を基準に考えても、"F.B.I."がacronymで"WWW"がabbrであるという違いについては依然よく分かりません（それに発音をどうするかは、基本的にはスタイルシートに委ねるべきでしょう）。

4.2 ABBRとACRONYMの背景

この2つの要素タイプは、HTML+の草案にも登場しているように、かなり古くから検討されてきたものでした（当時はabbrではなくabbrev）。HTML4の最初の草案ではacronymのみが採用され、用例としても頭文字の語句だけが示されていますが、1997年11月7日の勧告案の段階で、より一般的な略語を示すabbrに変更され、現在の仕様にも見られる"etc."といった例も追加されます。これが同年12月18日の勧告では両者併存という形に再度変更されました。

草案と勧告案の説明を比べると、acronymがabbrに入れ替えられた理由には国際化を意識した部分があることが伺えます。「頭文字」というのは、欧米語のような分かち書きを前提とした考え方で、日本語などでは必ずしも「頭」をとって省略形をつくるとは限らないということがあるわけです。

勧告案での修正がそれなりに合理的であるのに対し、最終勧告でacronymが復活したのは明快な理由が示されていません（先行してacronymを実装したブラウザがあったので仕方なく復活させた、という俗説もありますが、本当のところは不明です）。仮に、上記のWWWがabbrになっている例は勧告案から勧告に変更する際の修正漏れだとすれば、acronymは頭文字、abbrはその他略語全般という使い分けを目指したとも受け取れるのですが。

結局、HTML4仕様書でのabbrとacronymの違いは、エディタの一人であるイアン・ジェイコブズがメーリングリストで述べているように、あえてはっきりさせていないということかも知れません。

The definitions (in English) of abbreviations and acronyms are not mutually exclusive, and the HTML Working Group decided to leave both element names in rather than choose one or the other. If the specification is unclear on this point, it's because the Working Group felt they weren't linguists and didn't want to define precisely when one element should be used and not the other.

ジェイコブズは、個人的な意見として、上記のような頭文字とそれ以外による使い分けを示唆しています。しかし、使い分けることによって特にメリットが得られないのであれば、勧告案の示すように、全てのケースでabbrに統一しておくのが最も分かりやすい考え方でしょう。

4.3 アクセシビリティと略語

略語の展開型をtitle属性で示すのは、アクセシビリティの観点で重要だといわれますが、実際に音声ブラウザはこれを役立てているのでしょうか。手元で確認した範囲では、IBMホームページリーダー（HPR）のバージョン3.01は、acronym要素の箇所で「ステータスバーの読み上げ」という操作を行うことで、確かにtitle属性の内容を読み上げてくれます。

ただし、HPR3.01はInternet Explorerをベースにしているため、abbr要素には反応してくれません。これを解決するには、略語を全てacronymとしてマーク付けするか、スクリプトなどで内部的にabbr要素をacronym要素に変換する必要があります。また、どの部分が略語としてマーク付けされているかは、普通に読み上げているだけでは分からないので、使い勝手もあまり良いとは言えません。略語に関するアクセシビリティの向上は今後に期待というところです。

同じ略語が文中に何度も登場するというのはよくあるケースですが、これに関しては、WAIのガイドラインに次の記述があります。

4.2 Specify the expansion of each abbreviation or acronym in a document where it first occurs.

最初に登場する略語にtitle属性を与えておけば、ブラウザがその内容を記憶し、それ以降は略語としてマーク付けされている同じ語句に自動的にフルスペルを適用してくれるということでしょうか。実際には、音声合成に限らずまだそのようなブラウザは存在しないため、文書の途中から読み始めたりすると略語情報の存在が分からないままになりかねません。現状では、全てとはいわないまでも、主要なポイントで繰り返しtitle属性を指定する方が、情報はうまく伝わりそうです。

4.4 フレーズ系要素タイプ定義の難しさ

ここまで見てきて、何だかアンバランスな印象を持たれたのではないでしょうか。cite、dfn、abbrなどはともかく、code、samp、kbd、varを細かく使い分けることにどれほどの意味があるのかと。一方で、日時や人名など、もっと利用価値の高そうな要素タイプはまったく定義されていないのです。

HTML3の草案では、まさに人物を示すPERSON要素や、作者を示すAU要素などが提案されていたのですが、この方向に進むと切りがなくなります。先に挙げたコノリーのメッセージに対するバーナーズ＝リーの返信も、こうした難しさを述べていました。

The trouble is, you never have enough. Why CiteBook but not CiteProgram? etc etc.

見出し、段落といった大きなブロックと異なり、フレーズの意味をどう定義するかは人によって考え方がかなり異なります。語彙の拡張はXMLと名前空間に任せる方が賢明でしょう。

HTMLの長所のひとつは、そのシンプルさにあります。情報がうまく共有できさえすれば、あまり神経質にフレーズをマーク付けする必要はありません（HTML4仕様書で多くのフレーズ系要素タイプの定義がお座なりなのは、そういう意味を込めているのかと考えたくなるほどです）。読者の立場で、どんな情報がマーク付けで明示されていたら使いやすいのかを考え、自分なりのルールを決めて適宜利用するのがいいのではないでしょうか。

5.1 内容モデルの例外規定

insとdelは本文のあらゆる部分を編集できるようにするため、body要素の内部のどこにでも自由に出現可能になっています。これを、DTDでは

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) >

という具合に示します。要素タイプ（のグループ）の前に+を加えたものは「添加要素」と呼ばれ、その内容の子孫に渡ってどこにでも出現できます。この規定により、p要素タイプなどの内容モデルにins, delが含まれていなくても、パラグラフ内で挿入や削除が可能になるのです（仕様書3.3.3のDTDの読み方では、この部分がきちんと説明されていないので注意が必要です）。

一方、ins, del要素タイプの内容モデルは、次のようにブロック、インラインを問わず何でも取り込めるものになっています。

<!ELEMENT (INS|DEL) - - (%flow;)* >

DTDだけを見ると、p要素内にins要素を記述し、その中にulやol要素を埋め込めば、段落内にリストも記述できることになります。しかし、こうしたブロック、インラインの整合性を崩すような使い方は、仕様書の本文で禁止されています。

The INS and DEL elements must not contain block-level content when these elements behave as inline elements. (9.4)

HTMLのルールは、DTDだけでなく仕様書の本文も合わせて規定されているのです。

5.2 修正日時の書式

ins、del要素は、挿入、削除を行った日時をdatetime属性に記すことができます。これをうまく利用してスクリプトと組み合わせれば、ひとつのファイルでバージョンの履歴を提供することもでき、応用の可能性が広がります。

この日時の書式は、仕様書がdatetime型と呼ぶ特定のフォーマットを使うよう定められています。

[ISO8601] allows many options and variations in the representation of dates and times. The current specification uses one of the formats described in the profile [DATETIME] for its definition of legal date/time strings ( %Datetime in the DTD).

The format is: YYYY-MM-DDThh:mm:ssTZD (6.11)

ISO8601は日時表記方法の国際標準です。[DATETIME]で示されるプロファイルは、これを使いやすいシンプルな形にまとめたもので、W3C-DTFと呼ばれます。W3C-DTFには年月日だけ（時分秒を省略）の形も含まれているのですが、HTML4仕様書はなぜか時分秒とタイムゾーンまで含めた完全型のみしか認めていません。

Exactly the components shown here must be present, with exactly this punctuation. Note that the "T" appears literally in the string (it must be uppercase), to indicate the beginning of the time element, as specified in [ISO8601]

If a generating application does not know the time to the second, it may use the value "00" for the seconds (and minutes and hours if necessary).

時刻が分からない時は、00:00:00を加えよという規定です。プログラムで生成するページならともかく、人間が編集する時に分秒まで書けというのは無理な要求だと思うのですが、ここもHTML4仕様書9章の不思議のひとつです。

5回にわたってお届けした仕様書の読み方のヒントは、ここで一区切りとしたいと思います。世の中には不正確な情報が少なくありません。出典が示されていない説明は鵜呑みにせず、ぜひ原典にあたってください。このシリーズでお伝えしてきたことが、そうした確認の一助となれば幸いです。