harunaga at depublic dot com
Last modified: Sat Sep 1 01:36:19 2001
Copyright © HARUNAGA Hirotoshi 2000-2001
widthborderをつけるときborderやmarginとfont-familyは共存できないfont-familyの問題tableborder-widthmarginline-heightの継承border-colorlist-itemwidth、ブロックにtext-alignを指定したときCSSを使うことのメリットとしては、文書作成者側のものが多いのだろうが、ユーザ側にとっても、CSSを無効にする（Netscape Navigator 4、MSIE 5以上）とか、自分用のスタイルシートで表示する（MSIE 4以上）などの自由度があり、また、CSSに（あまり）対応していない古いブラウザを使っている場合でも、<table>や<font>や「つっかえ棒」の透明GIF画像などを使って無理矢理レイアウトされた文書を読まされるよりは、よいはずだ。
しかし、CSSを使ううえでいちばんの障害になってしまうのは、NN 4.*のCSS1サポートが滅茶苦茶だということだ。NN 4のユーザが、Mozilla（Netscape 6）に移行してくれればありがたいが、それには相当な時間がかかるだろう。NN 4で@importが無効な点を利用して、NN 4ではスタイルシートを使わせないという方法もあるが、そこまでドライにもなれない。一方、MSIE 5の方も、「コア」はかなりサポートされているものの、おかしな点も少なくはない。
したがって、ここでは、CSSを使ってできるだけ構造だけの文書にしながら、NN 4を含めた古いブラウザと妥協するとりあえずの方法を、試行錯誤してみたい。当然ながら、この文書は他と同様に、しばらく経てば無用のものになるだろう。
なお「正しい」スタイルシートの記述については、上記のW3Cの勧告や、『スタイルシートWebデザイン』（すみけんたろう著、技術評論社、1998）などを参照されたい。
widthNavigator 4とWindows版 MSIE 5では、<h*>や<div>などのブロック系要素にwidthを指定すると、paddingとborderを含めたブロックの幅として設定されてしまう。Mozilla / Netscape 6 PR3とMacintosh版 MSIE 5ではCSS1勧告どおり、paddingとborderを含まない、要素の中身の幅になる。
paddingやborderが0、1px、0.1emなど小さい値であればあまり差は出ないので実害はないが、ある程度の大きさをとる場合は、Navigator 4とWindows版 MSIE 5ではブロックの表示幅が想定よりかなり狭くなってしまうことになるため、これらのブラウザでの表示を優先させるためには、widthを大きめに指定するしかない（正しい実装のブラウザでは広くなってしまうが）。
なお、Nagigator 4ではwidthをパーセント指定すると、どのような計算なのかわからないが、本来よりかなり狭く表示される。
単に、親要素の右端まで伸ばせばいい場合は、widthの指定はせずに、margin-right: 0とする。
borderをつけるときブロック系要素にborderを指定すると、Navigator 4ではborderの表示幅は「文字を表示するのに最低限必要な幅」になってしまう（ただし、ブロックの中にa要素がある場合は、左右一杯になる）。
MSIEやMozilla / Netscape 6と同様に左右一杯になるようにするには、margin-right:0と指定する必要がある。しかし、marginを指定すると、Navigator 4ではフォントサイズがデフォルトに戻ってしまう。
したがって、見出しの場合は、フォントサイズをスタイルシートで指定する必要が出て来るが、各ブラウザでの標準の<h*>の表示は、スタイルシートでは以下に当たるようだ。
| Navigator 4 / Mozilla / Netscape 6 | MSIE 5 | |
|---|---|---|
| h1 | font-size:200%; font-weight:bold | 同 |
| h2 | font-size:150%; font-weight:bold | 同 |
| h3 | font-size:120%; font-weight:bold | font-size:110%; font-weight:bold |
| h4 | font-size:100%; font-weight:bold | 同 |
いずれも、標準の<h5>や<h6>は本文よりも小さいボールド体で表示されるが、これはおかしなことなので、これらをスタイルシートで指定する場合は、それなりのサイズなりを指定すべきだろう。
もちろんパーセントやポイントやピクセルで指定すると、それに当たるサイズがない場合は、近いものが使われたり、あまり表示がきれいにならなくなったりする。また、Macintosh版 Navigator 4でOsakaフォントを使っている場合は、上の表のようにはならない（後述）。
なお、Netscape 4のfont-size:120%などは、bodyのfont-sizeに対する比率ではなく、ブラウザの初期設定のフォントサイズに対する比率になる。
また、Netscape 4ではbodyのfont-sizeを指定せずに<h1>などにborderを指定すると、pのfont-sizeが効かなくなり、ブラウザの標準フォントサイズに戻ってしまう。
borderやmarginとfont-familyは共存できないNetscape 4では、h1などのブロック要素にborderやmarginとfont-familyを同時に指定すると、ページが全く表示されなかったり、border-colorやmargin-rightが効かなくなったりする。
回避するためには、font-familyはブロックには指定せず、ブロックの中身を<span>で囲んでそれに指定するしかない。
font-familyの問題Windows版のNetscape 4では、font-familyの指定は無効になる。
IE 5では有効だが、font-familyの指定は一つのページでは一つのフォントしか使われないようで、font-family: "Times New Roman", "Times", "ＭＳ Ｐ明朝", "平成明朝", serif;としても、欧文部分はserifになるが、全角日本語部分はブラウザの初期設定のままになる。font-family: "ＭＳ Ｐ明朝", "平成明朝", "Times New Roman", "Times", serif;とすると、半角英数字を含めて全てがＭＳ Ｐ明朝になる。
UNIX（FreeBSD）版のNetscape 4では欧文と和文は区別されているから基本的にはうまくいくのだが、X-TTでWindowsのフォントを使っている場合でも"ＭＳ Ｐ明朝"などのフォント名では設定してないはずなので、やはりserifとsans-serifの区別しかできないことになる。
また、Windows版のNetscape 4でpにfont-family: "ＭＳ Ｐゴシック", "平成角ゴシック", "Arial", "Helvetica", sans-serif;と指定すると、pに指定していたline-heightが無効になってしまう。回避するためには、font-familyをpではなくbodyに指定するしかないようだ。
表をビジュアル系（笑）ブラウザがどのように表示すべきかについてはCSS1勧告では特に述べられてなく、CSS2勧告ではいろいろ書かれているが、CSS2に対応しているブラウザがほとんどなく、またレイアウト用にtableを使ったページが多い現状では、まず、メジャーなブラウザで、CSS抜きの単なるHTMLの指定でtableがどのように表示されるのかを確認する必要がある。
MSIE 5では、tableタグのcellpadding属性で何かが指定されれば、それは各tdやthに指定されているwidthの中で「詰め」られる。tdやthのwidthは、cellpaddingを含めた列の幅と解釈され、したがって、tableの幅は、各列のtd（th）に指定したwidthの合計＋border、となる。
Navigator 4では、td（th）のwidthはその中身の幅となり、tableのcellpaddingは各td（th）のwidthに付け加えられる。また、borderが1以上に指定されるとcellspacingが0であっても各セルの周りに1pxの幅がとられ（つまり、セルの間には2px空き）、したがって、tableの幅は、各列のtd（th）に指定したwidthの合計＋（tableのcellpadding×列の数×2) ＋（列の数×2）、となる。
font-sizeの絶対サイズとしてlarge、x-large、xx-largeなどが用意されているが、表示させる大きさはブラウザ依存なので、じっさい様々だ。
例えばx-largeは、Navigator 4では230％、MSIE 5では200％、Mozilla / Netscape 6では140％で表示される。CSS1勧告では一段階として「1.5倍」、CSS2勧告では「20％」を推奨しているので、Navigator 4とMozilla / Netscape 6は各々これらに準拠しているのだろう。
と思ったのだが、もうちょっと調べてみたら、Navigator 4はx-largeは27ポイント、largeは18ptの固定になっており、ブラウザの標準フォントサイズ（bodyのfont-sizeではない）を12ptにしたときに230％に当たるだけだった（Macintoshでも同様）。
MSIE 5の方は、上記に加えてlargeが150％だが、文字のサイズを標準の「中」（＝96dpiでの12ポイント。Mac IE 5では16ピクセル、96dpi、100%）から変えると、少し比率がズレることがある。また、なぜかmediumが、Windows版では110％、Mac版では120％で表示される（無指定より一段階大きいサイズで表示されているようだ）。
いずれにせよ、絶対サイズは、OSとブラウザの種類やユーザ側の設定によって大幅に異なった結果にしかならず、サイズ指定としては使いにくいので、やはりパーセントで指定した方がよいことになる。
なお、Mac版のNavigator 4でOsakaフォントを使っている場合は、font-sizeのパーセント指定は本来より少しずつ大きく表示されるという、おかしなことが起こる（後述）。
width、ブロックにtext-alignを指定したときいわゆる半角英字を全角幅で表示させようとして、span.zen{width:1em}などと指定し、それが含まれるブロックをtext-align:centerとか<div align="center">などすると、Netscape 4.7(2)では、改行されて表示が重なるなど、おかしくなる（rightも）。
しかし、Mozilla M17 / Netscape 6 PR2でもインライン要素のwidthは有効にならないので、無意味。
<link>で複数のスタイルシートを設定し、指定が衝突したときは、最後に設定したシートの指定が有効になるはずだ。
しかし、IE 5では、どうやらそうはなってないらしい。ローカルのファイルを読めばそうなるのだが、サーバに読みにいくと、そうはなってくれないことが多い。しかし、同じページを何度も再読み込みすると、正しくなることもある（笑）。
どうも、IE 5は読み込んだ順に指定が有効になるようで、上書きするために後に設定したシートのサイズが小さいと、それが先に読まれ、あとから前に設定したシートが読まれてそれが有効になってしまうようだ。
IE 5のためには、バカバカしいことだが、!importantした方がいいようである。
前記したMac Netscape 4でのJavaScriptエラーについて、ある匿名希望の方から以下のようなメールをいただいた。
この症状は「Netscape 4x の 4kバイト問題」と呼ばれるバグに起因すると思われます。
Netscape 4は、ソースが長くなるとソースの先頭からちょうど4kバイトのあたり（正確に4kではない）で意図しない改行が入ってしまい、その結果としてjavascript がエラーになったり、htmlが崩れたりします。
厄介なことに、ローカルで問題なくてもサーバーにアップしたら発現したり、マシンのレンダリング速度が遅いと大丈夫だったり、神出鬼没です。
こんな重要な問題なのに、どのサイト、書籍にも記述がないなんて不思議ですが・・・
（中略）
回避方法としてはソースの先頭から4kのあたりに1k分くらいのコメントを入れるというのがありますが、javascriptのdocument.write等を使用しているとこの 4k の位置がずれてしまうので注意が必要です。
より確実なのは <BODY> 直後に4k（4095バイト）のコメントを入れてしまうのが安全なのですが、その分ソースは重くなります。ちなみに私はこの方法で回避しています。
その後しばらくは問題が起こってなかったので、そのままだったのだが、最近発生したので、少し実験してみたところ、驚くべきことに（笑）、以下のようなことがわかった。
ブラウザごとにCSSファイルを変更するため、JavaScriptで以下のようにすることは割と一般的になっていると思われる。
document.writeln("<link rel=\"stylesheet\" type=\"text/css\" href=\"hoge.css\">");
しかし、これをやると、NN 4ではhtmlファイルの先頭から4キロバイト付近に、確実に改行が入ってしまう。Windows NT 4.0上の4.75、4.04、Mac OS上の4.7の各日本語版で確認した（テストケース参照）。これ以外の条件で余分な改行が入ることは確認できなかった。
ローカルのファイルを開く場合は、Windows版 4.*では、正確に4097バイト目に改行が入る。リンクしているCSSファイルのサイズは関係ないし、JavaScriptのdocument.write等でhtmlを出力していたとしても、単にhtmlファイルの4097バイト目である（確認はしてないが、サーバにアクセスする場合はSSIで取り込んでいる文字列のサイズは含まれるはず）。特に表示上の問題が起こっていなくても、「表示→ページのソース」画面を開くと、改行されていることがわかる。「ページを保存」してそれを開いてみると余計な改行は入っていないので、表示のためのレンダリングの段階で入っているようだ。
ちなみにWin版の「ページのソース」表示は、読んでいるソースを更新しても、再起動しないと表示が更新されないので、テストが面倒だった…。
Macintosh版 4.7も先頭から4096バイトの次に起こることが多いのだが、ときどき少しずれた位置になることもあり、また、シフトキーを押しながら強制再読み込みすると改行位置が変わることもあった。なお、Mac版の「ページのソース」画面には、この余計な改行は見えないことが多い。
サーバ上にhttp経由でアクセスする場合は、4097バイト目とは限らず、3KB後半から4KB前半あたりで改行が入る。同じファイルをMac版とWin版で見てみると改行の位置は違うし、また、同一セッション内で「戻る」ボタンによって再表示したときや、再読み込みしたときには、改行の位置が変わることもあった。キャッシュから読むときとネットワークから読むときなどによって、レンダリングのタイミング（？）が違っているのかもしれない。また、WindowsとMacで位置が違うのは、サーバ上のファイルがUNIX改行（1バイト）で同じだとしても、Windows改行が2バイトでMac改行が1バイトのためかも…。
この余分な改行が、たまたまタグとタグの間とか、タグの要素名と属性の間とかに起こってくれれば、もちろん表示上は何の問題もない。また、テキスト部分に起こった場合は半角スペースとして表示されるわけだが、Win版では標準がプロポーショナル・フォント（MS Pゴシック）になっているので、空きが小さいから、それほど目立たない。
Mac版では固定幅フォントが一般的なので、よく見ると半角分の空きが見える。
しかし、タグの要素名や属性の値の途中に起こった場合は、当然ながら表示は大きく崩れ、フォントが太字になってしまったり、タグ自体が表示されてしまったり、画像が表示されずに「壊れた画像アイコン」が表示されてしまったり、tableのbgcolorが効かなくなったり、もちろんCSSの指定が効かなくなったり、さまざまなことが起こり得る。
もっともWin版では、致命的な箇所に改行が入っても、逆説的に驚くべきことに (^_^)、問題なく表示されることがある。そのため、この問題はあまり話題になっていないのかもしれない。
長々書いた割に、対策は単純で、document.writelnは使わずにdocument.writeを使う、である。このとき、余計なお世話をして\nを最後に書き出そうとすると、元の黙阿弥になってしまう。\nは付け足さずに単に以下のようにすれば、けっこうな数のテストをしてみたが、この余分な改行は出力されなかった。
document.write("<link rel=\"stylesheet\" type=\"text/css\" href=\"hoge.css\">");
なお、document.writelnで<meta name="keywords">などを書き出す分には問題はないようだ。また、NN4は、linkタグについてはrel=\"stylesheet\"以外は対応していないからだと思われるが、念のためdocument.writelnで<link rel=\"contents\">などを書き出しても、問題は起こらなかった。
その後、<link rel=\"stylesheet\">以外に、もう一つ、同じ問題が起こるタグをたまたま見つけたのだが、メモするのを忘れて、わからなくなってしまった（笑）。
Windowsの「ＭＳ ゴシック」などが例えば10.5ポイントなどの細かいサイズをもっているのに対して、Macintoshのスクリーンフォントは、…、10、12、14、18pt…などのビットマップしかもっていないことが多いはずだ。
フォントサイズをポイントやピクセル、パーセントなどで指定されて該当ビットマップのサイズがないとき、Mac版 MSIE 5はそれに近いビットマップフォントだけしか表示しない。Mac IE 5の標準は16ピクセルのOsakaになっているが、16pxはないので、無指定部分の文字は14px（Macの画面上では14ptと同じ）で表示されている。<font size="??">やCSSのfont-sizeなどで細かく指定しても「差」が出るとは限らないということである。
一方、Navigator 4ではできるだけ指定サイズで表示しようとするが、ビットマップがないサイズの表示は汚い。コントロールパネル→アピアランス→フォントで「スムーズに表示する」をチェックすれば確かにスムースにはなるが、フォントの種類とサイズによっては太字になってしまい、文書作成者の意図とは違ってしまうだろうし、読者も気持ちが悪いと思う。
Macユーザを考慮すれば、フォントサイズ指定は見出しなどだけに限定し、ほかはユーザ側の設定にまかせるというのが、もともとのCSSのコンセプトにも合っているはずだ。
font-sizeを％指定したときのOsakaフォントMacintosh版のNavigator 4（現在4.7）は初期状態では日本語プロポーショナルフォントが細明朝体12ポイント（等幅フォントはOsaka-等幅の10ポイント）になっているが、多くのMacのアプリケーションではOsakaが標準になっており、また読みやすいフォントでもあるので、それに変更している人も多いと思う。
しかし、font-sizeをパーセント指定したときOsakaを使っていると、本来よりも大きく表示されるという、おかしなことが起こる（font-size:100%でも無指定より10〜20％大きく表示される）。手元のものはMac OS 8.6上のNavigator 4.7であり、OSのヴァージョンが異なれば、違った結果になるのかもしれない。おかしいのはとりあえずOsakaだけで、細明朝体や平成明朝、平成角ゴシック、本明朝-Ｍなどでは正しく表示される。また、MSIE 4.5や5、Mozilla / Netscape 6 PR2ではOsakaを使っても正しい結果になる。
OsakaはNavigator 4で使うと適当に行間が空いて読みやすいフォントなのだが、なんでこんなことになっているのか…。
まったくおかしなことだが、Macintosh版のNavigator 4.7では、JavaScriptを使っているページでCSSの指定がある程度以上長くなると、JavaScriptエラーが発生し、JavaScriptの実行が途中で止まってしまうことがある。もちろんJavaScriptやCSSの指定に特に問題がなくても、である。しかも、ローカルのファイルでエラーになっていてもサーバ経由では問題なかったり、逆だったりすることもある。
これを止めるためにはJavaScriptをいくらいじってもダメで、むしろ、CSSの指定を一部止めたり、記述する順序を変えたり、<style>タグの中に適当にコメント/* */を入れると、だいたい直る（笑）。もちろん、ぜんぜん根本的な解決ではないのだが。
バカすぎる…。
上記に関連して、JavaScriptエラー以外に表示がさまざまに崩れるという問題が発生していたのだが、それについてはNetscape 4.*の4KB問題 あるいは document.writeln("<link rel=\"stylesheet\" …>");のバグに関連するものだっのだろうと思うのだけれど、発生していたJavaScriptエラーは<head>内の頭の方で指定していたJavaScript指定が「構文エラー」になってしまっていたものだったので、この4KB問題とは別問題だと思う。<head>が4KBを超えたことはなかったはずだし。
その後はJavaScriptは必須のものしか使わないようにしたせいなのか、そうしたエラーは起こっていないが、今度発生したら、調べてみたい
font-familyMacintosh版のNavigator 4.7では、font-family: serif;やfont-family:"Times",serif;などと指定されていると、その部分の日本語は文字化けして読めない。
Macの日本語フォント名を指定すれば読めるわけだが、実は、font-family:"Times","あ",serif;でも読める（笑）。つまり、osakaなどのクライアントが持っている日本語フォント名が指定されているか、フォント名に2バイトの日本語が含まれている場合に、日本語が表示されるようになる。もっとも、Macの（システム標準の）日本語フォントを指定しても、そのフォントでは表示されず、ブラウザの標準設定のフォントが使われるだけだが。ちなみに、font-family:cursive;やfont-family:fantasy;と指定すると、逆に読めてしまう (^_^;)。対応していないからだろう。
また、フォント名に平成明朝などの日本語を指定する場合、シフトJISにしないと文字化けは直らない。外部スタイルシートを使うときは、HTMLはシフトJIS以外でもいいが、スタイルシートはシフトJISにする必要がある。HTMLとスタイルシートの文字コードが違っていて大丈夫かという気もするが、手許のいくつかのブラウザで試した限りでは問題ないようだ。ただし、CSS2勧告に従って、スタイルシートの先頭に@charset "Shift_JIS";を指定したり、参照元のlink要素のcharset属性で符号化方法を指定するべきだろう（これを参照しているブラウザはほとんどなさそうだが）。
なお、font-familyを指定すると、font-sizeやfont-weightなどは無効になってしまう。
MacのNetscape 4はWindows版に比べて悪いところばかりだが、一つだけ良い点を見つけた。Windows版は、欧文のfont-familyを指定しても日本語のページの中ではブラウザで設定した日本語フォントから変わらないが、Mac版では有効になる。