[26] 語句化内容は、 文章やそれに準ずる段落内の構造を記述する要素です。
[27] かつては行内要素 (インライン要素) と呼ばれることもありましたが、明確化のため現在の名称となりました。
[25] 語句化内容は、 文書の文章や、 文章を段落内の水準においてマーク付けする要素です。 >>24
[28] 語句化内容の連なりは、段落を形成します。 >>24
[29] English の語 phrase (語句) は、 一般的には高々数個の単語の連なりを指していいます。 その -ing形 phrasing は、 文章の特定の法則性のもとで語句のまとまりに区切ること (句節) や、 語句で表される言い回しを表して使われます。
[30] 対して HTML における語句化内容の「語句化」は、 こうした自然言語的な特性とは独立した、 文書構造としての構成単位に着目しています。従って、 語句化内容である要素は自然言語の語や文より大きな単位にも、小さな単位にも、 それらの境界とは無関係に使えます。
[40] なお、初期の HTML の DTD での要素の分類の1つである %phrase;
と現在の語句化内容は意味が少し違っています (>>41)。
[31] 語句化内容という概念は HTML5 で要素の内容モデルや分類が整理された際に導入されました。 それ以前の HTML4 や初期 HTML5 はほぼ同じものを行内要素、行内内容のように言っていました。
[32]
ここでいう行内とは語句化とほぼ同じ意味で使われていた語ですが、
CSS でも display: inline
に代表される行内の概念があり、
紛らわしいため HTML では使わなくなりました。
[33]
行は CSS の行箱のような表示上の概念で、 HTML
の文書構造には (br
のような例外を除き) 直接出現しません。
語句化内容である要素は、行の境界とは無関係に使えます。
[15] 内容モデルが語句内容だけの要素や語句付け内容の一部の要素が除外されている場合の他に複雑な内容モデルのものがいくつかあります。
[16] ruby
要素は語句付け要素の部分と rt
要素や
rp
要素の部分が混在しています。
[17] HTML文書中の SVG title
要素の内容モデルは SVG
仕様上の制約に加えて HTML の語句化内容とされています。
[23]
SGML応用では語句化内容相当の要素の表現にいくつかの流儀がありました。
そのうちの一派は
CERN SGMLguid
のように
hpn
要素群を使う方式でした。
[34]
hpn
は
n
によって太字, 斜体などの表示効果を割り当てて使われました。
[35]
誕生当初の HTML は CERN SGMLguid から hpn
を引き継いだものの、実装と仕様化は不完全のまま保留状態でした。
[39]
予約されていた hpn
要素型群に代わって
語句のマークに使う語彙として DocBook や MIME
のものなどが候補に挙がりましたが、結局 GNU Texinfo
のものが中心に採用されました。
code
, var
,
em
, strong
,
b
, i
などが HTML に取り入れられました。
[93]
Dan Connolly はの半ば頃から、
HTML の仕様書と SGML DTD の作成に取り組んでいました。
hpn
の処理に取り掛かりました。
[91] >>1312 はの DanC の投稿。
TimBL の仕様書で未使用とされている
hp1
,
hp2
,
hp3
,
hp4
,
hp5
をどうするかについて、
em
,
tt
,
cite
Emphasis
,
OopsChar
,
wordasword
,
CiteBook
,
Subscript
,
Superscript
の2系統の案を提示しています。 >>1312 これに対する返信は >>2612 の TimBL の返答と、 DocBook に賛成するものの2件。
[36] DanC のメールでは TeX と書かれているが、正確なところは不明。
後述の通り \em
, \tt
は LaTeX にあり、
@cite
(と @emph
) は Texinfo にある。
LaTeX の \cite
は少し意味が違って、
citation への参照を表す。
[92]
>>2612 は >>91 に対するの
Tim Berners-Lee
の返信。
hpn
の番号システムはよくないとしつつも、
絶対に十分ではないこと、例えば
CiteBook
があるのに
CiteProgram
がない、ということを指摘しました。また、
DocBook の名前は長いのではないかと書いています。
[97] これだけでは真意を把握しかねるところもありますが、 ファイル日付がの >>1412 にはより詳しい記述があります。 すなわち:
[109]
つまり、
DocBook のように論理的な要素をいくら用意したところで、
いくらでも漏れは出てきます。
例えば船名を斜体にしたくても、専用の要素がありません。
斜体になるものといえば var
があります。
そうなると船名は var
で表せばいいということになってしまいます。
[37] この TimBL の指摘は慧眼というべきで、 blockquote
が字下げに使われる事案など、
この後の時代にそういうものを嫌と言うほど見せつけられることになる。
[38] HTML5 の時代になって Ian Hickson が物理要素の完全排除を断念して
b
や i
を新しい意味で復活させたのも、このときの TimBL
と同じ判断。
[111] >>1412 の MIME への言及は、 MIME text/richtext
に関するものですが、
MIME と HTML の関係をどうするかが議論になっていた半年前の >>110
の TimBL 記事の理解が土台となっていると思われます。
text/richtext
も SGML にするべき、簡単にできるtext/richtext
と HTML を比べると、hp0
, hp1
は未実装[127] text/richtext
には bold
, italic
の他にも文字サイズ、
改行改頁、ページヘッダー・フッター、下線などの機能がありますが、
HTML に欠けているのは bold
と italic
というのが TimBL
の判断だったようです。
[128] SGML の設計原理である一般化マーク付けの考え方が、ここで明確に HTML の従うべき方針として言語化されていることに注意したいです。 これが初出でしょうか (探せばもっと前にもあるかも)。
[129] TimBL が SGML や LaTeX や Texinfo の設計方針をよく理解していたのか、それとも NeXTSTEP の WorldWideWeb と各プラットフォームの Line Mode Browser とその他のWebブラウザーが既にあって、 利用できるフォントその他の条件がまったく異なる環境でも機能しなければならない、 という現実的制約から必然的に同じ結論に導かれたのかはわかりませんが。 WorldWideWeb がスタイルシート機能を持っていたので、基礎的な考え方は SGML から引き継いだのかもしれません。
[94]
付仕様書、
付 DTD が現存します (hpn
も新要素も入っていません。
2007-07-02 21:17:14 +09:00
版) http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1992.messages/370.html[134] >>133 の付 DanC のメールには、 未決の課題が挙げられています。
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] つまり、この時点ではまだ未決で、
em
, it
, bf
, sf
, sl
, tt
text/richtext
は typographic なものだけと決めかねていました。
[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
が念頭にあったというくらいは言えるでしょうか。
2007-07-02 21:27:49 +09:00
版) http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1992.messages/412.html[60] >>59 のの DanC のメールは、 の 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 の話題が出たから詳しく書いたということでしょうか。
[153] >>148 の
「そこで」のつながりもあまりよくわかりません。
Texinfo が良さげだと思ったものの、
@ctrl
のように HTML に完全にはフィットしないので、
他にもっといいものがないか探したということでしょうか。
[154] この書き方だと、結局 Texinfo はこの時点でまだ仕様書に追加してはいなかったということになるのでしょうか。 だとすると説の方が妥当な解釈でしょうか。
[155] とわからないことだらけではありますが、 DanC がこれまでにメーリングリストで挙げられていたもの以外にもいろいろな文書形式を調べていた(調べようとしていた)ことがわかります。
2007-07-02 20:33:40 +09:00
版) http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1992.messages/428.html[56] >>55
Dan Connolly の、語句要素を入力するのが面倒なので
SHORTTAG
を使えるようにしませんかという提案。
TimBL の返信は否定的で、採用されず。
As I was adding phrase-level elements (from TeXinfo: em, strong, code, file, cite, etc.)
とあり、 Texinfo 由来で
em
,
strong
,
code
,
file
,
cite
等を追加しようとしていたそうです。
[77] >>156
このときの仕様書は現存が確認されていませんが、 DTD は
html.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 $
とあります。
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 という表現の初出でしょうか。
<!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
です。
そのうちの dfn
と key
は数奇な運命をたどっております。
(それぞれの説明を参照されたし。)
[79]
1992年12月3日 → 1993年1月6日で
%inline;
として追加されたのは:
em
, tt
,
strong
, b
,
i
, u
,
code
, samp
,
kbd
, key
,
var
, var
,
dfn
, cite
。
[161] >>158 のの DanC の投稿は何気に重要記事で、
追加要素に関する GNU Texinfo のドキュメント該当部分を引用しています。
ここから追加当時の
code
,
samp
,
kbd
,
key
,
var
,
dfn
,
cite
,
@emph
(em
),
strong
,
i
,
b
の想定された用法を知ることができます。
[162] 注意したいのは、
@ctrl
がこの引用には含まれない@emph
があるが追加されたのは em
@t
がこの引用にはある (tt
に相当するがこのとき
tt
は追加されていない)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?
[169] 当項目の主題とは関係ないがこういうのも:
4. HTML should support QUESTION and RESPONSE elements to support converting USENET FAQ's to HTML
> 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.
[180] ちなみに >>177 は man の HTML 化のために
pre
の中で b
, i
, u
が必要という TimBL の認識を示していて、これらの要素が必要と考えられた理由の1つが知られます。
[222] >>221 は頃のものと思われる HTML 仕様書案で、語句化内容要素の意味の説明としては現在知られる最古のものです。 これより古いのは DanC による Texinfo からの引用 (>>158) と DTD 追加時の概要説明 (>>75) だけしかありません。
[223] >>158 の引用は語句化内容要素の説明を TimBL の仕様書 (
[224] その追加後の状態の TimBL の仕様書の現存は確認されていませんが、 >>221 の要素の説明部分は、他の要素の説明文や途中に 「Tim BL」 と書かれた箇所があることから推測して、 Tim BL の HTML 版仕様書の文言に由来していると推測されます。 この推測が正しいとすれば、 >>221 の語句化内容要素の説明は >>223 の追加分だと考えられます。
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
TT Fixed-width typewriter font B Boldface, where available, otherwise alterntive mapping allowed. I Italic font (or slanted if italic unavailable). U Underline?? 3.18.2 Logical styles
EM Emphasis, typically italic. STRONG Stronger emphasis, typically bold. CODE Example of code SAMP A sequence of litteral characters KBD in an instruction manual, Text typed by a user. VAR A variable name DFN The defining instance of a term CITE A citation 3.18.3 Examples of use
See test complete markup set. Tim BL
[372]
key
の説明がなぜかありません。 DTD にはあります。
strong
, b
, i
, code
, samp
,
kbd
, key
, var
, dfn
, cite
:
Texinfo からの借用 (>>201)em
, tt
: LaTeX からの借用 (>>181)u
: 不明の3系統の元言語から取り込まれたことになります。
[80] >>79 1993年5月の GNU Texinfo 3.1 のマニュアルの語句要素相当の部分と比較すると:
emph
が HTML では em
t
が HTML では tt
u
file
と
ctrl
(ただし Texinfo マニュアルでは非表示になっている)
と r
と sc
という違いがあります。 ctrl
は HTML
には相応しくなかろうと Dan Connolly が発言しています。
r
と sc
は
Texinfo 2 の新機能と NEWS
に書いてあるので、もしかすると Dan
が参照した版には入っていなかったのかもしれません
(し、入っていたけどフォントを直接指定するものはあえて除外したのかもしれません)。
[82]
予想ですが、 em
は
emph
では長すぎるから
(LaTeX より拝借)、 tt
は
t
では短すぎるから (それほど使わなそうな割に)、
u
は Microsoft Word
に b
と i
と一緒にあるから、というような理由ではないでしょうか。
(名無しさん)
[83]
んー、でも RTF 1.0 に含まれているのは \u
ではなく
\ul
だ。。。
(名無しさん)
[84]
em
が略されて strong
が略されなかったのはなぜでしょう。 LaTeX
になかったから?
[179]
>>148 にあるように DanC が LaTeX を検討していて、そこに
em
と tt
があります。理由はわかりませんが、
この2つだけは LaTeX から採られたと考えて間違いなさそうです。
[220]
>>157 の DTD 追加部分の要素の順序、改めて見ると
em
と tt
が先頭にあります。
code
から cite
は Texinfo のマニュアルの順序そのままです。
間に strong
, b
, i
, u
が挟まっているのがよくわかりませんが。
[215]
u
は今のところ先行する言語の採用例が見つかりません。しかし特徴的な
「B」「I」「U」
ボタンに着想を得た可能性はありそうです。
[219] >>218 は Macintosh 版 Microsoft Word 3.0 () の画面写真。 「B」「I」「u」 とボタンが並んでいるのがわかります。
[226]
ところで >>222 からの経緯で作られた HTML の仕様書で u
が「下線??」
と意味が不明になっていることは見逃せません。
追加後何ヶ月も立たないうちに、追加の当事者らによって作られた仕様書であるにも関わらず、
早くも新要素の意味が推測だけで書かれるという、異常な事態が起こっています。
[227]
DanC の引用には @i
, @b
, @t
があって u
や tt
はありませんが、 DanC はそれに気づかずに(?)メールを送っています。
@file
が HTML から抜け落ちたことには気づいているのですが。
という 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 の区分となっています。
[201] DanC が明言しているように最初に追加された語句化内容要素群は基本的に Texinfo からの借用です (>>161)。
[232] GNU Texinfo は GNUプロジェクトのドキュメントシステムです。 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 の引用とよく似た箇所があります。 引用した部分以外にも多くの説明があります。分量が多いですが、 重要なので引いておきます。
@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.
@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 はこの時点で既に何年にもわたって多くのソフトウェアドキュメントの記述、 そしてソフトウェアに付属させての配布や印刷物としての出版の実績を積み重ねていて、 そのために必要な語彙がある程度整備されており、 しかもそれぞれの用法について詳しく説明されています。
[209] この詳細な説明が全文 HTML の要素一覧にも引かれていれば、 その後の展開もまた違ったものになっていたでしょうね。
[240] GNU Texinfo のマニュアルの記述を要約すると:
@code
`
...'
で引用@samp
@file
@kbd
@key
@key{RET}
@kbd{C-x @key{RET}}
SPC
(間隔), RET
(復帰), LFD
(行送り),
TAB
(タブ), BS
(後退), ESC
(逃避), DEL
(削除),
SFT
(シフト), CTL
(制御), META
(メタ)@key
を使い、
組み合わせのとき @kbd
だけで使う@kbd{Meta-a}
@key{META}
@ctrl
@var
@dfn
@cite
@emph
@strong
@i
@b
@t
@code
と @samp
は明らかに対照的、相補的に定められています。
誤解を恐れず一言でまとめてしまうなら、
プログラミング言語的なものの字句(群)としてそのまま意味を成すものが @code
、
それ以外のすべてが @samp
となります。@kbd
はただ単に打鍵されるべき鍵・文字列を示すというよりは、
打鍵列を表す表記構文という1つのプログラミング言語的なもの用に特化した
@code
というべきかもしれません。@ctrl
は SGML 的には文字参照で表すのが正統的な方法で、
HTML が採らなかったのは自然な流れといえますが、
ソフトウェアマニュアルとしてこの機能が必要だった (特にこの時代には。) のは頷けます。@file
はソフトウェアマニュアルとして必要なことは確かですが、
なるほど HTML に持ち込むには具体的すぎると感じるのもわかります。@emph
, @strong
が推奨されない直接的な記述に分類されています。
これはちょっと意外ですね。@emph
より @strong
が強いという関係が明記されています。[181]
em
と tt
は、その要素名を 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
が大量に使われているので、
いくつか用法を見ておきましょう。
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
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
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
で文中の語を強調、 \tt
で LaTeX の機能名
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
はおおむね現在の HTML の code
の役割で使われています。 \em
はいろいろな意味で強調、
周りとの区別を表すために使われていて、現在の HTML
でいえば em
, strong
, var
, kbd
など幅広く応用されています。
[200]
これを現在視点から見ると code
があるのに tt
は要らなそうにも感じますが、
当時の code
の意味と比べると、 \tt
がないと困りそうです。
@file
が省かれて \tt
が採用された理由もこの辺りにあるのかもしれません。
[235] これらに出現するものを DanC の言及と比較すると、
LaTeX | >>187 | bf | it | rm | sl | ss | tt | ||||
---|---|---|---|---|---|---|---|---|---|---|---|
LaTeX | >>188 | rm | it | bf | tt | sl | sf | sc | em | ||
LaTeX | >>189 | em | rm | it | bf | sl | sf | sc | tt | ||
DanC | >>134 | em | it | bf | sf | sl | tt | ||||
DanC | >>148 | em | tt | bd | sl | sf | |||||
HTML | em | tt |
と実にバラバラで、 DanC が参照したのはここで引いたどれでもなかったのかもしれませんが、 それにしても >>134 と >>148 で違うのは一体どういう理由によるものなのでしょう。
[236] >>134 と >>148 の違いは誤記、誤写、もしかすると手書きを経由している可能性すらあるのではとも思わせられますね。
[470] Texinfo の詳しい説明が引き継がれず HTML では短い簡潔な説明になりましたが、 それでは使い方がわからないということで、後続の仕様で少しずつ言い方が改められています。 しかしそれでも不明瞭な部分が多く、著者は解釈に悩まされ、色々な使い方をしてきました。
[471] HTML5 はその反省から、あるものは利用の実態に合わせて、 あるものは新たに利用目的を再設定することにより、 詳細な要素の意味の説明を0から決め直しました。
[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
を表示できない環境で i
を italic 表示せよと無理強いはしていません。
しかし地の文や b
と違う表示は求めています。
code
のその後Indicates text that is a literal example of a piece of a program.
CODE Example of code
- CODE
- Example of code. typically monospaced font. (Do not confuse with PRE )
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 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
プログラム符号
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] 「符号」という中心義を維持しながらも、そのあり方はかなりの変化を見ています。
code
が使われるようになりました。samp
のその後Indicates text that is a literal example of a sequence of characters.
SAMP A sequence of litteral characters
A sequence of literal characters.
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
ではアルファベット順になっていて、完全に code
と samp
のつながりが絶たれてしまいました。
SAMP used for sample output from programs, and scripts etc.
[495] HTML 3.2 で旧来の順序が復活。 HTML4 もそれを踏襲しました。
Designates sample output from programs, scripts, etc.
Computer output
The
samp
element represents sample or quoted output from another program or computing system.
[497] samp
は最も迷走した要素といえます。現在もその用途が不明瞭で不遇な扱いです。
@code
と @samp
が対で相補的に説明されていましたが、
HTML ではその関係性が引き継がれませんでした。
(先述)@samp
という命令の名前が説明と合っていない感があります。
(先述)@code
と同じく (>>475)、
ドキュメントの文章中で実際の入出力文字列片の一部を提示したものという程度の意味だったと思われます。[508]
元々 Texinfo 的には、英文中にコマンドライン引数とか、
プログラムの出力テキスト例とか、
正規表現とか、
利用可能な文字のリストとか、
なにかの識別子とか、
地の文とは区別したくて、固定長フォントがしっくり来る、
ときには引用符で括っておきたいのだけれども、
プログラムの関数名や変数名やその他字句の並びとは性質が違っていて
@code
は相応しくない、そんな諸々のものを @samp
で表すとしていたようです。
[509] これを説明なしで理解しろといわれても無理な話ですし、歴代 HTML 仕様に関わっていた人達も HTML のマニュアルを書いた人々も、 Texinfo に戻って確認することなく雰囲気だけで説明を書いていたのでしょうね。
kbd
のその後Indicates the names of keys on the keyboard or characters you type.
KBD in an instruction manual, Text typed by a user.
in an instruction manual, Text typed by a
user.
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 -->
KBD used for text to be typed by the user
Indicates text to be entered by the user.
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]
文字でなく鍵も指定できることがわからなくなっていますが、
HTML5 は kbd
の入れ子で記述できることと定めました。
要素名こそ違うものの、 key
が復活したことになります。
[514]
HTML4 には特に記述がないものの、実態として kbd
が鍵の名前のために使われることはあったので、 HTML5
で用法が整理されたものです。入れ子で区別するという手法はおそらく HTML5
の創案です。
key
のその後Used for the conventional name for a key on a keyboard.
[430] HTML 1.0 : DTD にあるが本文になし
[512] 本文から欠落して忘れ去られてしまったのか、不要だと判断されて削られて一時 DTD に残ったままになっていたのかわかりませんが、早々に消え去ってしまいました。
var
のその後Indicates a metasyntactic variable.
VAR A variable name
A variable name.
The <VAR> element indicates a placeholder variable, typically
rendered as italic. For example:
<!-- <VAR> Variable phrase or substitutable -->
VAR used for variables or arguments to commands
Indicates an instance of a variable or program argument.
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
のその後Indicates the introductory or defining use of a term.
DFN The defining instance of a term
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 要素は囲まれた用語の定義的実現値を含めます。
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 thedfn
element must also contain the definition(s) for the term given by thedfn
element.
[517]
初期には dfn
はなぜか他の要素と違って実装から欠落し、仕様書からも削られていました。
その後復活しました。
[518] 意味には大きな変化はありません。
cite
のその後Indicates the name of a book.
CITE A citation
A citation. Typically italic.
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 -->
CITE used for citations or references to other sources
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>.
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
のその後emphasis
EM Emphasis, typically italic.
Emphasis, typically italic.
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 -->
EM basic emphasis typically rendered in an italic font
Indicates emphasis.
Generally, visual user agents present EM text in italics and STRONG text in bold font.
Stress emphasis
The
em
element represents stress emphasis of its contents.
[523] Texinfo は他に該当する表現がないような強調としていましたが、 HTML は引き継がずにただの強調としました。 そのためよく使われる要素となりました。
[524] ソフトウェアの技術マニュアルに用途を限定しない HTML としては悪くない判断ではあるのですが、 他の要素との関連性が失われて「強調」というものの性質の理解が難しくなったようにも思われます。
[525]
HTML5 は strong
との区別が求められたために、
文の意味を変えるような性質の強調が em
だとしました。
これも悪くはない判断ではあるのですが、
厳密に言えば過去の用法との連続性が失われています。
strong
のその後emphasis
stronger
STRONG Stronger emphasis, typically bold.
Stronger emphasis, typically bold.
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 -->
STRONG strong emphasis typically rendered in a bold font
Indicates stronger emphasis.
Generally, visual user agents present EM text in italics and STRONG text in bold font.
Importance
The
strong
element represents strong importance, seriousness, or urgency for its contents.
[526]
Texinfo では @emph
よりも強い強調とされていました。
HTML にも引き継がれたものの、次第に比較対象が明言されなくなりました。
そのため「em
より strong
が強い」という意識は著者の間に残ったものの、
出典不明の怪情報のような扱いになっていきました。
[527]
実態として em
は斜体、 strong
は太字で使われていましたが、
表示の違いだけで別の要素があるのはおかしいと考えられた時代にちょうど作られた
HTML5
は em
と strong
に別の意味を与える必要があり、
strong
を強い重大性、深刻性、緊急性を表すとしました。
tt
のその後typewriter font
TT Fixed-width typewriter font
Fixed-width typewriter font.
The <TT> element indicates teletype (monospaced )text. Where a
teletype font is unavailable, an alternative representation may be
used.
<!-- <TT> Typewriter text -->
TT teletype or monospaced text
TT: Renders as teletype or monospaced text.
b
のその後bold font
B Boldface, where available, otherwise alterntive mapping allowed.
Boldface, where available, otherwise
alternative mapping allowed.
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 -->
B bold text style
B: Renders as bold text style.
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 は、新しい意味で説明し直しました。
[540] 表現は変わっていますけど、
ということで、「なんか太字っぽい、しらんけど」程度の位置づけってのはずっと変わってないんですよね。
i
も同じで。
[544]
b
も i
も見かけの定義が随分と変わったので物理要素絶対反対勢からも物理要素別にいいじゃん勢からも反発はありましたけど、
「もっとちゃんと現実を見ましょう」が基本方針の HTML5
が突飛なことなんてやるはずないんですよねえw
i
のその後italic font
I Italic font (or slanted if italic unavailable).
Italic font (or slanted if italic
unavailable).
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 -->
I italic text style
I: Renders as italic text style.
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
のその後
U Underline??
Underline.
characters, and the <U> element indicates an underline.
とあります。
U underlined text style
U: Deprecated. Renders underlined text.
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ブラウザーにはあまり実装されなかったようで、一旦は仕様から外されました。
後に復活しましたが、 HTML4 で b
や i
と違って非推奨とされたのは、
実装が遅かったこと、それだけ機能としての重要度が低かったことが影響しているのでしょう。
[538]
HTML5 でも b
と i
は他の専門の要素で表現しきれない場合のために、
多少強引な意味を新たに付与してまで残されてたものの、当初 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 に対する拡張と称して、
b
や i
を入れ子にしても Netscape Navigator
がその通りにレンダリングするようになったことを紹介しています。
<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.
なんて書いてあります。
DTD の注釈には行内要素 (
と書かれています。文水準
要素)
仕様書:
[12]
また、 DTD の注釈には文字水準要素および文字列
とも書かれています。
仕様書:
[12] Matthew Thomas » Blog Archive » 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
[9]
HTMLもどきの DTBook にも同じような %inline;
がありました。
[10]
HTML とは違って %inlineinblock;
もありました。
[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)
[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
[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
text/richtext
も思いっきり SGML 風の構文を採用したからには、設計者は何かしらの SGML応用に接する環境にはいたはずですよね。