[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 と書かれているが、正確には Texinfo。
[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
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 まで残りました。
[201] DanC が明言しているように最初に追加された語句化内容要素群は基本的に Texinfo からの借用です (>>161)。
[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.
[209] この詳細な説明が全文 HTML の要素一覧にも引かれていれば、 その後の展開もまた違ったものになっていたでしょうね。
[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
が採用された理由もこの辺りにあるのかもしれません。
[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
[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応用に接する環境にはいたはずですよね。