物理スタイル

語句化内容 (HTML)

[26] 語句化内容 (phrasing content) は、 文章やそれに準ずる段落内の構造を記述する要素です。

[27] かつては行内要素 (inline element) (インライン要素) と呼ばれることもありましたが、明確化のため現在の名称となりました。

仕様書

意味

[25] 語句化内容は、 文書文章 (text) や、 文章段落内の水準においてマーク付けする要素です。 >>24

[28] 語句化内容連なり (run) は、段落を形成します。 >>24


[29] English の語 phrase (語句) は、 一般的には高々数個の単語連なりを指していいます。 その -ing形 phrasing は、 文章の特定の法則性のもとで語句のまとまりに区切ること (句節) や、 語句で表される言い回しを表して使われます。

[30] 対して HTML における語句化内容の「語句化」は、 こうした自然言語的な特性とは独立した、 文書構造としての構成単位に着目しています。従って、 語句化内容である要素自然言語より大きな単位にも、小さな単位にも、 それらの境界とは無関係に使えます。

[40] なお、初期の HTMLDTD での要素の分類の1つである %phrase; と現在の語句化内容は意味が少し違っています (>>41)。


[31] 語句化内容という概念は HTML5要素内容モデルや分類が整理された際に導入されました。 それ以前の HTML4 や初期 HTML5 はほぼ同じものを行内要素行内内容 (inline content) のように言っていました。

[32] ここでいう行内とは語句化とほぼ同じ意味で使われていた語ですが、 CSS でも display: inline に代表される行内の概念があり、 紛らわしいため HTML では使わなくなりました。

[33] CSS行箱のような表示上の概念で、 HTML文書構造には (br のような例外を除き) 直接出現しません。 語句化内容である要素は、の境界とは無関係に使えます。

特殊ケース

[15] 内容モデル語句内容だけの要素語句付け内容の一部の要素が除外されている場合の他に複雑な内容モデルのものがいくつかあります。

[16] ruby 要素語句付け要素の部分と rt 要素rp 要素の部分が混在しています。

[17] HTML文書中の SVG title 要素内容モデルSVG 仕様上の制約に加えて HTML語句化内容とされています。

[3] meta 要素は、属性次第で語句化要素となることもあります。

[4] テキストは、語句化内容です。

[5] 自律カスタム要素は、語句化内容です。

文脈

[21] 語句化内容またはそれに近いものが使える非 HTML 構造:

関連

[6] 語句化内容は、すべてフロー内容でもあります。

表現と構造の分離

歴史

前史

[23] SGML応用では語句化内容相当の要素の表現にいくつかの流儀がありました。 そのうちの一派は CERN SGMLguid のように hpn 要素群を使う方式でした。 hpn

[34] hpnn によって太字, 斜体などの表示効果を割り当てて使われました。

[35] 誕生当初の HTMLCERN SGMLguid から hpn を引き継いだものの、実装と仕様化は不完全のまま保留状態でした。 HTML 1991

語句化要素の誕生

[39] 予約されていた hpn 要素型群に代わって 語句のマークに使う語彙として DocBookMIME のものなどが候補に挙がりましたが、結局 GNU Texinfo のものが中心に採用されました。 code, var, em, strong, b, i などが HTML に取り入れられました。


[93] Dan Connollyの半ば頃から、 HTML の仕様書と SGML DTD の作成に取り組んでいました。 HTML2 年末に差し掛かる頃には、 当時の仕様書に未使用とだけ書かれていた hpn の処理に取り掛かりました。

[91] >>1312DanC の投稿。 TimBL の仕様書で未使用とされている hp1, hp2, hp3, hp4, hp5 をどうするかについて、

の2系統の案を提示しています。 >>1312 これに対する返信は >>2612TimBL の返答と、 DocBook に賛成するものの2件。

[36] DanC のメールでは TeX と書かれているが、正確なところは不明。 後述の通り \em, \ttLaTeX にあり、 @cite (と @emph) は Texinfo にある。 LaTeX\cite は少し意味が違って、 citation への参照を表す。

[92] >>2612>>91 に対するTim Berners-Lee の返信。 hpn の番号システムはよくないとしつつも、 絶対に十分ではないこと、例えば CiteBook があるのに CiteProgram がない、ということを指摘しました。また、 DocBook の名前は長いのではないかと書いています。

[97] これだけでは真意を把握しかねるところもありますが、 ファイル日付が>>1412 にはより詳しい記述があります。 すなわち:

  • [98] hpn は未実装
  • [99] bold / italic / fixed width の highlighting は有用
  • [100] 3案ある:
    • [101] Numbered HPn tags
      • [102] 意味がない (meaningless)、みんなどれが bold でどれが italic か覚えないといけない
    • [103] Logical tags
      • [104] >>95 >>96
      • [105] 絶対に十分ではないのでこれは bold になるのでとの理解で再利用することになるのが問題
    • [106] Physical tags
      • [107] MIMEBold, italic など
      • [108] bold, italic が利用できない環境では他の表現に置き換えられると理解しなければならない

[109] つまり、 DocBook のように論理的な要素をいくら用意したところで、 いくらでも漏れは出てきます。 例えば船名斜体にしたくても、専用の要素がありません。 斜体になるものといえば var があります。 そうなると船名var で表せばいいということになってしまいます。

[37] この TimBL の指摘は慧眼というべきで、 blockquote字下げに使われる事案など、 この後の時代にそういうものを嫌と言うほど見せつけられることになる。

[38] HTML5 の時代になって Ian Hickson物理要素の完全排除を断念して bi を新しい意味で復活させたのも、このときの TimBL と同じ判断。

[111] >>1412MIME への言及は、 MIME text/richtext に関するものですが、 MIMEHTML の関係をどうするかが議論になっていた半年前の >>110TimBL 記事の理解が土台となっていると思われます。

  • [112] MIMEHTML は同じ段階: SGML っぽいけど SGML ではないもの
  • [114] MIME text/richtextHTML を比べると、
    • [115] BOLD と ITALIC が HTML に足りていない
    • [116] HTML の論理的な見出し水準やその他の構造の扱いは、 フォントサイズを明示的に半ば参照する方式より、 異なるプラットフォームにおける比較的柔軟な書式付けを提供できることがわかっている
      • [117] TeX のかわりに LaTeX や他のマクロを使う場合などなど、 明示的な書式付けのかわりに名前付きスタイルを使うすべてのシステムで実証されている
    • [118] 技術的には HTML はいくらかのものを MIME text/richtext に与えられる
  • [124] なお HTML 仕様の hp0, hp1 は未実装

[127] text/richtext には bold, italic の他にも文字サイズ、 改行改頁、ページヘッダー・フッター、下線などの機能がありますが、 HTML に欠けているのは bolditalic というのが TimBL の判断だったようです。

[128] SGML の設計原理である一般化マーク付けの考え方が、ここで明確に HTML の従うべき方針として言語化されていることに注意したいです。 これが初出でしょうか (探せばもっと前にもあるかも)。

[129] TimBLSGMLLaTeXTexinfo の設計方針をよく理解していたのか、それとも NeXTSTEPWorldWideWeb と各プラットフォームLine Mode Browser とその他のWebブラウザーが既にあって、 利用できるフォントその他の条件がまったく異なる環境でも機能しなければならない、 という現実的制約から必然的に同じ結論に導かれたのかはわかりませんが。 WorldWideWebスタイルシート機能を持っていたので、基礎的な考え方は SGML から引き継いだのかもしれません。

[130] 逆に MIME がなんであれだけ思いっきり物理マーク付けに走ったのか。 やっぱり実装の容易さでしょうか。 MUA も負けず劣らずいろいろな環境を考慮しなければならなかったはずですが... WWW は母体となる CERN SGMLguid があったからというのは大きいのでしょうが、 text/richtext も思いっきり SGML 風の構文を採用したからには、設計者は何かしらの SGML応用に接する環境にはいたはずですよね。
[132] WWW は最初から高度な GUINeXTSTEP と一般的なテキスト環境の両方があった、 というところで判断が分かれたのでしょうかね。

[94] 付仕様書、 DTD が現存します ( HTML2 ) が、 hpn も新要素も入っていません。

[134] >>133DanC のメールには、 未決の課題が挙げられています。

Highlighting: Who's tags should we use? LaTeX seems to be an adequate
markup system for lots of folks. Its tags are
	em | it | bf | sf | sl | tt

The DocBook folks use only semantic tags: they don't have bold or italic
tags. The MIME richtext stuff has only typographic tags: no <emphasis>
or <booktitle> or any such thing.

[135] つまり、この時点ではまだ未決で、

と決めかねていました。

[140] >>139のメールですが、 HTML 仕様をアップロードした旨の案内で、 DTD の変更を説明しています。

[142] >>139 は変更点としてSGML宣言を変更して

	<bold/foo bar/   in stead of
	<bold>foo bar</bold>

のような省略形 (SHORTTAG) を禁止することにしたとしています。 実態に合わせたものですが、 >>56 とも関係します。

[143] ここでなぜ bold を例示に出したのかは謎です。 現存する前後の DTD には bold の定義がありません (>>94)。 そのものが現存しない版にはあるいは含まれていた可能性もありますが、 >>139 が変更点として挙げていないのでもっと前に追加されたことになり、 しかしより後となりますから、かなり無理があります。

[144] ともかく追加候補として bold が念頭にあったというくらいは言えるでしょうか。

[60] >>59DanC のメールは、 Texinfo に言及したメール (時差の関係でこちらが先) に触発されて次のように書いています。

Yea! TeXinfo is a Good Thing, and I think it's highly appropriate that W3 support it as an authoring environment. The beauty of TeXinfo is that it's _not_ a programming language like TeX or troff. That makes it possible to develop correct translators. (Otherwise you run into the halting problem... it's everywhere!)

I studied the TeXinfo documentation for a couple hours before I released the last version of the HTML spec. The major feature of TeXinfo lacking in HTML is character-level formatting (font changes.)

There were a few TeXinfo commands (@ctrl for one) that don't fit the HTML mold. So I looked at the LaTeX options: em, tt, bd, sl, sf and the DocBook options, and nroff, and decided I didn't have time to choose the right set.

[I'm also keeping MS Word (RTF) and FrameMaker (MIF) in mind.]

[90] これによると

とのことです。

[151] このメールの前に仕様書を公開したとのことですが、 それは送信の直前と解するべきでしょうか。 返信元のメールが , このメールが で、この間4時間弱です。 一応このメールの内容とは合致します。

[152] それともの仕様公開前の数時間と解するべきなのでしょうか。 メールTexinfo に思い至ったわけではなく、 元からちょうど調べていたところで、 その時は何も書かなかったものの、 Texinfo の話題が出たから詳しく書いたということでしょうか。

[159] この前後、仕様の新版公表時にメールで変更点を送っているので、このときだけサイレントで新版を公開したとは考えにくく、 となると説が妥当か。

[153] >>148 の 「そこで」のつながりもあまりよくわかりません。 Texinfo が良さげだと思ったものの、 @ctrl のように HTML に完全にはフィットしないので、 他にもっといいものがないか探したということでしょうか。

[154] この書き方だと、結局 Texinfo はこの時点でまだ仕様書に追加してはいなかったということになるのでしょうか。 だとすると説の方が妥当な解釈でしょうか。

[155] とわからないことだらけではありますが、 DanC がこれまでにメーリングリストで挙げられていたもの以外にもいろいろな文書形式を調べていた(調べようとしていた)ことがわかります。

[160] 他にこの時期に別言語から HTML に追加しようとしたものに、 blockquote, typewriter があります。 blockquote, <typewriter>

[56] >>55 Dan Connolly の、語句要素を入力するのが面倒なので SHORTTAG を使えるようにしませんかという提案。 TimBL の返信は否定的で、採用されず。

[126] >>125 に示された時点の DanC 案は、

As I was adding phrase-level elements (from TeXinfo:
em, strong, code, file, cite, etc.) 

とあり、 Texinfo 由来で em, strong, code, file, cite 等を追加しようとしていたそうです。

[77] >>156 このときの仕様書は現存が確認されていませんが、 DTDhtml.dtd,v に 1.3 93.01.07.00.38.36 があります。

 $Id: html.dtd,v 1.3 93/01/06 18:38:10 connolly Exp Locker: connolly $

とあります。

[75] >>156 には

Now about that last few changes to the HTML spec...

INLINE ELEMENTS

I added <em>, <samp>, <code>, and several other elements,
inspired by TeXinfo. We need these to support conventional
technical documentation. The list is not exhaustive, but
I think it's pretty good.

と変更点があり、このときの仕様書に初めて Texinfo に着想を得た要素群が追加されたようです。

[182] >>75 は inline elements という表現の初出でしょうか。

[157] >>77 によると DTD への追加分は

<!ENTITY % inline "EM | TT | STRONG | B | I | U |
                        CODE | SAMP | KBD | KEY | VAR | DFN | CITE "
        >

でした。

[78] この時に texinfo から Dan の html.dtd に輸入されたのは code, samp, kbd, key, var, dfn, cite です。 そのうちの dfnkey は数奇な運命をたどっております。 (それぞれの説明を参照されたし。)

[79] 1992年12月3日 → 1993年1月6日で %inline; として追加されたのは: em, tt, strong, b, i, u, code, samp, kbd, key, var, var, dfn, cite

[161] >>158DanC の投稿は何気に重要記事で、 追加要素に関する GNU Texinfo のドキュメント該当部分を引用しています。 ここから追加当時の code, samp, kbd, key, var, dfn, cite, @emph (em), strong, i, b の想定された用法を知ることができます。

[162] 注意したいのは、

  • [163] @ctrl がこの引用には含まれない
  • [164] 「[I left @file out of HTML -- can't remember why.]」
  • [165] @emph があるが追加されたのは em
  • [166] @t がこの引用にはある (tt に相当するがこのとき tt は追加されていない)
  • [167] u がこの引用にはない

という点でしょうか。

[168] EMail Msg <9301120436.AA00126@pixel.convex.com>, , https://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1993q1.messages/39.html

42. (Definition of these and reference
- Dan?)
They come from TeXinfo.

43. I left the TeXinfo @file element out. I don't remember why.
It might have been an oversight. Do we want it in there?

[173] >>177 TimBL:

> 43. I left the TeXinfo @file element out. I don't remember why.
> It might have been an oversight. Do we want it in there?

No too sepcific. We have enough.
[174] これが too specific だというなら、他のも too specific なのでは、 という疑問がないでもない。どこに線を引くのかは難しい問題。

[180] ちなみに >>177manHTML 化のために pre の中で b, i, u が必要という TimBL の認識を示していて、これらの要素が必要と考えられた理由の1つが知られます。

[222] >>221頃のものと思われる HTML 仕様書案で、語句化内容要素の意味の説明としては現在知られる最古のものです。 これより古いのは DanC による Texinfo からの引用 (>>158) と DTD 追加時の概要説明 (>>75) だけしかありません。

[223] >>158 の引用は語句化内容要素の説明を TimBL の仕様書 ( HTML 1991 ) に追加したいが要素の意味がわからないというコメントに対する返答なので、 >>158 時点で >>158 が最も詳細な説明だったことと、それを基にした説明が TimBL の仕様書がこの後追加されたことがわかります。

[224] その追加後の状態の TimBL の仕様書の現存は確認されていませんが、 >>221 の要素の説明部分は、他の要素の説明文や途中に 「Tim BL」 と書かれた箇所があることから推測して、 Tim BLHTML 版仕様書の文言に由来していると推測されます。 この推測が正しいとすれば、 >>221語句化内容要素の説明は >>223 の追加分だと考えられます。

[225] >>221語句化内容要素の説明部分:

3.18 Character highlighting

Status: Extra

These elements allow sections of text to be formatted in a particular way, to provide emphasis, etc. The tags do NOT cause a paragraph break, and may be used on sections of text within paragraphs. Where not supported by implementations, like all tags, these should be ignored. All these tags have related closing tags, as in

This is <EM>emphasised</EM> text.

Some of these styles are more explicit than others about how they should be physically represented. The logical styles should be used wherever possible, unless for example it is necessary to refer to the formatting in the text. (Eg, "The italic parts are mandatory".)

3.18.0.4 Note:

Browsers unable to display a specified style may render it in some alternative, or the default, style, with some loss of qualtity for the reader. Some implementations may ignore these tags altogether, so information providers should ettempt not to rely on them as essential to the information content. These element names are derived from TeXInfo macro names.

3.18.1 Physical styles

TTFixed-width typewriter font
BBoldface, where available, otherwise alterntive mapping allowed.
IItalic font (or slanted if italic unavailable).
UUnderline??

3.18.2 Logical styles

EMEmphasis, typically italic.
STRONGStronger emphasis, typically bold.
CODEExample of code
SAMPA sequence of litteral characters
KBDin an instruction manual, Text typed by a user.
VARA variable name
DFNThe defining instance of a term
CITEA citation

3.18.3 Examples of use

See test complete markup set. Tim BL

[372] key の説明がなぜかありません。 DTD にはあります。


[210] このとき追加された要素を出所で整理すると、

の3系統の元言語から取り込まれたことになります。

[214] 当時の資料を発掘する前の古い分析:

[80] >>79 1993年5月の GNU Texinfo 3.1 のマニュアルの語句要素相当の部分と比較すると:

という違いがあります。 ctrlHTML には相応しくなかろうと Dan Connolly が発言しています。 rscTexinfo 2 の新機能と NEWS に書いてあるので、もしかすると Dan が参照した版には入っていなかったのかもしれません (し、入っていたけどフォントを直接指定するものはあえて除外したのかもしれません)。

[82] 予想ですが、 ememph では長すぎるから (LaTeX より拝借)、 ttt では短すぎるから (それほど使わなそうな割に)、 uMicrosoft Wordbi と一緒にあるから、というような理由ではないでしょうか。 (名無しさん)

[83] んー、でも RTF 1.0 に含まれているのは \u ではなく \ul だ。。。 (名無しさん)

[84] em が略されて strong が略されなかったのはなぜでしょう。 LaTeX になかったから?

[179] >>148 にあるように DanCLaTeX を検討していて、そこに emtt があります。理由はわかりませんが、 この2つだけは LaTeX から採られたと考えて間違いなさそうです。

[220] >>157DTD 追加部分の要素の順序、改めて見ると emtt が先頭にあります。 code から citeTexinfo のマニュアルの順序そのままです。 間に strong, b, i, u が挟まっているのがよくわかりませんが。

[215] u は今のところ先行する言語の採用例が見つかりません。しかし特徴的な 「B」「I」「U」 ボタンに着想を得た可能性はありそうです。

[219] >>218MacintoshMicrosoft Word 3.0 () の画面写真。 「B」「I」「u」 とボタンが並んでいるのがわかります。

[226] ところで >>222 からの経緯で作られた HTML の仕様書で u が「下線??」 と意味が不明になっていることは見逃せません。 追加後何ヶ月も立たないうちに、追加の当事者らによって作られた仕様書であるにも関わらず、 早くも新要素の意味が推測だけで書かれるという、異常な事態が起こっています。

[227] DanC の引用には @i, @b, @t があって utt はありませんが、 DanC はそれに気づかずに(?)メールを送っています。 @fileHTML から抜け落ちたことには気づいているのですが。

という HTML との違いを説明しなければならないはずなのに、そのことに気づいていないし、 @file が抜けている理由も覚えていない DanC たん、 クリスマス休暇を挟んだ1ヶ月ちょっとの間で旧年中の作業のことが記憶から消えちゃうおっちょこちょいさんですね...

[230] そのおっちょこちょいで、意図しないことが起こっている可能性というのも、 一応考えておいた方がいいのかもしれません。 @t をみて t を追加しようとしたのに、うっかり u を追加してしまった、とか。

[231] u だけ敢えて他のところから探してきて追加したのだとすると、 それを忘れちゃうというのは流石にどうかと思うのです。たくさんあるうちの1つとかではないので。

[42] HTML DTD では %inline; に分類されていました。 %inline;#PCDATA%inline; とされていました。

[41] HTML DTD から %inline; が細分化されました。 これによって次のような階層関係になりました。

[50] この DTD での使われ方を分析すると、どうやら pre物理要素pre 以外と論理要素、という組み合わせに限定しようと考えていたようです。

[51] pre との組み合わせはその後断念されますが、 このときの物理要素論理要素の区別は HTML4 まで残りました。

[444] HTML 2.0 本文ではこの区別が phrase markup のうちの Typographic Elements と Idiomatic Elements の区分となっています。

[86] 関連: key, cite

[176] >>175 pre の中で制限するしない問題

[545] HTML要素概説
要素名
bold
日付
説明
Dan Connollywww-talkHTML 仕様書の案内を投稿したが、その例文で bold が使われた。仕様書本体は現存が確認されず、 bold が含まれていたかは不明。 >>546
出典
注釈
[548] HTML要素概説
要素名
hp1
要素名
hp2
要素名
hp3
要素名
hp4
要素名
hp5
要素名
em
要素名
tt
要素名
cite
日付
説明
Dan Connollywww-talk への投稿で、 hp1, hp2, hp3, hp4, hp5 に代わる新要素群の案を提示した。 >>131 後に em, tt, cite などが追加され hp1 などは廃止された。
出典
[43] HTML要素概説
要素名
em
要素名
cite
要素名
strong
要素名
code
要素名
file
日付
説明
Dan Connollywww-talk への投稿によると、 Dan ConnollyGNU Texinfo から HTMLem>>547, strong, code, file, cite 等を追加しようとしていた。
出典
注釈
[19] HTML要素概説
要素名
em
要素名
tt
要素名
strong
要素名
b
要素名
i
要素名
u
要素名
code
要素名
samp
要素名
kbd
要素名
key
要素名
var
要素名
dfn
要素名
cite
日付
説明
HTMLcode, samp, kbd, key, dfn, var, cite, em, tt, strong, b, i, u が追加された。 >>549 GNU Texinfo に着想を得たものと説明されている。 >>550 >>552 SW:語句化内容
出典
注釈

Texinfo からの借用

[201] DanC が明言しているように最初に追加された語句化内容要素群は基本的に Texinfo からの借用です (>>161)。

[232] GNU TexinfoGNUプロジェクトドキュメントシステムです。 GNU Emacs など GNU 製品のドキュメントで使われています。 テキスト系の専用のマーク付け言語で記述しますが、 TeXマクロとして実装されていることから Texinfo の名があり、印刷物形態のマニュアルを生成することもできますし、 専用プログラム等で画面表示することもできます。

[233] 書籍版は TeX の提供する高品質な組版機能に預かることができる一連なりの静的な頁媒体であるのに対して、 画面表示は章節ごとに区切られ前後・上層・下層に移動できる閲覧ソフトウェア内で、 当時の貧弱な (しかもプラットフォームごとに違いの大きい) 基礎的な文字表示機能だけの文章が上下スクロールしつつ表示されるという構造であります。 この2系統の性質が大きく異なる媒体で同一の文書ファイルを利用するため、 Texinfo文字書体や大きさを直接記述するよりは、 章節の構造や語句の性格を記述する言語として発達しました。

[234] この Texinfo装置非依存記述的マーク付け的性質こそ、 様々な異なるプラットフォームで利用され特定の書体や文字サイズへの対応を強制し得ない HTML の開発者達が求めていたものでした。しかもマニュアル等の技術文書の表現は初期の HTML の主要な応用分野であり、そのものまさに GNU Texinfo から HTML への変換ソフトウェアも開発されていましたから、 技術文書の記述に実績のある GNU Texinfo語彙HTML にとって魅力的なものだったのです。

[202] DanC が参照した Texinfo のドキュメントからの引用がありますが >>158、 改めて当時のドキュメントを確認してみます。 DanC が参照したものがどのように入手したどのドキュメントだったのかまでは不明ですが、 当時の GNU Texinfo のドキュメントは GNU Emacs に同梱されて配布されていて、現在も近い時期のものが残っています。

[204] >>203 のファイルの中身のファイルの日付は、 ChangeLogとなっています。他はそれより古いファイルです。

[205] man/texinfo.texi という日付がのファイルがあります。 Texinfo 1.1 と題されており、

This file documents Texinfo, a documentation system that uses a single
source file to produce both on-line help and a printed manual.  

This is edition 1.1 of the Texinfo documentation, and is for the Texinfo
that is distributed as part of Version 18 of GNU Emacs.

Copyright (C) 1988 Free Software Foundation, Inc.
@center The GNU Documentation Format
@sp 2
@center by Richard M. Stallman and Robert J. Chassell
@sp 2
@center Edition 1.1
@sp 2
@center May 1988

と冒頭にあります。

[206] その内容を見ると、 DanC の引用とよく似た箇所があります。 引用した部分以外にも多くの説明があります。分量が多いですが、 重要なので引いておきます。

[207] いわゆる論理要素に相当するもの:

@section Specifying Definitions, Files, Commands etc.
@cindex Highlighting
@cindex Specifying commands, files and the like
@cindex Definitions, specifying them within text
@cindex Commands, specifying them within text
@cindex Files, specifying them within text

Texinfo has a variety of commands for specifying just what kind of object a
piece of text refers to.  Metasyntactic variables, for example, are marked
by one @@-command and code by another.  Texinfo uses this information to
determine how to highlight the text.  Since the pieces of text are labelled
by commands that tell what kind of object they are, it is easy to change
the way Texinfo formats and typesets such text.  For example, code is
usually illustrated in a typewriter font, but it would be easy to change
the way Texinfo highlights code to use another font.  This change would not
effect how metasyntatic variables are highlighted.  If straight typesetting
commands were used in the body of the file, you would have to check every
single occurrence to make sure that you were changing code and not
something else that should not be changed.

In addition, the commands can be used to generate useful information from
the file, such as lists of functions or file names.  It is possible, for
example, to write code in Emacs Lisp (or a keyboard macro) to insert an
index entry after every paragraph that contains the text labelled by a
specified command.  You could do this to construct an index of functions if
you had not already made the entries.

The commands serve a variety of purposes:

@table @code
@item @@code
Indicates text that is a literal example of a piece of a program.@refill

@item @@samp
Indicates text that is a literal example of a sequence of characters.@refill

@item @@file
Indicates the name of a file.@refill

@item @@kbd
Indicates the names of keys on the keyboard or characters you type.@refill

@item @@key
Used for the conventional name for a key on a keyboard.@refill

@item @@ctrl
Indicates an ASCII control character.

@item @@var
Indicates a metasyntactic variable.

@item @@dfn
Indicates the introductory or defining use of a term.

@item @@cite
Indicates the name of a book.
@end table



@menu
* Code::	A literal example of a piece of a program.
* Samp::	A literal example of a sequence of characters.
* File::	The name of a file.
* Kbd::		The names of keys or else characters you type.
* Key::		The conventional name for a key on a keyboard.
* Ctrl::	Indicates the ASCII control character.
* Var::		A variable.
* Dfn::		The introductory or defining use of a term.
* Cite::	The name of a book.
@end menu

@node     Code, Samp, , Specifying
@comment  node-name,  next,  previous,  up
@subsection @@code
@findex code

@code{@@code} is used to indicate text that is a piece of a program which
consists of entire syntactic tokens.  The text follows, enclosed in braces.

For example, @code{@@code} is used for an expression in a program, the name
of a variable or function used in a program, or a keyword.  @code{@@code}
is not used for a piece of a token, such as when speaking about the
characters used in a token; for example, when you are explaining what
letters or printable symbols can be used in the names of functions.  It is
also not used for input to programs unless the input is written in a
language that is like a programming language.  For example, it is not used
for the single character commands of GNU Emacs although it is used for the
names of Emacs Lisp functions that the keyboard commands invoke.

You should also @code{@@code} for command names in command languages that
resemble programming languages, such as Texinfo or the shell.  Note,
however, that @code{@@code} is not used for options such as @samp{-c} when
such options stand alone.  There is some argument as to whether an entire
shell command incorporating an option should be written using @code{@@code}
or @code{@@samp}.@refill

It is an error to alter the case of a word inside an @code{@@code}
command.  This is a particularly insidious error if the language being
documented is case sensitive.  If the command is @code{printf}, then
@code{Printf} is a misspelling.  If you do not like having such a command
with lower case at the beginning of a sentence, you may wish to rearrange
the sentence.

In the printed manual, @code{@@code} puts the argument in bold face.
In the Info file, it uses `@dots{}' quotation.  For example:

@example
To compare two files, showing text inserted or removed, use @@code@{diff@}.
@end example

@noindent
produces

@quotation
To compare two files, showing text inserted or removed, use @code{diff}.
@end quotation

@iftex
In the Info file, it looks like this:

@example
@dots{}, use `diff'
@end example
@end iftex

@node     Samp, File, Code, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@samp
@findex samp

@code{@@samp} is used to indicate text that is a literal example of a
sequence of characters in a file, string, pattern, etc.  The text follows,
enclosed in braces.  The argument appears within `@dots{}' quotation in
both the Info file and the printed manual; in addition, it is printed in a
fixed-width font.

@example
To match @@samp@{foo@} at the end of the line, use the regexp @@samp@{foo$@}.
@end example

@noindent
produces

@quotation
To match @samp{foo} at the end of the line, use the regexp @samp{foo$}.
@end quotation

Any time you are referring to single characters, you should use @code{@@samp}
unless @code{@@kbd} is more appropriate.  Basically, @code{@@samp} is a
catchall for whatever is not covered by @code{@@code}, @code{@@file},
@code{@@kbd}.

Punctuation marks that are part of the English text that surrounds the
strings you are specifying are @emph{never} included within the braces.  In
the following sentence, for example, the commas and period are outside of
the braces:

@example
A symbol name ends in @@samp@{a@}, @@samp@{b@}, or @@samp@{c@}.
@end example

@node     File, Kbd, Samp, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@file
@findex file

@code{@@file} is used to indicate text that is the name of a file or
directory.  Currently, it is equivalent to @code{@@samp} in its effects on
the output.  For example,@refill

@example
The @@file@{.el@} files are in 
the @@file@{/gnu/emacs/lisp@} directory.
@end example

@noindent
produces

@quotation
The @file{.el} files are in 
the @file{/gnu/emacs/lisp} directory.
@end quotation

@node     Kbd, Key, File, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@kbd
@findex kbd

@code{@@kbd} is used much like @code{@@code}.  The difference is that
@code{@@kbd} is for names of keys on the keyboard, or of characters you can
type.  For example, to refer to the command @kbd{M-a}, you would use

@example
@@kbd@{M-a@}
@end example

@noindent
and to refer to @kbd{M-x shell}, you would use

@example
@@kbd@{M-x shell@}
@end example

The @code{@@kbd} command has the same effect as @code{@@code} in Info,
but may produce a different font in a printed manual.@refill

You can embed another @@-command inside the braces of a @code{@@kbd}
command.  This is the way to describe a command that would be described
more verbosely as ``press an @samp{r} and then press the @key{RET} key'':

@example
@@kbd@{r @@key@{RET@}@}  
@end example

@noindent
This produces: @kbd{r @key{RET}}

You also use the @code{@@kbd} command if you are spelling out the letters
you type; for example:

@example
To give the @@code@{logout@} command, 
type the characters @@kbd@{l o g o u t @@key@{RET@}@}.
@end example

@noindent
This produces

@quotation
To give the @code{logout} command, 
type the characters @kbd{l o g o u t @key{RET}}.
@end quotation

@node     Key, Ctrl, Kbd, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@key
@findex key

@code{@@key} is used for the conventional name for a key on a keyboard, as
in

@example
@@key@{RET@}
@end example

Often, @code{@@key} is used within the argument of a @code{@@kbd}
command, whenever the sequence of characters to be typed includes one or
more keys that are described by name.@refill

For example, to produce @kbd{C-x @key{ESC}} you would use 

@example
@@kbd@{C-x @@key@{ESC@}@}
@end example


The recommended names to use for keys are in upper case and are

@table @t
@item SPC
Space.
@item RET
Return.
@item LFD
Linefeed.
@item TAB
Tab.
@item BS
Backspace.
@item ESC
Escape.
@item DEL
Delete.
@item SFT
Shift.
@item CTL
Control.
@item META
Meta.
@end table

There are subtleties to handling words like `meta' or `ctrl' which are
names of shift keys.  When mentioning a character in which the shift key is
used, such as @kbd{Meta-a}, use the @code{@@kbd} command alone without the
@code{@@key} command, but when you are referring to shift key in isolation,
use the @code{@@key} command.  For example, you would use
@samp{@@kbd@{Meta-a@}} to produce @kbd{Meta-a} and @samp{@@key@{META@}} to
produce @key{META}.

@node     Ctrl, Var, Key, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@ctrl
@findex ctrl

@code{@@ctrl} is used to describe an ASCII control character.  The pattern
of usage is @code{@@ctrl@{@var{ch}@}}, where @var{ch} is an ASCII character
whose control-equivalent is wanted.  Thus, you put in an @samp{f} when
you want to indicate a @samp{control-f}

Thus, to specify @samp{control-f}, you would enter

@example
@@ctrl@{f@}
@end example

@noindent
which produces

@quotation
@ctrl{f}
@end quotation

In the Info file, this generates the specified control character, output
literally into the file.  This is done so a user can copy the specified
control character (along with whatever else he or she wants) into another
Emacs buffer and use it.  Since the `control-h',`control-i', and
`control-j' characters are formatting characters, they should not be
indicated this way.@refill

In a printed manual, this generates text to describe or identify that
control character: an uparrow followed by the character @var{ch}.

@node     Var, Dfn, Ctrl, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@var
@findex var

@code{@@var} is used to indicate metasyntactic variables.  A metasyntactic
variable is something that stands for another piece of text.  You would use
a metasyntactic variable in the documentation of a function to describe the
arguments that are passed to that function.

@code{@@var} is not used for names of particular variables in programming
languages.  For example, the Texinfo variable @code{texinfo-tex-command} is
not a metasyntactic variable.

Its effect in the Info file is to upcase the argument; in the printed
manual, to italicize it.  Example:

@example
To delete file @@var@{filename@}, type @@code@{rm @@var@{filename@}@}.
@end example

@noindent
produces

@quotation
To delete file @var{filename}, type @code{rm @var{filename}}.
@end quotation

In some documentation styles, metasyntactic variables are shown with angle
brackets, for example: 

@example
@dots{}, type rm <filename>
@end example

@node     Dfn, Cite, Var, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@dfn
@findex dfn

@code{@@dfn} is used to identify the introductory or defining use of a
technical term.  The command should be used only in a passage 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 doesn't deserve
@code{@@dfn}.  It generates italics in the printed manual, and double
quotation marks in the Info file.  Example:

@example
Getting rid of a file is called @@dfn@{deleting@} it.
@end example

@noindent
produces

@quotation
Getting rid of a file is called @dfn{deleting} it.
@end quotation

@node     Cite, , Dfn, Specifying
@comment  node-name,  next,  previous,  up
@subsection @@cite
@findex cite

@code{@@cite} is used for the name of a book.  It produces italics
in the printed manual, and quotation marks in the Info file.

[208] 強調物理要素に相当するもの:

@node     Emphasis, , Dots Bullets Tex, Marking Text
@comment  node-name,  next,  previous,  up
@section Emphasizing Text
@cindex  Emphasizing text

Usually, Texinfo changes the font automatically to mark words in the text
according to what category the words belong to.  The @code{@@code} command,
for example, does this.  Most often, this is the best way to mark specified
words.  However, sometimes you will want to emphasize text directly.
Texinfo has two ways to do this: commands that tell Texinfo to emphasize
the text but leave the method to the program, and commands that specify the
font to use.  The first method is generally the best and it makes it
possible to change the style of a document without have to re-edit it line
by line.

@menu
* Emph and Strong::	Emphasizing text.
* Fonts::		Selecting italic, bold or typewriter fonts.
@end menu

@node     Emph and Strong, Fonts, , Emphasis
@comment  node-name,  next,  previous,  up
@subsection @@emph and @@strong
@findex emph
@findex strong

@code{@@emph} and @code{@@strong} are two forms of emphasis.  @code{@@strong}
is stronger.

In printed output, @code{@@emph} produces @emph{italics} and @code{@@strong}
produces @strong{bold}.

In the Info file, both of these commands put asterisks around the
argument.

@node     Fonts, , Emph and Strong, Emphasis
@comment  node-name,  next,  previous,  up
@subsection @@i,  @@b and @@t
@findex i (italic font)
@findex b (bold font)
@findex t (typewriter font)

These three commands specify font changes in the printed manual and have no
effect in the Info file.  @code{@@i} requests @i{italic} font (in some
versions of @TeX{}, a slanted font is used), @code{@@b} requests @b{bold}
face, and @code{@@t} requests the @t{fixed-width} font used by
@code{@@kbd}.  All three commands apply to an argument that follows,
surrounded by braces.@refill

If possible, you should avoid using these three commands.  If you find a
need to use one, it probably indicates a lack in the Texinfo language.

[237] GNU Texinfo はこの時点で既に何年にもわたって多くのソフトウェアドキュメントの記述、 そしてソフトウェアに付属させての配布や印刷物としての出版の実績を積み重ねていて、 そのために必要な語彙がある程度整備されており、 しかもそれぞれの用法について詳しく説明されています。

[238] その利用実績が、明言はされていないとはいえ、 HTML が完全に独自に要素を作るのではなく既存の言語からひとまとめに要素群を借用する方針を採った理由の1つではあるのでしょう。

[209] この詳細な説明が全文 HTML の要素一覧にも引かれていれば、 その後の展開もまた違ったものになっていたでしょうね。

[239] そのためにせっかく先行する GNU Texinfo で積み重ねられてきた要素の運用実績が、 HTML には十分引き継がれず、要素の意味が曖昧になってしまいました。

[240] GNU Texinfo のマニュアルの記述を要約すると:

[354] この語彙と説明の全体を眺めた感想:

  • [355] ソフトウェアマニュアルの頻出の表現を、執筆者に過度な負担を求めない程度に、 しかし当時の表示環境を勘案しつつも美しく印刷できるように、 うまい塩梅の粒度だと思いました。
    • [373] 例えばもっと細かく、 関数名、 引数名、 プログラム中の変数名、 環境変数名、 といくらでも際限なく語彙を増やしていくことは可能で、 その方が関数一覧が生成できたりと便利なことはあるのですが、 便利さと引き換えにマニュアル執筆の負担も増していきます。
    • [377] 実のところ Texinfo のこれより新しい版には @command, @option, @env が追加されています。
  • [356] @code@samp は明らかに対照的、相補的に定められています。 誤解を恐れず一言でまとめてしまうなら、 プログラミング言語的なものの字句(群)としてそのまま意味を成すものが @code、 それ以外のすべてが @samp となります。
    • [357] この対応関係が HTML に伝わらなかったのは大きな不幸でした。
    • [358] @samp は名前と意味が合っていない気がします。 (でももっと適当な名は思いつかないですね。) 作られた頃はもっと違った整理だったのかもしれません。 これも不幸でした。
    • [361] @code@samp は表示の違いもありますが、 索引的な処理で意味を持つのが @code、持たないのが @samp という整理もできそうです。
      • [367] 索引を自動生成したときに出てきて嬉しいか、嬉しくないか、というのはきっといい判断基準のはず。
  • [359] @kbd はただ単に打鍵されるべき鍵・文字列を示すというよりは、 打鍵列を表す表記構文という1つのプログラミング言語的なもの用に特化した @code というべきかもしれません。
    • [360] ソフトウェアマニュアルならではの専用語彙といえます。
  • [362] @ctrlSGML 的には文字参照で表すのが正統的な方法で、 HTML が採らなかったのは自然な流れといえますが、 ソフトウェアマニュアルとしてこの機能が必要だった (特にこの時代には。) のは頷けます。
  • [363] @file はソフトウェアマニュアルとして必要なことは確かですが、 なるほど HTML に持ち込むには具体的すぎると感じるのもわかります。
    • [364] ただ @code とはちょっと違っているので、「その他全部」の @samp にするしかなくなります。
      • [365] 設定ファイルの名前やアプリケーションのディレクトリー名など、 @file は二次利用が難しい「その他全部」枠よりは @code 枠に近い使われ方が多そうです。 (「索引」基準なら @code に入れたいですね。)
      • [366] でも @code には収容できないとなると、 ファイル名の他に URLISBN のようなものも含めた「識別子」 カテゴリーを新設するという手もあったかもしれませんね。 もう少し広げて正規表現XPath のようなものも含んだ「式言語」 枠もありかもしれません。
  • [368] @emph, @strong が推奨されない直接的な記述に分類されています。 これはちょっと意外ですね。
  • [371] @emph より @strong が強いという関係が明記されています。
  • [374] 下線を使う命令がなければ、表示にも使われていないことに気が付きます。
    • [375] ここに示していない Texinfo命令下線を使うものはありますが (見出しなど)、 次の行に =, - などを使って表現するとされています。 つまるところ、この時代には下線を表示するのが難しかった (少なくても可搬ではなかった) ので有効な表現方法と考えられなかったということなのでしょう。
    • [376] 太字italic / slantInfo ファイルの画面表示には使っていないくらいなので、 下線が画面表示できないとしても印刷用だけは下線、 という命令は用意できたはずですが、それすらもないのは、 敢えて使うような表現方法とみなされていなかったのでしょうか。
[553] HTML要素概説
要素名
emph
要素名
strong
要素名
b
要素名
i
要素名
code
要素名
samp
要素名
kbd
要素名
key
要素名
var
要素名
dfn
要素名
cite
要素名
file
日付
説明
時点で GNU Texinfo@code, @samp, @kbd, @key, @file, @dfn, @var, @cite, @emph, @strong, @b, @i がある。
出典

LaTeX からの借用

[181] emtt は、その要素名LaTeX から借用したと考えられます (>>148 >>179)。

[185] >>184 付の latex209.tar.gz があります。 中身のファイルの日付は, , のいずれかの正時に揃っています。 どうにも不自然ですが、に過去のファイルを集めて作成したtar玉なのでしょう。

[186] DanC が参照したものが何だったのか、 LaTeX という以外に情報がありませんが、 この tar玉の中身とそう遠くはないものだろうと期待されます。

[187] general/latex.tex というのファイル LATEX VERSION 2.09 <25 March 1992> には、

%     ****************************************
%     *           COMMAND LIST               *
%     ****************************************

%  IN DOCUMENT :
%    FONT SELECTION:
%         SIZE: \normalsize \small \footnotesize \scriptsize \tiny
%               \large \Large \LARGE \huge \Huge
%         STYLE: \bf \it \rm \sl \ss \tt \mit[math mode only]

とあります。

[188] general/sfonts.tex というのファイル File SFONTS - Version of 25 November 1991 には、

% protected font names
\def\rm{\protect\prm}
\def\it{\protect\pit}
\def\bf{\protect\pbf}
\def\tt{\protect\ptt}
\def\sl{\@subfam\sl\it}
\def\sf{\@subfam\sf\rm}
\def\sc{\protect\psc}
 
\def\em{\protect\pem{}}
\def\pem{\relax\ifdim \fontdimen\@ne\font >\z@ \rm \else \it \fi}

とあります。

[189] general/lfonts.tex というのファイル File LFONTS - Version of 25 November 1991 には、

% \em is defined to be \it inside an unslanted style and \rm inside a
% slanted style.  An \em command in a section title will produce a \pem
% command in the table of contents.
%

\def\em{\protect\pem{}}
\def\pem{\relax\ifdim \fontdimen\@ne\font >\z@ \rm \else \it \fi}
% protected font names
\def\rm{\protect\prm}
\def\it{\protect\pit}
\def\bf{\protect\pbf}
\def\sl{\protect\psl}
\def\sf{\protect\psf}
\def\sc{\protect\psc}
\def\tt{\protect\ptt}

とあります。

[190] general/local.tex というのファイル local.tex -- released 26 February 1992 には、

Table~\ref{tab:fonts}
tells, for every type size, to which class of fonts each type style
belongs.  For example, in 14pt type, \verb|\bf| uses a preloaded
font and the other five type-style commands use load-on-demand fonts.
Roman (\verb|\rm|) and math italic (\verb|\mit|) fonts are all
preloaded; the \hbox{\verb|\em|} declaration uses either italic
(\verb|\it|) or roman.

とあってフォントとサイズの表があります。

[191] 以上、 DanC の引用 (>>138) と若干違うのが気になりますが、 \tt を含む7種類のフォントスタイルがあり、 \em\it または \rm のどちらかとして実装されていることがわかります。

[192] local.tex には \tt\em が大量に使われているので、 いくつか用法を見ておきましょう。

[193] \em で書名を強調

computers at SRC. It is not about \LaTeX\ itself, which is described by
the manual---{\em \LaTeX: A Document Preparation System}, published by
Addison-Wesley, available at fine book stores everywhere.

[194] \em で入力する文字列を強調、 \tt でファイル名

(You must type the space followed by the period at the end.  This
and all other Ultrix commands are ended by typing {\em return}.)
A copy of the file \mbox{\tt sample.tex} is now in your current
directory; you can edit it just like any other file.  If you destroy or

[195] \em で文書名を強調

You must use a text editor to prepare an input file for \LaTeX. The
document {\em Welcome to SRC\/} describes the text editors available
at SRC.  The easiest way to start learning about \LaTeX\ is by 

[196] \em打鍵列を強調

because it is printing a seemingly unending string of uninformative
error messages, type {\em Control-C\/} (press $C$ while holding down
the key labeled {\em CTRL\/}).  This will make \LaTeX\ stop as if it

[197] \em で文中の語を強調、 \ttLaTeX の機能名

Except for these differences, a \SLiTeX\ input file prepared for the
ordinary {\tt slides} style {\em should\/} work with the {\tt
ps-slides} style.  There are probably some \SLiTeX\ commands that will

[198] \em で可変部分を強調、 \tt で実行するコマンド

\begin{quote} \tt
     aptex -Pcolor {\em file-name}.dvi
\end{quote}

[199] 他にも用例が多数あります。 \tt はおおむね現在の HTMLcode の役割で使われています。 \em はいろいろな意味で強調、 周りとの区別を表すために使われていて、現在の HTML でいえば em, strong, var, kbd など幅広く応用されています。

[200] これを現在視点から見ると code があるのに tt は要らなそうにも感じますが、 当時の code の意味と比べると、 \tt がないと困りそうです。 @file が省かれて \tt が採用された理由もこの辺りにあるのかもしれません。

[235] これらに出現するものを DanC の言及と比較すると、

LaTeX>>187bfitrmslsstt
LaTeX>>188rmitbfttslsfscem
LaTeX>>189emrmitbfslsfsctt
DanC>>134emitbfsfsltt
DanC>>148emttbdslsf
HTMLemtt

と実にバラバラで、 DanC が参照したのはここで引いたどれでもなかったのかもしれませんが、 それにしても >>134>>148 で違うのは一体どういう理由によるものなのでしょう。

[236] >>134>>148 の違いは誤記、誤写、もしかすると手書きを経由している可能性すらあるのではとも思わせられますね。

[554] HTML要素概説
要素名
em
要素名
tt
日付
説明
LaTeX 2.09 に \em, \tt がある。
出典

初期要素のその後

[470] Texinfo の詳しい説明が引き継がれず HTML では短い簡潔な説明になりましたが、 それでは使い方がわからないということで、後続の仕様で少しずつ言い方が改められています。 しかしそれでも不明瞭な部分が多く、著者は解釈に悩まされ、色々な使い方をしてきました。

[471] HTML5 はその反省から、あるものは利用の実態に合わせて、 あるものは新たに利用目的を再設定することにより、 詳細な要素の意味の説明を0から決め直しました。

[472] それによって意味は明確になり、利用しやすくはなりましたが、 GNU Texinfo の原義とは離れたものもあります。 また、 GNU Texinfo 側でも新機能の追加などで意味の変化が置きています。

[445] Texinfo は必ずしも違った表示にしていませんでしたが、 HTML 2.0 は地の文と違った表示にすることを求めています:

User agents must render highlighted phrases distinctly from plain

text. Additionally, <EM> content must be rendered as distinct from

<STRONG> content, and <B> content must rendered as distinct from <I>

content.

[446] HTML 2.0 も指定されたままの表示を必須とまではしていません。例えば italic を表示できない環境で iitalic 表示せよと無理強いはしていません。 しかし地の文や b と違う表示は求めています。

code のその後

[386] Texinfo:

Indicates text that is a literal example of a piece of a program.

[401] >>225

CODEExample of code

[378] HTML 1.0:

CODE
Example of code. typically monospaced font. (Do not confuse with PRE )
code
符号の例。典型的に単一幅フォント。 (pre と混同しないように。)

[379] RFC 1866 (HTML 2.0):

5.7.1.2. Code: CODE

The <CODE> element indicates an example of code, typically rendered in a mono-spaced font. The <CODE> element is intended for short words or phrases of code; the <PRE> block structuring element (5.5.2, "Preformatted Text: PRE") is more appropriate for multiple-line listings. For example:

code 要素は符号の例を示し、 典型的に単一幅のフォントでレンダリングします。 code 要素は符号の短い語や語句を想定しています。 複数行の並びには pre ブロック構造化要素がより適切です。例:

The expression <code>x += 1</code> is short for <code>x = x + 1</code>.

式 <code>x += 1</code> は <code>x = x + 1</code> の略です。

[380] HTML2 (RFC 1866, RFC 2070) DTD 注釈:

<CODE> Source code phrase

code 原始符号語句

[381] HTML+ 議論文書 http://www.w3.org/MarkUp/HTMLPlus/htmlplus_18.html:

code
code example - usually shown in fixed pitch font
code
符号例 — 通常固定幅フォントで

[382] HTML 3.0 I-D http://www.w3.org/MarkUp/html3/logical.html:

The <CODE> element indicates an example of code; typically rendered in a mono-spaced font. Do not confuse with PRE.

code 要素は符号の例を示します。 典型的に単一幅フォントでレンダリングされます。 pre と混同しないように。

[496] HTML 3.2

CODE used for extracts from program code

[383] HTML 4 仕様書 IW:HTML4:"struct/text.html#edef-CODE" いわく:

Phrase elements add structural information to text fragments. The usual meanings of phrase elements are following:

(略)

CODE
Designates a fragment of computer code.

語句要素は文素片に構造的情報を追加します。 語句要素の通常の意味は次の通りです。 (略)

code
計算機符号の素片を示す。

[384] ISO-HTML利用者の指針 http://purl.org/NET/ISO+IEC.15445/Users-Guide.html#UNREFINED:

<CODE> [W3C 9.2.1]—Program code

code プログラム符号

[385] XHTML 1.0 DTD 注釈 http://www.w3.org/TR/2002/REC-xhtml1-20020801/dtds.html#dtdentry_xhtml1-strict.dtd_code:

program code

プログラム符号

[464] HTML5

Computer code

The code element represents a fragment of computer code. This could be an XML element name, a filename, a computer program, or any other string that a computer would recognize.

[473] 「符号」という中心義を維持しながらも、そのあり方はかなりの変化を見ています。

  • [474] 「例示」だったものがいつの間にかなくなっています。
    • [475] この「例示」は Texinfo の時点で既にあまり実態をよく反映していなかったように思われます。 「命令のドキュメントでその命令の名前を実際に書いた箇所」というようなニュアンスの、 プログラム中ではなくドキュメントの説明文中に示した、というくらいの意味の「例示」 であって、例文を書くため、という限定的な意味では元々なかったのではないかと、 GNU Texinfo の説明や実利用事例を見ると思われます。だとすると「例示」 という表現はあまりわかりやすくなかったので、この表現がなくなったのは良い変化といえます。
  • [476] どんな符号かの説明がコロコロと変わっています。
    • [477] 現在の HTML5 定義では計算機符号の素片なら割と何でも当てはまることになっています。 Texinfo では専用の命令があったファイル名にも使えると明記されていますし、 仕様書自体では URL などにも実用されています。
    • [478] Texinfo では字句未満のものは @samp、定数的な文字列はどちらか迷う感じですが、 HTML5 ではそれらも code で記述できます。
    • [479] 初期の HTML 仕様が明確な説明をしなかったために、計算機っぽい符号っぽいものはすべてが code に収容されるようになった感があります。 HTML5 はその実態を追認したものといえます。
      • [480] 割を食らったのが samp です。
  • [481] 複数行のプログラム片にも code が使われるようになりました。
    • [482] 元の Texinfo では @code は高々数字句程度の語句の記述に使うもので、 初期 HTML でも pre との使い分けを指摘していました。 codepre も固定幅フォントで表示されるので、 行内要素ブロック要素で素朴に使い分けられていました。
      • [483] ところが preなどにも利用され、意味よりも表示方法に寄った (HTML にそぐわない) 要素だと認識され、 XHTML2blockcode を導入したりしていました。
      • [484] HTML5 に至って precode の組み合わせが慣用句として新たに規定されました。

samp のその後

[387] Texinfo

Indicates text that is a literal example of a sequence of characters.

[402] >>225

SAMPA sequence of litteral characters

[425] HTML 1.0

A sequence of literal characters.

[435] HTML 2.0

The <SAMP> element indicates a sequence of literal characters,

typically rendered in a mono-spaced font. For example:

<!-- <SAMP> Sample text or characters -->

[436] HTML 1.0 の頃は Texinfo 順でしたが、 HTML 2.0 ではアルファベット順になっていて、完全に codesamp のつながりが絶たれてしまいました。

[494] HTML 3.2

SAMP used for sample output from programs, and scripts etc.

[495] HTML 3.2 で旧来の順序が復活。 HTML4 もそれを踏襲しました。

[448] HTML4

Designates sample output from programs, scripts, etc.

[465] HTML5

Computer output

The samp element represents sample or quoted output from another program or computing system.

[497] samp は最も迷走した要素といえます。現在もその用途が不明瞭で不遇な扱いです。

  • [498] Texinfo では @code@samp が対で相補的に説明されていましたが、 HTML ではその関係性が引き継がれませんでした。 (先述)
    • [499] かろうじて前後に並んで説明されていましたが、HTML の版によってはそれすら維持されませんでした。
  • [500] そもそもの Texinfo@samp という命令の名前が説明と合っていない感があります。 (先述)
  • [501] @code と同じく (>>475)、 ドキュメントの文章中で実際の入出力文字列片の一部を提示したものという程度の意味だったと思われます。
  • [502] HTML の説明文には「例示」という表現が消えたり復活したりしています。 前の版の説明文ではなく要素名から説明が導かれている感があります。
  • [506] 初期 HTML の説明は、 Texinfo の説明を省略しすぎて、文字列、 としか説明していなくて意味不明です。
  • [503] HTML 3.2 で「プログラム」の「出力」「例」と意味がかなり限定的になって、 以後それが引き継がれています。
  • [504] 著者はそれを理解できずにわけもわからず使うか、使い所のない要素という扱いになっています。
    • [507] GUI が基本になった今でもプログラムとしか説明がないのも、 ちょっと困ったポイント。なぜプログラムの出力に専用の要素が必要なのか意味が不明気味です。
  • [505] HTML5 もそれを処理し切れず、 HTML4 の説明をより明瞭に改めるに留まっています。

[508] 元々 Texinfo 的には、英文中にコマンドライン引数とか、 プログラムの出力テキスト例とか、 正規表現とか、 利用可能な文字のリストとか、 なにかの識別子とか、 地の文とは区別したくて、固定長フォントがしっくり来る、 ときには引用符で括っておきたいのだけれども、 プログラム関数名変数名やその他字句の並びとは性質が違っていて @code は相応しくない、そんな諸々のものを @samp で表すとしていたようです。

[509] これを説明なしで理解しろといわれても無理な話ですし、歴代 HTML 仕様に関わっていた人達も HTML のマニュアルを書いた人々も、 Texinfo に戻って確認することなく雰囲気だけで説明を書いていたのでしょうね。

kbd のその後

[388] Texinfo

Indicates the names of keys on the keyboard or characters you type.

[403] >>225

KBDin an instruction manual, Text typed by a user.

[426] HTML 1.0

in an instruction manual, Text typed by a

user.

[434] HTML 2.0

The <KBD> element indicates text typed by a user, typically

rendered in a mono-spaced font. This is commonly used in

instruction manuals. For example:

<!-- <KBD> Keyboard phrase, e.g. user input -->

[493] HTML 3.2

KBD used for text to be typed by the user

[449] HTML4

Indicates text to be entered by the user.

[466] HTML5

User input

The kbd element represents user input (typically keyboard input, although it may also be used to represent other input, such as voice commands).

[510] Texinfo では GNU 形式の打鍵列を表す慣習的な表記のために使われていましたが、 HTML ではその構文的な部分は引き継がず、説明も少しずつ雑になって 「利用者が入力する文字列」 というだけになっています。 HTML5 に至って鍵盤に限定されず音声入力などでもいいと拡大されています。

[511] 文字でなくも指定できることがわからなくなっていますが、 HTML5kbd入れ子で記述できることと定めました。 要素名こそ違うものの、 key が復活したことになります。

[514] HTML4 には特に記述がないものの、実態として kbd が鍵の名前のために使われることはあったので、 HTML5 で用法が整理されたものです。入れ子で区別するという手法はおそらく HTML5 の創案です。

key のその後

[389] Texinfo

Used for the conventional name for a key on a keyboard.

[404] >>225 : DTD にあるが本文になし

[430] HTML 1.0 : DTD にあるが本文になし

[447] HTML 2.0 になし

[512] 本文から欠落して忘れ去られてしまったのか、不要だと判断されて削られて一時 DTD に残ったままになっていたのかわかりませんが、早々に消え去ってしまいました。

[513] HTML5 である意味復活 (>>511) しました。

var のその後

[390] Texinfo

Indicates a metasyntactic variable.

[405] >>225

VARA variable name

[427] HTML 1.0

A variable name.

[438] HTML 2.0

The <VAR> element indicates a placeholder variable, typically

rendered as italic. For example:

<!-- <VAR> Variable phrase or substitutable -->

[492] HTML 3.2

VAR used for variables or arguments to commands

[453] HTML4

Indicates an instance of a variable or program argument.

[469] HTML5

Variables

The var element represents a variable. This could be an actual variable in a mathematical expression or programming context, an identifier representing a constant, a symbol identifying a physical quantity, a function parameter, or just be a term used as a placeholder in prose.

[515] Texinfo ではメタ構文変数であってプログラム変数ではないと明言されていましたが、 初期 HTML 仕様は変数名としか説明していませんでした。

[516] そのため HTML では変数全般に拡大して利用されている実態がありました。 HTML5 はそれを追認してメタ構文変数の他に数式プログラム変数にも使えると明確化しました。

dfn のその後

[391] Texinfo

Indicates the introductory or defining use of a term.

[406] >>225

DFNThe defining instance of a term

[428] HTML 1.0

The defining instance of a term. Typically

bold or bold italic.

[393] Highlighting in HTML http://www.w3.org/MarkUp/1995-archive/Highlighting.html#DFN.index

The defining instance of a term. Typically bold or bold italic.

用語の定義的実現値。典型的には太字または太字斜体 (イタリック)。

[431] HTML 2.0 では本文注釈にあるのみで、 DTD にはなし。

[394] Hypertext Markup Language - 2.0 - Footnotes http://www.w3.org/MarkUp/html-spec/html-spec_foot.html#FOOT20

It is used to indicate the defining instance of a term, and it is typically rendered in italic or bold italic.

[395] HTML+ Logical Emphasis http://www.w3.org/MarkUp/HTMLPlus/htmlplus_18.html

defining instance of a term

[396] HTML3.0 原案 Information Type Elements http://www.w3.org/MarkUp/html3/logical.html

The <DFN> element indicates the defining instance of a term.

[397] HTML 3.2 Reference Specification http://www.w3.org/TR/REC-html32#phrase

defining instance of the enclosed term

囲まれた用語の定義的実現値

[398] W3C Journal - What's New in HTML 3.2 http://www.w3journal.com/5/s3.musciano.html#HEADING1-131

抜粋すると:

This tag defines the enclosed text to be the defining instance of a word or phrase. Browsers may choose to place such a term in italics or some other distinctive text. In additional, it might be useful for the browser to collect such terms and create a dynamic glossary, with hyperlinks, of all the terms defined in a document.

このタグは、囲まれた文を語または語句の定義的実現値として定義します。 ブラウザはその用語を斜体 (イタリック) その他の差別化した文にすることを選ぶかもしれません。 加えて、ブラウザがその用語を集めて、文書中で定義されたすべての用語のハイパーリンク付き動的用語集を作るのに有用かもしれません。

[399] HTML4 IW:HTML4:"struct/text.html#edef-DFN":

Indicates that this is the defining instance of the encoded term.

これが囲まれた用語の定義的実現値であることを示します。

[400] XHTML2.0 WD - XHTML Inline Text Module http://www.w3.org/TR/2003/WD-xhtml2-20030506/mod-inline-text.html#sec_9.4.

The dfn element contains the defining instance of the enclosed term.

dfn 要素は囲まれた用語の定義的実現値を含めます。

[463] HTML5

Defining instance

The dfn element represents the defining instance of a term. The paragraph, description list group, or section that is the nearest ancestor of the dfn element must also contain the definition(s) for the term given by the dfn element.

[517] 初期には dfn はなぜか他の要素と違って実装から欠落し、仕様書からも削られていました。 その後復活しました。

[518] 意味には大きな変化はありません。

cite のその後

[392] Texinfo

Indicates the name of a book.

[407] >>225

CITEA citation

[429] HTML 1.0

A citation. Typically italic.

[432] HTML 2.0

The <CITE> element is used to indicate the title of a book or

other citation. It is typically rendered as italics. For example:

<!-- <CITE> Name or title of cited work -->

[491] HTML 3.2

CITE used for citations or references to other sources

[450] HTML4

Contains a citation or a reference to other sources.

As <CITE>Harry S. Truman</CITE> said,
<Q lang="en-us">The buck stops here.</Q>

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

[462] HTML5

Titles of works

The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc.). This can be a work that is being quoted or referenced in detail (i.e., a citation), or it can just be a work that is mentioned in passing.

[519] Texinfo は本の名前に限定していましたが、 HTML は初めから citation として本という限定を外しています。 Texinfo の想定が論文などを除外して本だけにする意図があったのかは不明ですし、初期 HTML がその限定を外す意図があったのかというと、正確性を意識しなかった可能性の方が高いようにも思われますが、 ともかくその結末として HTML5 では様々な作品の名称に適用できると種別名を多く列挙して明確化されています。

[520] HTML は初め citation といい、やがて citations or references といい、 HTML4 では a citation or a reference というように、 単なる作品名ではなく引用だと説明しています。要素名に引きずられてのことなのでしょうが、 これによって何が cite 要素で記述されるべきなのかも不明瞭になりました。

[521] HTML4 の例文には、著者名が cite で表されたり、 参考文献リストの参考文献名を文中から参照するときに使う合印の文献名が cite で表されたりしたものがあります。

[522] この例文は人名cite で表せるという誤解を一部で招きました。 HTML5 が詳細に説明しているのはそのような誤解を排除する意図もあってのことでした。

[556] FAQ - WHATWG Wiki, , https://wiki.whatwg.org/index.php?title=FAQ&oldid=9975#The_.3Ccite.3E_element_should_allow_names_of_people_to_be_marked_up

em のその後

[414] Texinfo @emph

emphasis

[408] >>225

EMEmphasis, typically italic.

[423] HTML 1.0

Emphasis, typically italic.

[433] HTML 2.0

User agents must render highlighted phrases distinctly from plain

text. Additionally, <EM> content must be rendered as distinct from

<STRONG> content, and <B> content must rendered as distinct from <I>

content.

The <EM> element indicates an emphasized phrase, typically

rendered as italics. For example:

<!-- <EM> Emphasized phrase -->

[490] HTML 3.2

EM basic emphasis typically rendered in an italic font

[451] HTML4

Indicates emphasis.

Generally, visual user agents present EM text in italics and STRONG text in bold font.

[460] HTML5

Stress emphasis

The em element represents stress emphasis of its contents.

[523] Texinfo は他に該当する表現がないような強調としていましたが、 HTML は引き継がずにただの強調としました。 そのためよく使われる要素となりました。

[524] ソフトウェアの技術マニュアルに用途を限定しない HTML としては悪くない判断ではあるのですが、 他の要素との関連性が失われて「強調」というものの性質の理解が難しくなったようにも思われます。

[525] HTML5strong との区別が求められたために、 文の意味を変えるような性質の強調em だとしました。 これも悪くはない判断ではあるのですが、 厳密に言えば過去の用法との連続性が失われています。

strong のその後

[415] Texinfo

emphasis

stronger

[409] >>225

STRONGStronger emphasis, typically bold.

[424] HTML 1.0

Stronger emphasis, typically bold.

[437] HTML 2.0

User agents must render highlighted phrases distinctly from plain

text. Additionally, <EM> content must be rendered as distinct from

<STRONG> content, and <B> content must rendered as distinct from <I>

content.

The <STRONG> element indicates strong emphasis, typically rendered

in bold. For example:

<!-- <STRONG> Strong emphasis -->

[489] HTML 3.2

STRONG strong emphasis typically rendered in a bold font

[452] HTML4

Indicates stronger emphasis.

Generally, visual user agents present EM text in italics and STRONG text in bold font.

[461] HTML5

Importance

The strong element represents strong importance, seriousness, or urgency for its contents.

[526] Texinfo では @emph よりも強い強調とされていました。 HTML にも引き継がれたものの、次第に比較対象が明言されなくなりました。 そのため「em より strong が強い」という意識は著者の間に残ったものの、 出典不明の怪情報のような扱いになっていきました。

[527] 実態として em斜体strong太字で使われていましたが、 表示の違いだけで別の要素があるのはおかしいと考えられた時代にちょうど作られた HTML5emstrong に別の意味を与える必要があり、 strong を強い重大性、深刻性、緊急性を表すとしました。

[528] 引用は省略しましたが、それらの詳しい説明もあります。
[529] em より strong が強いなら、 em を入れ子にしたら strong になるのか、それとも別なのか、など「より強い」という元の定義にも何かと問題がありました。

tt のその後

[418] Texinfo @t

typewriter font

[410] >>225

TTFixed-width typewriter font

[420] HTML 1.0

Fixed-width typewriter font.

[443] HTML 2.0

The <TT> element indicates teletype (monospaced )text. Where a

teletype font is unavailable, an alternative representation may be

used.

<!-- <TT> Typewriter text -->

[485] HTML 3.2

TT teletype or monospaced text

[454] HTML4

TT: Renders as teletype or monospaced text.

[530] 表現方法は違うものの、固定長フォントを使って表示するものという定義で一致しています。

b のその後

[416] Texinfo

bold font

[411] >>225

BBoldface, where available, otherwise alterntive mapping allowed.

[419] HTML 1.0

Boldface, where available, otherwise

alternative mapping allowed.

[441] HTML 2.0

User agents must render highlighted phrases distinctly from plain

text. Additionally, <EM> content must be rendered as distinct from

<STRONG> content, and <B> content must rendered as distinct from <I>

content.

The <B> element indicates bold text. Where bold typography is

unavailable, an alternative representation may be used.

<!-- <B> Bold text -->

[486] HTML 3.2

B bold text style

[455] HTML4

B: Renders as bold text style.

[468] HTML5

Keywords

The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.

[458] HTML4 まで、表現は違うものの太字で表現されるべきものという定義で一致していました。

[531] 表示条件だけを指定する要素が不適当という考えが強まった時代の HTML5 は、新しい意味で説明し直しました。

[532] strong と使い分けがちょっとむずかしそうなところではありますが....

[540] 表現は変わっていますけど、

  • [541] Texinfo : 太字を表します。 なるべく他の方法を使ってください。 太字にできるときは太字で表示します。
  • [542] HTML4 まで : 太字です。 できれば他の方法を使ってください。 太字で表示したらいいですが強制しません。
  • [543] HTML5 : なんやかんや太字で表記されがちなものを表します。 ただし他に専用の方法が使えるときは使えません。 太字が基本ですが、あくまで原則です。

ということで、「なんか太字っぽい、しらんけど」程度の位置づけってのはずっと変わってないんですよね。 i も同じで。

[544] bi も見かけの定義が随分と変わったので物理要素絶対反対勢からも物理要素別にいいじゃん勢からも反発はありましたけど、 「もっとちゃんと現実を見ましょう」が基本方針の HTML5 が突飛なことなんてやるはずないんですよねえw

i のその後

[417] Texinfo

italic font

[412] >>225

IItalic font (or slanted if italic unavailable).

[421] HTML 1.0

Italic font (or slanted if italic

unavailable).

[442] HTML 2.0

User agents must render highlighted phrases distinctly from plain

text. Additionally, <EM> content must be rendered as distinct from

<STRONG> content, and <B> content must rendered as distinct from <I>

content.

The <I> element indicates italic text. Where italic typography is

unavailable, an alternative representation may be used.

<!-- <I> Italic text -->

[487] HTML 3.2

I italic text style

[456] HTML4

I: Renders as italic text style.

[467] HTML5

Alternative voice

The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.

[533] HTML4 まで、表現は違うものの italic で表現されるべきものという定義で一致していました。

[534] 表示条件だけを指定する要素が不適当という考えが強まった時代の HTML5 は、新しい意味で説明し直しました。

u のその後

[413] >>225

UUnderline??

[422] HTML 1.0

Underline.

[439] HTML 2.0 では本文注釈にのみ

characters, and the <U> element indicates an underline.

とあります。

[488] HTML 3.2

U underlined text style

[457] HTML4

U: Deprecated. Renders underlined text.

[459] HTML5

Annotations

The u element represents a span of text with an unarticulated, though explicitly rendered, non-textual annotation, such as labeling the text as being a proper name in Chinese text (a Chinese proper name mark), or labeling the text as being misspelt.

[535] HTML4 まで、表現は違うものの下線で表現されるべきものという定義で一致していました。

[536] 表示条件だけを指定する要素が不適当という考えが強まった時代の HTML5 は、新しい意味で説明し直しました。

[537] この要素の出自は不明で (先述)、 HTML の初期の初期で「?」が付いていましたが、「?」を削ってそのまま残されました。

[539] しかしそのためもあるのかどうか、 初期の Webブラウザーにはあまり実装されなかったようで、一旦は仕様から外されました。 後に復活しましたが、 HTML4bi と違って非推奨とされたのは、 実装が遅かったこと、それだけ機能としての重要度が低かったことが影響しているのでしょう。

[538] HTML5 でも bi は他の専門の要素で表現しきれない場合のために、 多少強引な意味を新たに付与してまで残されてたものの、当初 u廃止されるところでした。しかしやはり u が必要だという声に推されて復活しました。

[440] HTML 2.0 本文注釈に strike があります。

[52] Netscape Navigator Extensions to HTML http://web.archive.org/web/20000415023954/http://www.netscape.com/home/services_docs/html-extensions.html

HTML 2.0 に対する拡張と称して、 bi入れ子にしても Netscape Navigator がその通りにレンダリングするようになったことを紹介しています。

[53] >>52

<i><tt><font size=6><b>Text here</b></font></tt></i>

[54] A Beginner's Guide to HTML (2003-08-15 22:48:58 +09:00 版) http://ccat.sas.upenn.edu/jod/primer.html#CharFormat

意外なことに

For HTML-coded documents, you should use logical styles whenever possible. Future implementations of HTML may not implement physical styles at all.

なんて書いてあります。

もっとも、それでいて emcode の意味が説明されていないわけですが。

HTML3

[20] HTML要素概説
要素名
i
要素名
b
要素名
u
要素名
s
要素名
sup
要素名
sub
要素名
tt
要素名
em
要素名
strong
要素名
q
要素名
cite
要素名
person
要素名
cmd
要素名
arg
要素名
kbd
要素名
var
要素名
dfn
要素名
code
要素名
samp
日付
説明
HTML+ にある。 HTML+19931028

[22] HTML+acronym, abbrev もありました。

[551] HTML要素概説
要素名
q
要素名
lang
要素名
au
要素名
dfn
要素名
person
要素名
acronym
要素名
abbrev
日付
説明
HTML 3.0 DTD にある。 HTML3-19941130
[216] HTML要素概説
要素名
u
要素名
s
要素名
tt
要素名
b
要素名
i
要素名
big
要素名
small
要素名
em
要素名
strong
要素名
code
要素名
samp
要素名
kbd
要素名
var
要素名
cite
要素名
q
要素名
lang
要素名
au
要素名
dfn
要素名
person
要素名
acronym
要素名
abbrev
日付
説明
HTML 3.0 DTD にある。 HTML3-19950301

[74] HTML 3.0 では ins, del も追加されました。

HTML4

[11] HTML 4要素型級 %inline:

DTD注釈には行内要素 (文水準要素)と書かれています。

仕様書:

[12] また、 DTD の注釈には文字水準要素および文字列とも書かれています。

[61] HTML 4要素型級 %phrase:

仕様書:


[12] Matthew Thomas &#187; Blog Archive &#187; When semantic markup goes bad http://mpt.net.nz/archive/2004/05/02/b-and-i

[13] XSLT 2.0 and XQuery 1.0 Serialization (Second Edition) ( ( 版)) http://www.w3.org/TR/2010/REC-xslt-xquery-serialization-20101214/#HTML_INDENT

[8] op

HTML 以外

[9] HTMLもどきDTBook にも同じような %inline; がありました。

[10] HTML とは違って %inlineinblock; もありました。

[81] HTML要素概説
要素名
b
要素名
i
要素名
u
要素名
em
要素名
strong
要素名
big
要素名
small
借用先
WML1

HTML5

[87] Re: contenteditable, <em> and <strong> (Henri Sivonen <hsivonen@...> 著, 2007-01-09 17:19:43 +09:00 版) http://permalink.gmane.org/gmane.org.w3c.whatwg.discuss/8338

<em>, <strong>, <i> and <b> have all been in HTML for over a decade. I think that’s long enough to see what happens in the wild. I think it is time to give up and admit that there are two pairs of visually- oriented synonyms instead of putting more time, effort, money, blog posts, spec examples and discussion threads into educating people about subtle differences in the hope that important benefits will be realized once people use these elements the “right” way.

(名無しさん 2007-01-12 15:36:16 +00:00)

[89] >>88 i, b, div が同時追加

[14] Web Applications 1.0 r7238 Clean up content model descriptions. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=7237&to=7238

[1] HTML5 Revision Tracker ( 版) http://html5.org/tools/web-apps-tracker?from=5157&to=5158

[2] [whatwg] Various HTML element feedback ( 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-June/036283.html

[62] [whatwg] contenteditable, <em> and <strong> (2007-01-22 21:07:39 +09:00 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html

[63] [whatwg] contenteditable, <em> and <strong> (2007-01-22 21:07:39 +09:00 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html

[64] [whatwg] contenteditable, <em> and <strong> ( 版) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-January/009060.html

[65] Re: Deprecating <small>, <b> ? (Lachlan Hunt <lachlan.hunt@...> 著, 版) http://permalink.gmane.org/gmane.org.w3c.whatwg.discuss/16742

[67] [whatwg] Various HTML element feedback ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/036998.html

[66] [whatwg] Various HTML element feedback ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-August/037000.html

[555] FAQ - WHATWG Wiki, , https://wiki.whatwg.org/index.php?title=FAQ&oldid=9975#Why_are_some_presentational_elements_like_.3Cb.3E.2C_.3Ci.3E_and_.3Csmall.3E_still_included.3F

[85] 関連: samp, var, b, i


[68] HTML Italic and Bold Elements as regards Web Standards | The Elementary Standards (Sean Fraser 著, 2007-05-22 11:09:10 +09:00 版) http://www.elementary-group-standards.com/web-standards/html-presentation-elements-web-standards.html (名無しさん 2007-05-25 01:05:19 +00:00)

[69] カナかな団首領の自転車置き場 - 物理要素とか (2007-07-08 14:49:00 +09:00 版) http://d.hatena.ne.jp/kana-kana_ceo/20070706/1183719689 (名無しさん)

[70] HTML に装飾要素は必要 (2007-07-03 09:56:06 +09:00 版) http://deztec.jp/design/07/07/02_html5.html (名無しさん)

[71] HTML 5 の中の人の意図を推測したいならせめて Design Principle くらい読んでおいて欲しいものですな。

HTML Design Principles (2007-06-27 01:27:04 +09:00 版) http://dev.w3.org/cvsweb/~checkout~/html5/html-design-principles/Overview.html#separation-of-concerns

However, structural markup is a means to an end such as media independence. Profound and detailed semantic encoding is not necessary if the end can be reached otherwise.

いつの間にか一部の人から絶対的なものと妄信されるまでに至った表現と構造の分離はそもそも手段であって、 目的ではなかったのです。 (名無しさん)

[72] HTML 5のi要素とb要素、sup要素とsub要素、small要素:メモランダム (2007-07-09 20:54:42 +09:00 版) http://mynotes.jp/blog/2007/07/html5_elements (名無しさん)

[73] 構造と見た目の分離:メモランダム (2007-07-09 20:54:42 +09:00 版) http://mynotes.jp/blog/2007/07/separate_structure_and_presentation (名無しさん)

[18] XSLT and XQuery Serialization 3.0 ( ( 版)) http://www.w3.org/TR/xslt-xquery-serialization-3/#XHTMLPHRASING

[7] OSLC Core Version 3.0. Part 6: Resource Shape () http://docs.oasis-open.org/oslc-core/oslc-core/v3.0/cs01/part6-resource-shape/oslc-core-v3.0-cs01-part6-resource-shape.html#dcterms:title

dcterms:title is used to provide a summary of oslc:ResourceShape and oslc:Property resources. Its value should be a literal of type rdf:XMLLiteral that is valid content for an XHTML <span> element. If the value contains no XML markup then it may be represented as a plain text literal or xsd:string.