2017年10月15日バックアップの旧・時代おくれです現行サイトはこちら

（5）：記述全般の留意点

2003年7月18日作成／2003年12月22日更新／1加筆

具体的な記述に入る前に全般的留意点、禁止自粛事項などをまとめます。ここでも循環参照が起こっていて、ある機能が『嫌いだから使用しない＝対策は困難だが不要』なのか、『対策不能だから嫌い＝使用しない』のか、本人にも判らなくなっています(*_*)？

テキストエディタの使用

HTML専用エディタは、無意味なタグを大量に挿入しソースを肥大化させる傾向があり、挿入量は価格に比例する様です(^_^;)。その無意味な激重ページは、エディタ開発時の最新ブラウザ（勧告）しか考慮しておらず、アクセシビリティ（バリアフリー）に対する配慮も概して不足しており、しかも、間違っている事もあると言うオマケ付です。

その点、タグ挿入型のエディタは高価な専用エディタに比べれば遥かにマシですが、やはり、間違った記述をする場合が有り、最終的に通常のテキストエディタで確認と修正が必要になります。

テキストエディタで直接記述すれば、確実に自分の望むソースが手に入ります。そもそも、オマケのメモ帳でも可能なことを高価な専用エディタで行うのは、私のプライドと財布が許しません(^_^;)。英米人がテキストエディタで英文ソースを書く場合に比べ、半角のマークアップと全角の本文が一目で判別できる日本語は非常に楽です。様々な処理の障害となり手を焼く『全角日本語』ですが、このメリットは存分に活用しましょう。

なお、WordやExcelなどに『HTML形式で保存』と言う取って付けたような機能がありますが、本当に取って付けたような『最悪のHTML』を生成します。これだけは使用しない方が良いと思います。

iso-2022-jpによる提供（暫定）

WindowsマシンやMacで普通に記述するとShift_JIS（MS漢字）になります。私も普通にShift_JISで記述していますが、Shift_JISが定義されていないNN2の文字化けを防ぎ、かつ、半角カナを排除するためiso-2022-jpに変換して提供します。

半角カナ？そんな規格はこの世に存在しない、文字サイズや表示幅は規格化されていない！と言われても・・・全角、半角、倍角、（松の必殺ワザ、1／4倍角！）と言う表現がDOS版ワープロ世代には解り易いんです(^^ゞ。

NN2がiso-2022-jp（いわゆるJIS）以外のエンコードができない訳ではありません。Shift_JISやeuc-jpのソースも表示できますが、NN2ではcharsetが独自拡張コードx-sjisやx-euc-jpとして定義されているため、正しくShift_JISやeuc-jpを指定するとエンコードに失敗し文字化けを起こします。charsetにx-sjisやx-euc-jpを指定、または省略すれば表示できるようになりますが、HTMLとしての妥当性を欠いてしまいます。その点、より古い規格であるiso-2022-jpの場合にはNN2を含む多くの（全ての？）ブラウザが対応しており、HTMLの妥当性も損ないません。

Shift_JISが正式に定義され浸透した現在、iso-2022-jpを用いる以前のような圧倒的メリットは見当たりません。強いてあげればメールとニュースでサーバークラッシュなどの重大な障害の原因になる（なった？）と言われる、インターネットの嫌われ者・半角カナが駆逐される程度です。Webとの関係はよくわかりませんが、元々規格上使用可能なので影響なさそうです。

しかし、深刻なデメリットも見当たりません。現時点で思い付くのは、私の手間がチョット増える(^_^;)、圧倒的多数を占めるWindows＋IE環境でソースが読み難くなる程度です。なお、NNの専用ソースビューワは『文字コードを変換して表示』する事が可能です。編集できない役立たず、素直にメモ帳を呼び出せ！と、思っていたのですが、Netscape社にもそれなりの目的（思想）があったようです(^^ゞ。

もともと好きでない見苦しい（有害かもしれない）半角カナが駆除され、ついでにNN2でも閲覧可能になる、マニアックな匂いがして大変良い (^o^)、と言う事で私が飽きるか深刻な障害を確認するまでは『半角カナ駆除』も兼ねて、iso-2022-jpを（暫定）採用します。なお、コード変換には莎華さんの『ime漢字コード変換プログラム』を使用していますが、半角→全角変換機能もあり、一部の顔文字に含まれる半角カナも順次全角カナに変換・駆除される運命です。

HTML本文と同様に外部CSSファイルも、ファイルの先頭で@charset "iso-2022-jp";のように宣言します。しかし、半角英数に日本語問題はありませんからすべて半角英数で構成されたCSSの場合、@charsetは有っても無くても（間違っていても！）関係ありません。さらに、@charset行が存在するとIE3でその直後の設定が無効になってしまいますから、その必要の無い半角英数のみで構成されたCSSには記述しません。IE3で都合の悪い設定を飛ばすのに有効では有りますが、まさに『バグを突く裏技』でしょう（自主規制対象項目 (^^ゞ）。

XHTML的記述

XHTMLへの移行を拒否している私ではありますが、あくまでも暫定的な対応であって何時かはXHTMLに移行します。その時に備え先取り可能な記述方法、要素や属性の名前と値は小文字、属性は""で囲む、終了タグを省略しない、タグは対応する順番に閉じる、色はRGB値で指定する、区切り線<hr>は内容の区切りと一致させる、などは採用します。今から習慣付ける意味と、将来（『時代おくれ』が生き残っていたら ^_^;）、ソースを書き直す場合の労力を節減できます。

HTML4.0ではをのように閉じてもルール違反ではないようですが、XHTMLでは対応する順番に内側からで閉じなければならない様です。また<hr>は内容の区切りとして処理する、と（私には）読める部分があるので、修飾目的の使用は避けたほうが良さそうです。

ソースの改行

私はソースを読み易くするために全角40～50文字程度で改行したり、半角スペースの挿入でテーブルやリストの字下げなどしています。両方とも表示には（規則上は）反映されませんが、僅かですが確実にソースのサイズを増大させます。全ての改行コードと半角スペースを除去すればソースの軽量化が図れますが、現時点ではそこまで頑張る気はありません（将来、病状が悪化したら判りませんが ^_^;）。

ソース中の改行は表示に影響しない事になっていますが、ほとんどのブラウザで半角と半角、半角と全角の境目で改行すると（非常に微妙ですが）隙間ができます。この原因は、半角文字には欧文の禁則処理を適用する、欧文では単語中の改行は行わない、従って、改行された行末の文字と次の行頭の文字は別々の単語であるから隙間をあける、と言う事のようです。

画面上の表示体裁としてはほとんど気になりませんし、実際の処理手順もわかりませんが、音声ブラウザや自動文書処理で一連の文章や単語を切って処理されたら嫌なので、改行位置を調整し隙間を潰しています。

句読点の統一

最近は日本語でも『、点』や『。丸』でなく、『，カンマ』や『．ピリオド』の使用が目立って来ましたが、カンマやピリオドを日本語のHTML本文で使用すると、IBMホームページリーダーが音節・文脈の区切りに失敗し不自然な読み上げをします。

その他の自動文書処理への影響も考えられるので、点と丸に統一します。

機種依存文字の禁止

パソコンには罫線・特殊記号を中心に機種やOSによって、表示できない文字がありますが、そのような閲覧の障壁となる機種依存文字はもちろん使用禁止です。以下の文字に機種依存性を確認しています。広く流布しているリストとは大分異なりますが、自分の確認結果を優先しました（なぜか98x1で罫線が表示されず、逆にMacintoshで正しく表示される・・・ ^_^;）。

PC-98x1のDOS環境で表示されない（PC-9801BX、PC-9821Neで確認）: ∧ ∨ ￢ ⇒ ⇔ ∀ ∃ ∠ ⊥ ⌒ ∂ ∇ ≡ ≒ ≪ ≫ √ ∽ ∝ ∵ ∫ ∬ Å ‰ ♯ ♭ ♪ † ‡ ¶ ◯ ─ │ ┌ ┐ ┘ └ ├ ┬ ┤ ┴ ┼ ━ ┃ ┏ ┓ ┛ ┗ ┣ ┳ ┫ ┻ ╋ ┠ ┯ ┨ ┷ ┿ ┝ ┰ ┥ ┸ ╂ ≡ ∫ √ ⊥ ∠ ∵ ∩ ∪
Macintoshで表示されない（Performa6260で確認）: ㍉㌔㌢㍍㌘㌧㌃㌶㍑㍗㌍㌦㌣㌫㍊㌻㎜㎝㎞㎎㎏㏄㎡〝〟 № ㏍ ℡ ㊤㊥㊦㊧㊨㈱㈲㈹㍾㍽㍼㍻
Macintoshで文字化けする（Performa6260で確認）: ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ Ⅵ Ⅶ Ⅷ Ⅸ Ⅹ ∮ ∑ ∟ ⊿

PC-98x1の場合はWindows環境、3.1、9x共にこれらの文字は表示可能なので特に気にする必要はなさそうです（ネットに繋がっている98DOSは超レアなはず）。また、Macintoshで表示されないグループはほとんどが単位記号など略号ですから、普通に文字で記述すれば用は足ります。

問題は文字化けグループの丸付き数字とローマ数字です。階層を持った序列を表すのに便利で日常的な使用頻度も高いのですが、Macintoshでは（i-Macなどでも！）化けます。ローマ数字の代用としてアルファベットのI、VとXで代用する方法があり、私もたまに使います(^_^;)が、見せ掛けであり、序列を持った数字として自動文書処理の対象になるわけもなく、音声ブラウザ利用者に『エックス・アイ・ブイ』を14と思えと言うのも無理な相談です。固有名詞の場合はともかく、序列を表す場合は、通常の数字に置き換えるのが確実です。

一部で文字実体参照を用いれば環境に関わらず表示できる、と言われていますが迷信です。実際には環境によって正しく表示できない文字が多数存在し、残念ながら丸付き数字とローマ数字も多くの環境で文字化けが起こります。手間隙掛けて問題をさらに複雑にしてしまいますから、表示可否が不明な文字の実体参照は控えます。

以上はPC/AT互換機（≒Windows）ユーザーの立場ですが、Macintosh文字やX68000文字などの逆にPC/AT互換機で表示できない文字もあります。すべてを把握するのは困難ですが、W3CのValidationサービスで機種依存文字（の一部？）はチェックされますから、Validationサービスを受けておけばある程度は回避可能です。

フレームの禁止

フレームが本当に必要な状況、フレーム無しでは実現できない状況は、複数サイトの応答結果を１ページに表示する場合など、極々まれですが、なぜかWeb上にはフレームが氾濫しています。フレームが存在すると、小型モニターでは実効画面が狭くなる、音声ブラウザでは閲覧の障害となり、移動ボタンと実際の画面が異なるフレームの場合は閲覧（移動）不可能です。フレームで提供されるナビゲーションバーやサイトマップのメリットを打ち消すに十分な害があります。

フレームはハイレベルな処理にのみ使用する、と言うことでたいした事をしない『時代おくれ』では、事実上の使用禁止です。なお、フレーム非対応のブラウザの存在を、短絡的に禁止の根拠とはしません。メリットを遥かに上回るデメリットが禁止の根拠です。

クリッカブルマップと類似物の禁止

クリッカブルマップは見た目にもよく、平面的位置関係を視覚に効率良く訴える事が可能です。逆にいえばクリッカブルマップは非グラフィカルブラウザの場合はかなり利用の難しい無意味なコンテンツであり、同等の別ページは必須です。

しかし、私はベタテキストページを併置して『配慮した！』とは言いたくありません。別ページの安易な設置は、実際には同等でない別ページを免罪符にしてしまう可能性があります。同等の別ページが本当に元ページと同等の価値・使いやすさ・分りやすさを有するのであれば、それを共通ページとすれば、クリッカブルマップと類似物は必要ありません、禁止です。何度も繰り返すように『時代おくれ』では別ページは作りません（共通ページでどこまで出来るかの実験なんですから ^_^;）。

しかし正直言って、この項目に関してW3Cは綺麗事を並べたような気がします。クリッカブルマップなみの利便性を持ち『テキストベースで平面的位置関係を表すリンク』ってどんなもの、想像できません(*_*)？

JavaScriptの自粛

JavaScriptには、音声ブラウザでの使用が極めて困難と言う致命的欠点があります。多くの解説サイトで困難と表現されていますが、私の体験では『極めて困難』です。ページの移動を（必要も無いのに）JavaScriptで行われると、音声ブラウザは先に進む事すらできません！

さらに、JavaScriptが実現するページの修飾、無意味な動きは多くの場合、好ましいものではありません。重要な情報を強調する目的でスクロールさせると、ブラウザや閲覧者の状況によって読めない場合があり、逆に情報が伝わらなくなります。ステータスバーにメッセージを流すと閲覧者はページに関する情報を１つ失ってしまいます。リンク先が目的の次ページなのか、悪質な接続ソフトのダウンロードなのか判断できなくて大変困ります(^^ゞ。

『時代おくれ』ではブラウザの振り分けや閲覧者の補助などJavaScriptは『閲覧者側に十分なメリット』があり、かつ、他の手段で実現不可能な場合に限定し、装飾目的使用は禁止とします。まあ、勉強不足でほとんど使えないので、この項目は大勢に影響ありませんが(^_^;)。

新しいブラウザが使用できない低スペック旧型機で、IE3ではなくNN2や3が使用されるのは単に軽いと言うだけではなく、JavaScriptへの対応も要因だと思います。私も最初はIE3を使用していましたが、Dionの掲示板がめくれない（次ページの存在すら判らない）ため、NN3に乗り換えました。もっとも、Operaの日本語対応によって、その存在意義もだいぶ薄れています。

Cookieの禁止

Cookie（クッキー）は重大な認証や個別情報提供を行ないたい場合には有効ですが、閲覧者側はCookie受入の為に確実にリスクを負います。単純に閲覧させる場合はまったく無意味であり、訪問の有無・回数によるメッセージやページの振り分け程度のメリットで閲覧者を危険にさらすのは考え物です。

本人が言うから間違いありません、ここ『時代おくれ』に閲覧者のリスクに見合う内容は絶対に有りませんから、論外、Cookieは全面禁止です！

最近は単純な閲覧であるにも関らずCookieを使用する公共サイトがありますが、閲覧者＝納税者を監視して身元調査でも行なっているのでしょうか？怖くて閲覧できません(‾_‾;)

プラグインの不使用

Shockwave Flash、Java（JavaScriptとは別物）、Adobe PDF、RealPlayerなど表示閲覧するのにプラグインが必用なコンテンツがあります。各ブラウザのデフォルト状態での対応状況はまちまちで、インストールされている他のソフトも影響し、さらにセキュリティ上の問題でプラグインを使用不可にしている場合も有ります。

最終的に閲覧可否はパソコン個別の環境で決まりますが、マクロメディア社は自社製Shockwave Flashの再生可能率は98.4％、ユーザー数で5億1,600万に達している（2003年3月）と発表していますが、少なくとも我が家にも職場にもマクロメディア社の調査員は来ていません（調査員を見かけたと言う噂もなく、私の周辺の状況を見る限り信じ難い数字です）。比率はともかく、プラグインの存在と使用を前提にコンテンツを提供すると、情報が伝わらない環境が確実に存在します。

さらに、正常に表示できたとしても、要プラグインコンテンツの多くは新しいマルチメディア系コンテンツであり、ほとんどが音声ブラウザでは利用困難です。

特に通常のWebページと根本的に構造が異なるFlashは音声ブラウザでは利用が難しく、 最近増えてきたAll Flashサイトの場合には完全に意味不明 です。トップページがAll Flashでスキップする方法も代替ページも用意されていない場合、音声ブラウザに限らず非対応環境では真白なページを眺めるしかありません。せめてもの救いは検索エンジンが拾っていかない事ですが、Web本来の目的、情報の共有と言う意味ではそれも問題です。

また、文字種とサイズを含めて完全に再現可能で、かつ（ツールさえあればHTML版よりも）作成が簡便なPDFで提供される文書も増加傾向にあります。Flashは個人や企業の（ハッタリ）サイトで多用される傾向が強く、ある意味困りません。しかし、その特性が災いしたのかPDFは正確さの求められる行政関係など重要な文書に多く見られますが、Adobe Acrobat Readerが無ければ表示不可能、表示できても音声ブラウザではほぼ利用不可能です。HTML版も併せて提供する必要がありますが、HTML版作成の手間を嫌ってPDFを採用している場合（私には多くの省庁がそう見えますが）、HTML版は提供されません。

個人的感想として、閲覧ツールを無償で配布しておいて高価な作成ツールを売りつける商法は嫌いです。また、PDFを閲覧可能にするには、Adobe Acrobat Readerをダウンロードしてインストールする必要がありますが、パソコンに詳しくない閲覧者には十分な障壁です。

マルチメディアコンテンツの標準化は（W3Cでも）進んでおらず、現時点では単に各企業の製品にすぎませんから可否の判断はしませんが、『時代おくれ』ではマルチメディアコンテンツを提供する意思も才能もありませんから、自動的にプラグインは不使用となります。

←前

次→

↑目次

表紙に戻る