● 電子文書の作法を考える 99.11.22…99.11.25…99.11.28…99.12.2…99.12.20
●電子文書（デジタルドキュメント）は、ワープロを使っていれば実現している、とは限らない。
●デジタル化の本質は、データの再利用にある（ただの閲覧といえども再利用に他ならない）。これを環境（プラットフォームやOS）や時空間を越えて実現していくこと、それが情報化の要のはずである。
●オープンな環境でのJavaScript利用には、慎重にならざるをえない。公開する場合は高い完成度が求められる。
専用ワープロのデータをコンピュータのテキストにするだけでも、結構問題がある。ワープロやコンピュータの機種を問わない回答としては、2DDのフロッピー（身近に存在しない場合は2HDのフロッピーの孔…スライド蓋のついてない方…をセロテープでふさぐ手もある）を720KBでMS-DOSフォーマットしたものを用意しておく。Macがある場合は、MacでDOSフォーマットした方が確実である。専用ワープロは、必ずMS-DOS変換の機能を持っているので、後はそれを利用する。ただし専用ワープロの操作は分りづらい...
テキスト化できたとして、さてコンピュータで確認してみると、メールのように折り返しに全て改行が入っている。これを全て取り去り、あるべき段落改行を残すのは、エディタで処理するにしても一手間である。それが出来たところで、原稿をチェックしてみると、半角数字が奇数個並んでいる場合に（偶数個の場合は大丈夫）、半角スペース（空白文字）が必ず1個入っているのに気付く。あるいは括弧が全角と半角が混じっていたり、段落冒頭の1字開けが半角スペース2個分だったりする。よくあるのが、位置決めにスペースを入れている場合が多いことである。これはタブ設定で処理すべきである。そもそも原稿段階では、センタリングや右寄せには、一切しない方がいい（するだけ無駄である）。最後に気付くのが、インデントのかわりに入れたスペースである。
きりがない話だが、機種依存文字コードも大きい問題である。特に問題なのがローマ数字、丸数字などである。これらは、互換性を考えれば、アルファベットないし算用数字で表現すべきである。なお、アルファベット及び数字一般を、全角半角いづれにするかは好みの問題であるが、筆者は原則として半角で統一している（何にでも例外はあるが...）。全角（2バイト）の各種記号の類は、原則的に注意した方がよい。
こうしたきれいなテキストファイルが求められるのは、DTP化するなどして編集すると、元のレイアウトは維持されないからである。文字の間隔（カーニング）も、DTPでは文字や段落の設定などで細かく指定できる。
この項での結論は、だから専用ワープロマシンは止めて、コンピュータを使えということである。それも、次項で説明するようにイタリックなどの書体が必要でない限り、ワープロ（以下、コンピュータのアプリケーション）ではなくて、エディタをお薦めする。もっとも、次次項で説明するような、構造化を盛り込む場合は、その限りでない（HTML化はともかく）。
きれいなテキストにこだわっていると、今度はイタリック体（斜体）も下付き数字（H2O→H2O）も上付き数字（14C→14C）も、書式として失われていることに気付く。面積のm2も、全角の記号文字（�F）でなく、mと2で表したいが、m2ではちょっと困る。
ワープロの中では表現できる文字書式を、アプリケーションを越えて維持していくためには、どうしたらよいだろうか。Macでは.edf（エルゴソフトの提唱規格）が有力だが、Windowsでの一般性を考えると、いわゆるリッチテキスト（Microsoftの提唱規格で、本来の拡張子は.rtf）ということになる。これらの互換用フォーマットによって、フォント指定はともかく、イタリックなどの書式が維持できるのはありがたい。なお今後は、HTMLを中間フォーマットとして扱うケースが多くなると予想される（今の所、DTPではedfないしrtfに限るようだが）。といっても、最低限必要な書式は、イタリック・下付き数字・上付き数字だけなのだが...
文書には基本的な構造というものがある（一般論として）。文書には、章節項などの階層的な見出し、本文、注、図版、表などのパーツがある。そうしたパーツ（エレメント）は、全てHTMLに用意されている。「注」専用のシステムは無いが、ハイパーリンクの適用が相当する（相互リンクも可能）。図版はイメージとしてリンクできるし、文書に埋込むこともできる。筆者名なども、用意されていると言えないこともない（それを使うと一般にイタリックで表示されてしまうが...）。
こうしたパーツと、その表示は自ずと別問題である。書式というと、表示と密接に結びついた概念であるが、HTMLでは論理的な書式（構造）と物理的な書式（表示）は分離可能な概念である。特にスタイルシートを使うと、本サイトのページで見るように、見出しに地色のついた枠がつき、本文は若干の行間を持って表示できる（表示はあくまで一例）。文書データ自体はごくシンプルなものである。
余談だが、以前、line-heightにem指定をしていたのだが、これだとIE3.0はline-heightゼロと誤解してしまうことが分かったので、現在はpt指定にしている。WindowsのIE3.0は未だに現役の場合もあるから、当然配慮すべきことであった。ついでに、Netscape Navigatorでの行間表示もノーマルになった（em指定だと広がり過ぎだった）。
HTMLが持っている理念としての構造化は、どちらかというと論文系に適合したものである。報告書は、文書としては論文系なのだから、構造化に適しているはずである。無論、ワープロやDTPにも、階層的な見出しを設定できるなど、構造化の道筋は用意されている。
HTML文書の作成には、HTML作成支援ソフトを使いたくなるかもしれないが（特にテーブルの作成など）、できる限りエディタでの作成をお薦めする（少なくとも学習段階では）。HTMLで必要なタグ（エレメント）は、たかがしれている。概念的には、段落書式だと思えば、プログラミング言語よりはるかに易しい。最初はシンプルな組み合わせから始め、徐々に機能を盛り込んでいけばよい。その方がタグの正しい適用、構造化を意識した文書作成を実現しやすい。HTML作成支援ソフトは、ロクでもないソースを作りやすい（全てがそうだとは言わないが）。
もっとも問題なのは、必要性の疑わしいタグを入れてしまうことである。本文（P）のフォント指定は、すべからく迷惑である。フォントサイズは、ユーザの設定したもので読ませてほしい。標準フォントを12ptにするか、14ptにするか、はたまた18ptにするか、それはユーザの自由というものである（これはバリアフリーやユニバーサルデザインの問題である）。特にフォント指定やalignが全ての段落に入っている場合など、いたずらにファイル容量を増やすだけである。そうした問題に気付くか どうかは、やはりタグを学習し、多少ともエディタでHTML文書を作成してみるかどうかにかかっている。
ちなみに読みやすさを考えると、色指定や背景画像、背景色などは十分な注意を要する。文字色は通常濃い色であるが（黒とかリンクの青とか）、背景が中間濃度以上に濃いものだと字が読みにくい柄の背景画像は、しばしば見受けられるところである。特に、背景色に目にちかちかするような色を使うのは、非常識というものである。また点滅するようなサイクルのGIFアニメーションも、文章を読む気をそぐ効果がある。意味があるかどうか疑わしい画像を多用する傾向も同様だが（日本考古学協会サイトが典型的）、要するに「マルチメディア」という、ありもしないドグマにとらわれているのである。大事なのは「デジタルドキュメント」であり、「知識のより良い流通」ではないか。
念のために付け加えると、ビジュアルな効果を用い、考古学を楽しもう、といったスタンスも当然「あり」である。自分でも、それはやってみたいと思う。だがそれは、デジタルドキュメントのマインドが、どこか（他のサイトを含めて）で実現されていることを前提とする。
JavaScriptの使用は、様々な問題をひき起こす。不完全なScriptは、時として深刻な影響をユーザのマシンに与えることがある（文法上の問題、ブラウザやOSとの相性、リソースを浪費するために問題をひき起こす、等々）。JavaScriptは悪用も可能な技術であり、実際セキュリティを考えると、ブラウザでScriptを原則不使用に設定すべきとすら言える。無論、信頼できるサイトの場合は、その限りではないが、初めて訪れる場合は分らないし、確かめるためには、トラブル覚悟でチェックしなければならない... Javaも同様のことが言える... JavaScriptやJavaは、クローズドなイントラネット等で使われるべきものかもしれない。少なくとも、オープンなインターネット環境でそれらを使用することには、慎重にならざるをえない。
一般にJavaScriptは、リンクのインターフェイスを拡張する。見た目はアクティブになるが、リンクのバラエティを増すだけならば、JavaScriptを使うまでもないのではないか。情報の本質とはあまり関わりのない問題だからである。もし使う場合は、（ブラウザの）互換性を確保することと、Scriptの完成度が高いことが必須である。世の中に存在しているJavaScriptの多くは、必ずしも完成度は高くない。
ただし、特に意図があってJavaScript等を使うこと、やむを得ずブラウザ指定（主にバージョン）を表明することを、必ずしも否定するものではない。確かにダイナミックHTMLは威力があるし、魅力的である（必要なら、ブラウザの自動認識と自動分岐を行えばよい）。高度な機能を実現するために、（例えば）Windows専用のカスタムアプリケーションやランタイムをインストールさせるよりは、エレガントだからである。同様の理由で、Javaを用いる場合もあるかもしれない（その場合でも出来ればJavaのバージョンは低くしておいて欲しい…MacのJava対応は遅れているから）。
ある調査では、ユーザが待てる時間の平均は8秒だそうである（アメリカでのEコマースサイトの調査）。平均伝送速度が2KB／秒だと16KB、3KB／秒でも24KBにすぎない。こうしてみると、少なくともトップページ（インデックスページ）はかなり軽いページにしておくべきだということが分る。
トップページは、原則としてデフォールトでアクセスできるファイル名にすべきである。一般にindex.html、index.htm、default.html、default.htm（の順で優先）である（サーバにより異なる）。トップページには、サイトの基本的なコンセプトを明記し、内容もできる限り詳細に目次を提示して、パッと分りやすくすべきである。そして、通常のモニタ（せめてXGA）でスクロールしないで表示可能な程度か、1回スクロールして見渡せる程度の量にすべきである。トップページにでかい写真を貼付けるのは、アウトオブデイトの流儀である（HTMLとイメージの合計が、8秒以内で表示できることを祈りたい....）。
なお一般論として（どのページであれ）画像を貼る場合は、出来る限りピクセルサイズを考え（必要最小限に）、写真画像ならJPEGの高圧縮（例えばPhotoshopでは0～1）、同一色を広い面積で使うような模式的な絵柄の画像（アンチエイリアスをかける場合もあるが）はGIFにすべきである。また、画像のIMGエレメントには、アトリビュートとしてALTが必須であり、WIDTHとHEIGHTも事実上の必須である。WIDTHとHEIGHTは画像のサイズを確保する。これらのアトリビュートが揃っていないと、画像データが届いてから表示場所を用意しなおすことになり、画面表示がおおいに乱れる。ALTは画像の表示前（データが届く前）ないし画像を表示しない場合に、画像のあるべき位置に表示されるテキストである。
一番問題なのは、リンクのインデックスに画像を用いながら、ALT文が用意されていない場合である。画像がなかなか来ないから伝送を停止しても、ALT文がないので内容が分らない。そもそもテキストで済むインデックスは、できる限り画像ではなく、テキストを用いるべきなのだが...
こうした注意事項は、常識かというと、そうでもない（常識となって欲しい...）。HTML4.0から、ALTが必須というのは事実なのだが...
総合的な意味で、セキュリティの問題は重要である。特にインターネットの場合、IPアドレス、ソフト環境、はてはハード環境から、ユーザの各種個人情報まで、多様な手段を組み合わせることで、入手可能である。特定のユーザが、どういう閲覧行動をとったかを、逐一追跡することも可能である。そうした記録は、ユーザの意思に関わりないところで行われる（行いうる）。いかにそれが技術的に可能なことだとしても、そうした他者の存在や行動に関わる情報は、個人情報に他ならない。個人情報は、本人の了解なしに公開してはいけない（というか、公開する必要が無いことだと思われる）。
通常、技術的に入手可能な、ユーザの各種個人情報は、サイトの管理者が厳重に管理し、外部に漏らすべきではない。その前提がなければ、信頼関係が成立しない。これは、マナーの問題である。
では、公開可能な個人情報はどこまでなのだろうか。文献のデータベースを考えると、書誌情報（ただし著作権者の制作による要旨は除く）は、自由に公開してよいようである。書誌情報の中で執筆者名を掲載することは、許容されると考えられる。無論、この場合の文献とは、一般に公開された出版物に限られる（当然、一般公開を前提としない出版物は除かれる）。
なお、FORMでメッセージをサーバに送る場合に、住所などの個人情報の記入欄があるのに、セキュリティがかかってない場合があるから、注意したい。こうした場合は、メールアドレスの記入が（個人情報開示の）限界だと思う。またページではセキュリティがかかっていても、そのメッセージが、サーバから一般のメールとしてウェブマスターに送られる場合もあるらしい。そういう杜撰なサイトかどうかは、雰囲気で判断するしかない。
ビレッジセンターHTML＆SGML研究チーム 1998『正しいHTML4.0リファレンス＆作法』ビレッジセンター出版局. 1200円（本体）. ISBN4-89436-111-6.