2017年10月15日バックアップの旧・時代おくれです 現行サイトはこちら
|
|
（7b）：『時代おくれ』的記述の根拠 |
2003年7月18日作成／2003年12月22日更新／2加筆／1追加 |
|
（7a）の続きです。分割点に意味 はありません、適当に分割されています。 |
| |
|
<title>は文字道理ページのタイトルですが、グラフィカルブラウザではキャプ ションバーのお飾り程度の扱いで、自分もほとんど読みません(^^ゞ。そのため軽視され、 省略、アバウト、全ページ共通、ときに『一行メッセージ』的目的外使用がみられます。 しかし、現在のブラウザの解釈がおかしいのであって、あくまでも<title>はページ のタイトルです。 <title>の記述は音声ブラウザではペー ジ移動・内容確認の手掛かりとなり、検索エンジンはこれを重要キーワードとして処理し ている可能性があります。『時代おくれ』も<title>の単語でヒット した場合、上位で表示される傾向があります。外国の検索エンジンにも配慮した英文タイ トルが良いと言う意見もありますが、日本語での検索が優先、日本人が音声ブラウザで困 る、の2点から不採用です。<title>に はきちんとページの内容を反映した正しい、固有のタイトルを記述する事が、 提供側・閲覧側双方のメリットになります。だからと言って<title>に撒餌（検索用 の変なキーワードの羅列）をしない様に(^_^;) その一方で、タイトルはページの先頭にもでっかく表示したい ので、<title>タグとほぼ同じ文言を表示用 のタイトルとして<h1>でページの先頭に表示しています。<h1>が ページ毎に１回しか使えない、音声ブラウザで２回聞くことになるなど若干の不都合はあ りますが、記述規則上の問題はありません。我ながら名案、カシコイと思ったのですがW3Cの Tip Of The DayにUse h1 for title!とありました、誰でも思いつくようです(^_^;)。 |
| |
|
CSSではなく<body>タグのオプションで ページの基本配色を指定します。もちろん非推奨です(^_^;)。配色の方針は 『HTML研究所（4）：基本レイアウト』に示してあります。 CSSで指定すると（ユーザーが独自に設定していない場合）非対応ブラウザではそこそ こ無難な万人向けのデフォルト配色が適用されますが、『時代おくれ』的感覚ではコント ラストが足りません。<body>タグやCSSで基本色を指定しても、知識のあるCSS対応 ブラウザ使用者は配色に限らず好みの体裁で自由に閲覧可能です から、変更できないブラウザ、変更できない閲覧 者を優先して、ハイコントラストを画面配色のデフォルトにすると言うことです。 なお、NN1と2およびIE3は文書指定の配色を変更する事ができませんが、NN3と4はある 程度変更可能、Operaを含め以降のブラウザではユーザーサイドCSSが指定できます。テキ ストブラウザw3mでは配色はユーザー側で指定であり、また、この問題は音声ブラウザに は無関係です。 工事現場の警告板を見ても解る様に、黒に黄色は目立つ、目立ちすぎる組合せです。 使わないのは勿体無いが使いすぎも問題だ、と言うことで黄色を頻度が低く普通は単語単 位で使用されるリンクに割り当てました。しかし、現実的問題としてたった16色からリン クに（黒背景で）目立つ複数色を割り当てるのは得策では無く、未表示に目立つ色を、表 示済みに残りの目立たない色を使用すると『1回見たら隠し文字』になってしまいます。 それよりはリンクを目立つ色で統一したほうが よいと判断し、未表示、表示中と表示済みリンクに共通の黄色を使用してい ます。決して、迷子になった閲覧者がいつまでもサイト内をうろつく様に、と言う姑息な 考えではありません(^^ゞ。 以前、HTML作成研修である受講者が『わかりました！』、と 『背景黒、基本文字色黄色』の組合せを選びました。確かに視認性は高いのですが暑苦し く異様な圧迫感があり、しばらく読んでいると目がチカチカ・・・私の説明が拙かったの か、その方の感性が特殊だったのか(^_^;)。 |
| |
|
単に要素を画面中央に配置する単純なタグで、『時代おくれ』では<table>をペ ージ中央に表示させるのに使用しています。非推奨である事を除けば(^_^;)特に問題のな い、どのブラウザでも安心して使用できるタグ・・・だったのですが、IE6とOpera7が標 準モードでの処理に失敗するので、ドキュメント タイプ典拠を省略して意識的に後方互換モードにしてから使用しています。 なお、Opera7最新ビルドでは改善されていると言う情報が有ります。 |
| ||
|
本文中のマークアップ記号は文字実体参 照で<＝<＝<、>＝>＝> および&＝&＝&として表示します。文字実体参照 は『&』で開始、『;』で終了、その間に定義された実体名または文字コードを記述し ますが、この3文字の実体名はそれぞれlt＝less-than sign、gt＝greater-than signおよ びamp＝ampersandの省略形、コードは単なる10進文字コードです。 なお、『" ダブルクォーテーション』も制御記号ですが、参照しなくても正常に表示 され、W3CのValidationサービスでもOKなので（私は ^_^;）そのままとします。 カットアンドペーストしたURIがW3CのValidationサービスで引っ掛かる、あるいは文 字化けを起こす場合、URIに&が含まれていますから、&を&または&に 置きかえる必要があります（DionのCGI利用解説は間違っていますネ ^_^;）。実体参照終 了を示す『;』を忘れた、あるいは『; セミコロン』と『: コロン』を間違えた場合で もIEは表示可能ですが、より厳格なブラウザでは表示できませんから要注意、表示できて も間違いは『間違い』です。 この3文字は、コード・実体名どちらで参照してもほぼ全てのブラウザで表示可能で すが、NN1〜4には解釈できない実体名があり ますから、コード参照が安全です。しかし、コード参照であっても、 その他のギリシャ文字、ラテン文字や特殊記号のなかには、環境によって正しく表示され ない文字が多数含まれているので、表示確認ができない場合は使用しない方が安全です。 しかし・・・マークアップ記号はともかく、その他の文字はこんな面倒な方法で表示 しなくても、日本人の強い味方、全角文字（記号）を使用するのが楽チンではないかと思 われます・・・(^_^;)。 |
| |||
|
ほぼ全てのブラウザが表<table>の色と 背景画を除く基本的表組に対応しており、可読性が損なわれることは滅多 にありません。数少ない非対応ブラウザのIE1〜2は本当に意味不明、グジャグジャな整形 を行ないます。でも大丈夫、『時代おくれ』の対象ブラウザからは除外済み(^_^;)です。 表の整形に関して、セル結合<colspan、rowspan>、表の大きさ<width="%または絶対値">、 罫線の影幅<border>、罫線の太さ<cellspacing>、見出し項目<th>、 セル内横位置<align="left、centerまたはright">、セル内縦位置<valign="top、middleま たはbottom">、キャプション<caption>などが（たぶん ^_^;）strictで、さらに 非推奨ながらセル幅<width="%または絶対値">とセル内改行禁止<nowrap>な どが認められています。 キャプションとセル内の項目の修飾も認められていますから、<table>を使用 するとかなり自由なレイアウト（修飾）が可能です。しかし、<table>使用時は常 に線形化の可否を意識する必要があり、ブラウザごとに部分的非対応やバグが存在するた め必ずしも（自分の意図した）共通の表示が得られるわけでもありません。また、セル幅 指定とセル内改行禁止が非推奨になっているのは、『画面を固定するな』と言うW3Cの意思 の表れではないかと思います。レイアウトの凝り過ぎ、過剰な画面固定は控えましょう。 と、言いながら、Opera6ではセル内横位置 の行単位一括指定<tr align="">は文字にのみ有効なので、各ペー ジの上下に有る『ナビバーもどき』のような入れ子にした<table>の位置 は<td align="">でセル毎に指定して固定しています(^^ゞ。 セル幅はブラウザの文字サイズ設定も関わってくるので、可能な限りブラウザに任せ るべきで、通常は各セルの内容・文字数に応じて適当に程よく分配されます。しかし、表 整形のツボにはまり内容と無関係にセル幅を分配、その結果、非常に読み辛くなる場合 があります。この障害は、個別セルの幅の割合が決らないと全体の幅が決められない、全体の 幅が決らないと個別セルの割合が決められない、と言う循環参照の収束失敗が原因らしく 横結合セルを含む表で（特にNN4で？）起こり易いようです。 画面の絶対値固定は避けたいのですが、ページ幅＝表の幅を絶対値固定している『時 代おくれスタイル』では個別セルは相対値でも絶対値でも結果は同じです。毒を食らわば ・・・と言うことで、すべて絶対値指定して循環参照を止める＝ブラウザに考えさせない 事で多くの場合改善可能です（本当に“善”かどうかは各自で判断 ^_^;）。なお、全体 の幅を固定したための障害とも考えられますが、であれば、簡単に表が画面サイズに達す る低解像度小型モニタの場合には避けられない問題です。 さらに、本物のドツボにはまるとセル幅の 指定も無視されますが、その場合は表の先頭をすべて非結合＆絶対値指 定にする事でドツボから脱出できる事があります。 | |||
| width="145" | width="145" | width="145" | width="145" |
非結合行を先頭に置く事で整形のツ ボにはまり難くなります。逆に言えば結合行を先頭 に置くな！です。もちろん、均等である必要はありません。 | |||
ただし『驚くほど変な整形の回避が できる』のであって、多くの場合分配は不正確なままです。 | |||
罫線が太く見える部 分が実は2行目ですべて空欄にすれば“ほぼ”非表 示にできます。 | |||
なお、表の横結合は通常は表の線形 化の可否に影響しません。 |
|||
|
あくまでも『ドツボ脱出の緊急避難』であって、逆に状況を悪化させる場合もありま すから『取敢えず書いときゃ安心』 と言うことは絶対にありません。表整形の基 本はブラウザ任せで、矯正が必要な障害を確認した場合のみ指定するも のです。幸いにも？ツボにはまった場合、セル幅の指定は大小関係を表す程度の意味しか 持たず各整形エンジンの癖も違うので、指定値の決定はトライアンドエラーとなりますか ら、余りにも面倒で緊急時以外使う気になりません(^^ゞ。 ある特定セルの幅＝ある文字列の折返しが気に入らない、『バカ野郎、１文字だけ改 行するな！』と言う場合、<nowrap>で修正できます。しかし、それで都合が良くな るのは作成者と同じフォントサイズの場合だけであって、環境によって都合が悪くなる事 もあればフォント設定があるサイズを超えると確実に障害の原因となります。プログラム ソースなど同一行に意味がある場合を除き使用しないほうがよいと思います、が、思わず 使ってしまう・・・(^_^;)。 NN7の標準モードを除き、表中に空欄セルが存在すると罫線（セル自身？）が表示され ず一部が欠けた表になりますが、非常に見苦しく私は大嫌いです。以前は全角スペースを 挿入して表示させていましたが、全角スペースも『文字情報』ですか ら、空欄セル対策は、（おそらく）情報としても 構造としても意味を持たない<br>の挿入に切り替えました。 | |||||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||||
| |
|
NN1と2では<table>の背景色が指定 できず、NN3と4では背景色を指定しても罫線部分に色が着きません。そ の為、全体と個別セルで違う色を指定し、<border="0">で影を消した『擬似色付き 罫線』の表示に問題を生じます。ページ背景色とセル背景色が異なる場合、NN3と4ではバ ラバラのパネルを並べたような表になり、背景色が指定できないNN1と2では表の意味がな くなります。ページ背景色とセル背景色が同じ場合は、NN1〜4で表の意味がなくなり ます。罫線が必要な<table>の場合 は、<border="1以上">を指定する必要があります。 |
悪い見本です |
セル背景とページ背景が同色のこの例では、NN1〜4で罫線が表示されず表の意味がありません | |
私はこの影無し細線が、大好きだったのですが自粛です・・・『みんなネスケが悪いんや！』 | ||
| しかも、通常の設定では印刷されない！ | 諦めましょう(T_T) | |
|
なお、NN7は罫線部分に色が着きますが、なぜか体裁が悪く視認性が良くない様に感じ ます。私には左側と上側の罫線が右側と下側より細く見えるのですが、気のせいでしょうか？ テーブル（セル）背景色とページ背景色のコントラストを利用すると、アイキャッチ 効果が得られます。古いブラウザを対象とし画像も控えたページでは、画面を陰鬱にしな い効果もあり『時代おくれ』ではページタイトルと項目タイトルに使用しています。背景 画を利用する事もできますが、背景画には問題もあり基本は背景色 です（『画像／<style="url(背景画)">』参照）。 ページ背景色が黒の場合、テーブル背景色白に文字色赤や黒を指定すると抜群のアイ キャッチャーとなります。その場合、NN1は背景色・文字色ともに非対応であるため、ペ ージ背景色と標準文字色がそのまま適用され問題ありません が、NN2では文字色のみ指定可能であるため、 文字背景色のコントラストが失われる可能性があります。当然、背景画 使用時の鉄則、背景画の表示可否に関わらず重ねた文字や画像とコントラストが得られる ように『背景画と同系の背景色を指定する』も、文字色指定可、テーブル背景色指定不可、 背景画表示不可と言うNN2では無効です。 NN2対応を優先する場合は、文字色は常に標準文字色を使用し、その標準文字色とコン トラストが得られる範囲でテーブル背景色を選択する、これで可読性は確保できますが、 画面は地味になります。色をより自由に使う場合 は、ページ背景色を部分的に指定する文字色に用 いない、これで少なくとも完全な隠し文字の発生だけは回避可能です。『時 代おくれ』は前者を原則採用していますが、NN2の優先率0.21％を知ってしまった今、心が 後者に傾いています（限定的使用だし、選択反転すれば読めるし・・・たとえMacユーザ ーでも怒らないよね(^^ゞ）。 最近、<table>背景色を指定するとIE3で はキャプションにも背景色がついてしまうことに気が付いてしまいました。 ページ背景色を前提とするキャプションが隠し文字になってしまう可能性があります。現 在、対応を検討中です（しかし、IE3の優先率、切り上げて0.01％・・・^_^;）。 |
| ||
|
<img src>による画像表示にはすべての グラフィカルブラウザが表示可能なJpeg、Gif、透過Gifを使用します。 なお、NN4は同名で画像を入換えた場合、 新しい画像を読まずにキャッシュを表示し続けることがあります。タイ ムスタンプやサイズの違いも無視しますから、要注意、日代わり画像など恒常的に入れか える画像はファイル名を月日や連番などで一意的に付直す必要があります。 新しい画像形式であるPngをNN1〜3とIE3は 表示できません。米ユニシス社の特許問題でGifが嫌われPngが推奨され ていますが、旧版ブラウザの対応状況ではGifにメリットがあります。Windows付属のペイ ントでも作成（変換）可能であり、放っておけば特許も切れます(^^ゞ。 しかし、透過でもアニメーションでもない通常画像でGifを使用する必然性が判りませ ん。Gifファイルの方が小さくなるのは極端に色数の少ないベタ塗りの（理屈的に横方向 に）単調なイラストの場合のみであり、自然画を含む通常のカラー画像ではGifにサイズ 的メリットはありません。はっきり言ってユニシスに金払ってま で使用する値打ちは有りません。 |
| full | 256色 | 128色 | 64色 | 32色 | 16色 | 2色 | |
|---|---|---|---|---|---|---|---|
| Gif | 11404 | 9813 | 7734 | 6640 | 5418 | 2232 | |
| Jpeg | 4213 | 4204 | 4540 | 4747 | 5610 | 6916 | 5050 |
 |
左が比較に使用した画像。オリジナル のBitmapを多摩川源 五郎氏作成のPadieで減色し、Windows98付属のペイントでGifおよびJpeg（推定圧縮 比75）に変換。 | ||||||
|
付属のペイントではなく高価な変換ツールを使用した場合、結果が変わるのかもしれ ませんが、貧乏な『時代おくれ』ではそう言う事は起こらないので(^_^;)Jpegの欠点を見 つけるか、Gifに重大なメリットを発見しない 限り、通常のカラー画像にはJpegを優先的に 使用します。 こんな常識をなぜ力説しているのかと思われた方、私は1999年以来、Jpegが表示でき ないブラウザがあると信じ、すべてGifに統一してきました。なぜそう思いこんでいたの か、今となっては謎ですが、確かなことは時間と労力と画質を浪費したと言うことです(^_^;)。 大勢の人にJpegは使うなといった記憶があります。『Jpegが表示できないグラフィカルブ ラウザは存在しません』、ウソをついていましたm(__)m。 画像は減色して軽量化せよ、と言う耳タコな警告がありますが、上の結果を見る限 りJpegには当てはまらず、Jpegの場合、減色した256色とフルカラーでもサイズに大差あ りません（なぜか？256色が大きい事もあります）。VGA環境に配慮して256色以下にせよ、 と言う警告も、実際にはブラウザが環境に応じて減色表示するので疑問です。減色の根拠 がなければ『フルカラーJpegを使うべし！』なのですが、大ボケ、見落としに保険をかけ ます（誰も信じるな、何も信じるな、特に自分は信じるな ^_^;）。幸いな事にモニタ上 で256色とフルカラーは見分けがつかない ので、Jpegは256色に減色し、圧縮比50〜75％とし て軽量化を図るとします。 アニメーションGifはすべてのブラウザで表示は可能で すが、NN1はアニメーションせず、NN2ではア ニメーションしますが読込みが終了しません。新しいブラウザでもアニ メーションを禁止している場合があります。アニメーションGifも1フレーム目で完結し た意味をもつ（アニメーションしなくても意味を持つ）ものであれば非対応環境でも情報 欠落は起きないと思いますが、画面の動きに 幻惑され集中できない閲覧者がいる、確実にCPUパワーを食いつぶすな ど別の問題もあります。 画像使用時には内容に関わる画像のalt（代替 文字）は確実に記述します。alt文字は画像のコメント文と勘違いされやす いですが、画像が表示できない場合の代替要素であり、本来同時に表示されるものではあ りません（表示してしまうIEやNNの解釈が間違っています）。画像から独立して同等の意 味を持つしっかりした代替文字を設定しないと、音声ブラウザやテキストブラウザでは意 味不明になります。逆の視点で、代替文字がないと提示の意図が伝わらない画像も問題で す。そして、一番問題なのは、alt文が必要ない内容に関わらない画像の存在かもしれま せん(^_^;)。また、altには巡回ロボットに画像情報を拾わせる効果もあります。 大変困った事にNN4＋Windows95環境でalt文 が原因で落ちると言う非常識な現象が起こります。詳しい条件は不明で すが、特定の文字ではなく文字数（全角半角の組み合わせ）の様です。現時点では実際に 表示させてみる以外に点検方法は判りませんが、全角半角を問わず１文字加除すれば解決 します。 画像のサイズを指定すると整形の回数が減り、 結果的に表示を高速にする効果が期待できます。サイズを指定した場合、画 像の読込み終了前の１回で整形が完了しますが、サイズがない場合、画像の読込み終了後 に画像サイズが確定するため（タイミングが悪いと画像の枚数回の）再整形が行われ、全 画像の読込み完了まで（落ち着いて）読むことができません。 画像と文字の位置関係をスペースと<br>で横着に調整すると起こりやすい様です が、NN1〜4で文字の回り込み処理に失敗し、画 像と文字が重なって判読不能になる場合があります。当然、レイアウト も崩れてしまいます。IE3でも画像を<p>タグ内に配置した場合に、同様の障害が起 こります。この現象はテーブルのセルで画像と文字を区画することで防ぐ事ができます （『色数と保存形式によるファイルサイズの比較』の表が実例）。 |
|
さらに（7c）に続く |
|