テキストエディタ風のデザインをCSSで作つてゐるうちにできた副産物。ユーザースタイルシートで使ひます。
*{
text-indent: 0 !important;
text-decoration: none !important;
letter-spacing: normal !important;
word-spacing: normal !important;
text-transform: none !important;
white-space: normal !important;
color: WindowText !important;
background: Window !important;
font: normal normal normal medium/normal
"ＭＳ Ｐゴシック",sans-serif !important;
margin: 0 !important;
padding: 0 !important;
border: 0 !important;
position: static !important;
float: none !important;
clear: none !important;
overflow: visible !important;
display: inline !important;
width: auto !important;
height: auto !important;
}「CSSなんてどうでもよい」といふ立場を採る人がゐるけれど、どのやうに読まれたいか、といふ制作者の意思を示すために重要であるはずだ。それが気にくはなければ、各自ユーザースタイルシートを適用すればよいだけの話。上記のやうなスタイルだと、ソースを見ない限り見出しやアンカーの区別がまるでつかない。スタイルなんていらない、といふ人はこれを適用してみればいい。私が「CSSは重要だ」といふ根拠はつまり、己の表現を如何にして他者に伝へうるか、といふ自意識をもつためだ。内容だけが重要なのだと言つて憚らない人は、アレな恰好をして就職活動に行き、落とされると「外面だけを見やがつて」云々と息巻くDQNと変らない。内面をみて欲しければ外面を変へる努力をすべきだ。
ニールセン博士が述べてゐるやうに、テキストのアンカーには色をつけてアンダーラインを引くべきだが、問題はテキストだけではない。さう、画像である。
我われは、a要素の内容が文字列ではなく、画像（img要素）であるのをよく見かける。この場合、大抵のUAのデフォルトスタイルシートは、周りに青色のボーダーを設けてアンカーであることを示すが、制作者CSSを適用された場合、しばしばこれが無効化されてゐる。さうなると、ユーザはguess or scrub
することになる。一体なぜ、文書制作者はわざわざそんな意地悪をするのだらうか。
その答へは、およそ見栄えに集約されることは言を俟たないだらう。みんな、太い青色のボーダーが、色彩や配置に気を配つた画像の周りに取り囲むことを望まないのだらう。私もそれには同意する。しかし、アンカーであるはずのそれを、さうでないやうに見せかけることには、見栄え以上のメリットが存在しない。あるいは、メリットとデメリットとを比較した場合、デメリットの方が上回ることのはうが多くある。なぜなら、WWWとはテキストとテキストのハイパーリンクが重要であるからだ。
では、どうすればある画像をアンカーであるやうに見せることができるだらうか。それには様々な解が存在する。たとへばボーダーを設けるにしても、画像の辺全てに適用するのではなく、或る一辺だけにしてもよいかもしれない。この際気を付けるべきことは、それが見てすぐにアンカーと分かることだ。テキストのアンカーと同一の色を用ゐるか、デフォルトの色をそのまま指定しないと、それとは気づかないだらう。
だが、いづれにしろ、困難極まるものだ。これは私の感想だが、あらゆるCSSの記述のなかで、これほど難しいものはない。配色とバランスは、画像の内容によつて変り、指定した色が合はないことは多々ある。結局、一番良いのはデフォルトスタイルのままか、或はアンカーの内容に画像なんて使はないこと、といふことになる。画像は、テキストで伝へられない、伝へづらいものを表現するときに使ふのが一番なのだ。サイトコンテンツに画像を並べ、あらうことかalt属性も記述してゐないなんて、論外なのである。
こちらはあまり更新できません。undercooledは随時更新中。
ただ今過去ログの整理中で、index.cgiの方では更新が拾へません。アンテナやリンクをしてゐる方は注意してください。また、これを機に「猫想い」の使用を中止し、一時的に手動更新に切り替へます。「猫想い」には約一年間お世話になつて、愛着をもつてゐましたが。
で、はてなの方とこちらの区別ですが、あちらは完璧に日常雑記のみにしました。HTMLやCSSなども表現の範疇ですので、こちらにします。「仕様書を読み解く」の企画は、はてなで第一草稿を、第二草稿をこちらにアップします。
This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 [HTML32] and HTML 2.0 [RFC1866]), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.
HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language [ISO8879].
日本語訳が必要な場合は、邦訳を参照して欲しい。
上記の文書はHTML 4.01を読み解く上で大変重要である。なぜといつて、HTML 4.01の立場や概要、思想や特徴が、この一節に集約されてゐるからだ。この文書を念頭におくことによつて、HTML 4.01が目指すもののアウトラインを捉へることができる。
ここで述べられてゐるもつとも重要な事柄を要約すれば、以下のやうになる。
つまり、俗に不思議マークアップと呼ばれるマーク付けが、何故否定されるのかといふと、「ハンディキャップを持つ人々からの高いアクセス性をサポートすること」を拒否或は無視してゐるからである。逆に言へば、この思想に異議のない者は、HTML 4.01で文書を記述すれば良いといふことになる。
This specification is divided into the following sections:
- Sections 2 and 3: Introduction to HTML 4
- The introduction describes HTML's place in the scheme of the World Wide Web, provides a brief history of the development of HTML, highlights what can be done with HTML 4, and provides some HTML authoring tips.
The brief SGML tutorial gives readers some understanding of HTML's relationship to SGML and gives summary information on how to read the HTML Document Type Definition (DTD).
- Sections 4 - 24: HTML 4 reference manual
- The bulk of the reference manual consists of the HTML language reference, which defines all elements and attributes of the language.
This document has been organized by topic rather than by the grammar of HTML. Topics are grouped into three categories: structure, presentation, and interactivity. Although it is not easy to divide HTML constructs perfectly into these three categories, the model reflects the HTML Working Group's experience that separating a document's structure from its presentation produces more effective and maintainable documents.
The language reference consists of the following information:
- What characters may appear in an HTML document.
- Basic data types of an HTML document.
- Elements that govern the structure of an HTML document, including text, lists, tables, links, and included objects, images, and applets.
- Elements that govern the presentation of an HTML document, including style sheets, fonts, colors, rules, and other visual presentation, and frames for multi-windowed presentations.
- Elements that govern interactivity with an HTML document, including forms for user input and scripts for active documents.
- The SGML formal definition of HTML:
- The SGML declaration of HTML.
- Three DTDs: strict, transitional, and frameset.
- The list of character references.
Sections 2 and 3: Introduction to HTML 4
では、
と述べられている。以上の項目は、仕様書を読み解くにあたって、頭に入れながら読むと良い。目的を意識しながら読むことにより、論理の筋道が明確に見え、理解しやすくなるだろう。
次に、Sections 4 - 24: HTML 4 reference manual
では、本仕様書がHTMLのリファレンスであり、HTMLの要素及び属性すべてがここで定義されていると述べられ、技術的な位置付を定義している。しかし、文法よりもトピック（テーマ）を重視して構成しているという。それらは、以下の三つに大別される。
この三つに分類するのは、HTML作業部会の経験を反映したもので、その利点はより有効的で、保持性が良い文書になるというものである。さらっと書いているが、ここは重要である。「ハンディキャップを持つ人々からの高いアクセス性をサポートする」ことがHTML 4の思想であるとこの前書いたが、それにプラスして、文書の訴求力や保守性を高める効果が期待できる特徴も兼ね備えているということだからだ。もし、なぜHTML 4で文書を記述しているのかと問われれば、これらを答えればよいのである。そして、それに答えられないようならば、あなたの文書は裏打ちされていない信用ならぬものとされるだろう。思索と行動は密接不可分で、行動は常に深い思索の先に表われるべきだ。閑話休題。
リストは、上述した三つのカテゴリーによって分類されている。上二つは前提となる基本データ形式を定義したもの。次（上から三つ目）は文書の「構造」を定義する要素、四つ目は文書の「表示」を定義する要素、五つ目は文書の「対話性（インタラクティブ性）」を定義する要素、と具体的な紹介であるが、これは後に触れることになるので、今は無視してよい。そして最後のリストは、SGMLによるHTMLの定義だが、SGMLが読めなければ無理であるし、これも後で詳細な解説があるので飛ばす。
This document has been written with two types of readers in mind: authors and implementors. We hope the specification will provide authors with the tools they need to write efficient, attractive, and accessible documents, without over-exposing them to HTML's implementation details. Implementors, however, should find all they need to build conforming user agents.
The specification may be approached in several ways:
- Read from beginning to end. The specification begins with a general presentation of HTML and becomes more and more technical and specific towards the end.
- Quick access to information. In order to get information about syntax and semantics as quickly as possible, the online version of the specification includes the following features:
- Every reference to an element or attribute is linked to its definition in the specification. Each element or attribute is defined in only one
location.
- Every page includes links to the indexes, so you never are more than two links away from finding the definition of an element or attribute.
- The front pages of each section of the language reference manual extend the initial table of contents with more detail about that section.
前段は仕様書の想定する読者を述べているだけ。あとのリストは仕様書の利用方法を述べている。要するに、仕様書を通読するにしても、分かりやすいように、最初は用語の解説を、後になると技術的な内容になるように書かれてい、通読せずに必要な情報を得るだけという読み方でも、素早くアクセスできるようにしている、ということである。本稿は通読を目的としているため、リンクをクリックすることはあまりしなくてよい。目的が分散されれば余計分かりにくくなる。
Element names are written in uppercase letters (e.g., BODY). Attribute names are written in lowercase letters (e.g., lang, onsubmit). Recall that in HTML, element and attribute names are case-insensitive; the convention is meant to encourage readability.
Element and attribute names in this document have been marked up and may be rendered specially by some user agents.
Each attribute definition specifies the type of its value. If the type allows a small set of possible values, the definition lists the set of values, separated by a bar (|).
After the type information, each attribute definition indicates the case-sensitivity of its values, between square brackets ("[]"). See the section on case information for details.
仕様書の記述の仕方を述べている。これは仕様書にできるだけはやく馴染むために、ぜひ覚えておこう。
一つ目と二つ目は分かってもらえると思う。ただし、HTMLにおける要素名と属性名には大文字と小文字の区別はない。これは便宜上分かりやすくするための処置というだけだ。
分かりにくいのは三つ目と四つ目だろう。これは実例を見てもらった方が話は早い。
Attribute definitions
- dir = LTR | RTL [CI]
- This attribute specifies the base direction of directionally neutral text (i.e., text that doesn't have inherent directionality as defined in [UNICODE]) in an element's content and attribute values. It also specifies the directionality of tables.Possible values:
- LTR: Left-to-right text or table.
- RTL: Right-to-left text or table.
これはdir属性の定義だが、縦線(|)でLTRとRTLとを区切っている。つまり、dir属性がとる値はLTRとRTL二つあるという意味である。
そして次に、角大括弧([と])の部分には[CI]と書かれている。リンク先には、CIについての定義が書かれていて、CIは小文字と大文字の区別をつけない、と解説している。つまり、LTRにしろRTLにしろ、ltr,rtlでもよく、LTR,RTLでもよいという意味だ。
以下1.2.2と1.3の項目があるが、1.2.2は推奨しない例と不正な例は特別なレンダリングが施されるようにしているというだけだし、1.3は仕様書のドラフトに参加した人々への謝辞だから、読まなくても問題ない。