サイト制作メモ

list-style-imageで画像を指定すると、リスト項目の文字列とアンバランスな位置に画像が表示されてしまうことが多い。 具体的に言うと、画像の位置がやや上過ぎる。

画像を揃えるにはlist-style-imageではなく、background-imageを使うのが一般的らしい。

ul {
 padding:0;
}

li{
 background-image:url(./img/bug.png) 
 background-repeat:no-repeat;
 background-position:top left;
 padding-left: 30px;
 list-style:none;
}

しかし、この方法ではCSSオンかつ画像オフのときにリストマーカーが見えなくなってしまうのが欠点。 素直にlist-style-imageを使えば画像がオフの時にはマーカーが表示される。

そこで、vertical-alignを使う方法を思いついた。 vertical-alignは、インライン要素に指定するとインラインボックスの行ボックス内での高さを指定できる。

li要素の中にインライン要素（たとえばa要素）がなければ使えないが、vertical-align:（数値＋単位）などとすれば、リスト画像に対してちょうどいい高さにインラインボックスをもってこられる。 ただし問題点も多かった。

• line-heightが影響する
• ブラウザによって表示位置が異なる
• 画像をオフにすると、リストマーカーの位置もずれる（正しくはインラインボックスの位置がずれている）

• CSS2仕様書翻訳　17.3 列選択子
• col/colgroup要素へのスタイル指定

一部の列だけにcolorやtext-alignを指定したくなるけど、仕様では無効なんですね。IEでは有効みたいですが。

floatを指定した場合の振る舞いについてのイメージ。 floatの説明としてよくされるような「floatを指定した部分を左または右に寄せて、空いたスペースに後続する文字を回り込ませる」とは違って、floatしたボックスは文字通り浮くものとして捉える。

基本

• ブロックレベル要素は矩形のボックスをつくる（高さはheightや内容によって決まる）。
• 矩形のボックスの中に行ボックスがある（高さはline-heightなどによって決まる）。

レンダリングのイメージ

1. 表示領域の上（y軸の正方向）に向かって重力のようなものが働くイメージ。
2. ブロックレベル要素がつくるボックスが、ソースで上にあるものから順に重力によって上（y軸の正方向）へと積まれていく。
3. floatが指定してあるボックス（Aとする）は浮く（z軸の正方向に）。浮いたうえで、左（float:left）や右（float:right）に寄る。
4. 浮いた（floatした）ボックスAにつづくボックス（Bとする）は、浮いているボックスAの下（裏）に潜り込む。
5. 浮いているボックスAの下になって見えなくなるボックスBの行ボックスは見える位置になるようにずれる。
6. 浮いているボックスAの背景色が透明の場合、下に潜り込んだボックスBのborderやbackgroudが見える。
7. IEのレンダリングはこれに従わないから無視すること。

たとえばボックスAにfloat:leftとwidth:200pxを指定し、つづくボックスBにwidth:200pxとbackground-colorを指定すると、 浮いたボックスAの下（裏）にボックスBが潜り込んで、ボックスBの行ボックスはボックスAの行ボックスと重ならないように下（y軸の負方向）にずれる。 そしてボックスAの部分にはボックスBの背景色が見える（はず）。

• floatのテスト

IEのバグ

ここまでの「floatのイメージ」に従わなくなるIEのバグを『CSSバグリスト＠CSSバグ辞典スレッド』から抜粋。

• フロートに後続するボックスの幅がフロートに合わせて短縮される(5.x/6.0)
• 先行するフロートの上方に後続のフロートが置かれる
• clearを指定した要素ではフロートに対して上マージンを設置する(5.x/6.0)

その他、フロートに関するバグの一部。

• フロートの左右マージンが指定値より大きくなる(5.x/6.0)
• フロートを含むボックスのマージンが無視される(5.x/6.0)
• フロートの左右にある行の端がずれる(5.x/6.0)
• 親要素のボックスからはみ出すボックスがフロートの下に置かれる(5.x/6.0)
• コメントがフロートの位置をずらす(6.0)

• linkのススメ - 駄的HTML改善計画

link要素のrel,rev属性に関して属性値の意味とブラウザの対応状況をまとめたもの。 同じ用途にも複数の属性値があるようで、それぞれ対応ブラウザに差があります。 link要素でのナビゲーションを記述する際にはとても参考になります。

Firefoxが標準で対応していないのが残念です。 Link Toolbarという拡張を入れれば利用できるとはいえ、ほとんどのサイトでlink要素が使われていない現状ではわざわざ拡張を入れる気にはなりません。

link要素でのナビゲーションを用意しているサイトが少ないのはやはり多くのブラウザが対応していないからでしょう（あるいはほとんどのサイトでlink要素でのナビゲーションを用意していないから、ブラウザ側もわざわざ対応しない）。 最近注目を集めるFirefoxが標準で対応していればこの状況も少しはマシになったかもしれないのですが。IE7には是非標準対応してもらいたいものです。

• フォントサイズ近似転換表
• CSSで小さい字

font-sizeを100％にするとたいていブラウザデフォルトの16pxになって、自分のパソコンのディスプレイではやや大きい気がします（日本語の場合）。 でも15pxだと今度は小さすぎる気が。14pxと15pxではほとんど差がないように思うのに、15pxと16pxではずいぶん違う。

次の表は、ひらがな、漢字、カタカナの例。

font-size	ひらがな	漢字	カタカナ
font-size: 16px;	ごきげんよう	白薔薇	ロサ・ギガンティア
font-size: 100%;	ごきげんよう	白薔薇	ロサ・ギガンティア
font-size: 15px;	ごきげんよう	白薔薇	ロサ・ギガンティア
font-size: 95%;	ごきげんよう	白薔薇	ロサ・ギガンティア
font-size: 14px;	ごきげんよう	白薔薇	ロサ・ギガンティア
font-size: 87.5%;	ごきげんよう	白薔薇	ロサ・ギガンティア

15pxと16pxの中間のサイズがほしいところですが、小さすぎるよりは大きいほうがマシなので、結局font-size:100%にしています。

• 一考・accesskey&tabindex

accesskeyやtabindexは指定するメリットがあまりない上に、デメリットもそれなりにあるというわけで、あえて指定する必要もないかと。

同様に、（本文の）font-sizeやfont-familyもブラウザのデフォルト（閲覧者の設定）にまかせて、制作者側で指定しない。指定したことによるトラブルもなくなって楽ですし。

• font-familyを指定した要素で文字化けする（『CSSバグ辞典スレッド』の要約）
• 本文は特定フォントでの表示を強制しないでほすぃ（ねこめしにっき）
• font-size: 90% 指定だって豆字固定と大差無い（ねこめしにっき）