サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
norisfactory.com
定義リストで、dtとddを横並びにしたいとき、ddのマージンの調整でそれを実現するやり方は私がよく使うテクニックなのだが、あるとき、IE7で見たらdtがすっかり消えていて、あわてたことがある。原因は、またしても、その定義リストを含むボックスへの背景画像の指定だった。 [該当するブラウザ] Windows/IE7.0以下 症状 たとえば、年表のようなリストを角マルの矩形で囲むレイアウトを組んだとする(右図)。 角マル矩形は、 frame_top.gif(トップの部分)、 frame_bg.gif(中間部分)、 frame_btm.gif(ボトムの部分)、 以上3つの画像を、dlおよびdlを含むボックスに背景として指定することで実現している。詳細は以下の通りである(→サンプルページ1)。 【スタイルシート】 body { margin: 10px; padding: 0; } .box { w
この現象は、あるWebページで、※1~、※2~、※3~というような「脚注」にdlタグを使用したときに発生した。 本文と脚注を区切る罫線として、脚注を含むボックスの上部に、二重破線の背景画像(line.gif をx軸にリピート)を指定。ddにマイナスのmargin-topを指定して、dtとddが横に並ぶレイアウトにしたところ、一番上にだけ入るべき罫線が<dt></dt><dd></dd>のセットごとに入ってしまったのである。 [該当するブラウザ] Windows/IE7.0(互換モードのとき)、IE6.0以下 症状 実際にどういうことか、右のスクリーンショットを見ていただこう。これは、IE7.0で表示させたときのものである。 そして、スタイルシートとHTMLは以下のように記述されている。(→サンプルページ1) 【スタイルシート】 body { line-height: 1.5em; } .b
ブラウザの表示モードには、W3Cの標準的仕様に準拠した標準モードと旧来のブラウザと互換性のある互換モードの2つがある。Windows版IE6.0以降、Macintosh版IE5.X以降、およびNetscape6.0以降では、この2つを文書型宣言の書き方(※注)によってスイッチするが、問題なのは、それより以前のバージョンのブラウザでは、文書型宣言の書き方にかかわらずすべて互換モードと表示になってしまうことだ。標準モードと互換モード(※注)では、スタイルシートの解釈の違いにさまざまなものがあるが、今回検証する「フォントサイズの指定がテーブル内に継承されるか、されないか」もそのひとつ。ちなみに、標準モードでは継承されるが、互換モードでは継承されない。 [該当するブラウザ] Windows版IE5.5以前、Macintosh版IE4.5以前 Netscape4.7以前 ※注:簡単にいうと、文書型宣
font-familyに細明朝体を指定すると、それ以降のスタイル指定がすべて無視される、という現象。これを発見したのは、管理人が手がけたあるサイトの中のページについて、顧客から「レイアウトがガタガタにくずれているよ」と指摘されたことがきっかけだった(公開前のテスト段階の話だが)。なぜ、指摘されるまで気付かなかったかというと、これがIE6以前でのみ起こり、IE7やFirefoxでは発生しない現象だからだ。Web制作を仕事としている以上、こんなことは言い訳にならないのだが、このときはたまたま見逃してしまった。 [該当するブラウザ] Windows/IE5.0、IE5.5、IE6.0 症状 この現象を再現してみよう。スタイルシートとHTMLは以下の通りである。 【スタイルシート】 p.default { border: 1px solid #000000; background: #cccccc
スタイルシートを使ってレイアウトする時、最も重要かつ基本的な概念となるのが "ボックス" だ。テーブルを使ったレイアウトに慣れている方なら、セルが一つしかないテーブルのようなものと考えればわかりやすいだろう。このボックス、標準モードでは、高さを100%と指定してもウィンドウの縦いっぱいに表示させることはできない。 [該当するブラウザ] Windows/IE6.0、Netscape7.1 Macintosh/IE5.0、IE5.1、Netscape7.0 testboxというID名のボックスを設定し、背景色・黒、高さ・幅とも100%で指定してみた(→サンプルページ1)。ご覧のとおり、幅についてはウィンドウいっぱいになるが、高さについては、標準モードで検証したすべてのブラウザでウィンドウいっぱいにならない。また、ボックスと同様テーブルも、標準モードでは高さを100%としてもウィンドウいっぱいに
前回のIE編の冒頭で、私は「CSS自体の正しさとか美しさを優先し、そのためには古いバージョンのブラウザは犠牲になってもしょうがない」と書いた。その流れでいえば、マイクロソフトもサポートを打ち切ったMac版IEにそもそも対応する必要があるのか、IE編でWin版IE5.0を無視したのだから、Mac版IEも無視していいのではないか、という疑問が当然わく。至極もっともなことである。が、しかし、それで終わってしまっては本稿自体が成り立たない。しぶしぶではあるが、Mac版IE(5.x)でfloatをクリアする方法を探ってみよう。結論はもうすでに出ている。以下の通りである。 .clearfix:after { content: url(pixel.gif); display: block; clear: both; height: 0; } .clearfix { display: inline-blo
今回は、floatバグ対策における鬼門ともいえるIEのclearfixに挑戦する。しかし、その前に、何をもって「決定版」とするか、あらためておさえておこう。本来なら、ひとつでも多くの種類、バージョンのブラウザでfloatをクリアできる(もしくは同じ効果を得られる)ことをもって、決定版とすべきなのだろうが、ここでは少し違う方針をとりたいと思う。簡単にいえば、CSS自体の正しさとか美しさを優先したいということだ。逆に、そのためには古いバージョンのブラウザなどは犠牲になってもしょうがない、と考えている。ここでいう「決定版」を定義してみよう。 1. 文法的に正しいこと このこととイコールとするには異論があるかもしれないが、「W3Cのvalidatorを通ること」と言い換えることもできる。少なくとも、通らないより通るほうがいい。 2. 内容的に理にかなっていること、意味不明でないこと いわゆるCSS
ある要素にfloatと横方向のmarginの指定を同時に行うと、marginで指定した位置よりも右または左にずれるというもの。 [該当するブラウザ] Windows/IE5.5、6.0 症状 Mac/IE5.1の場合 右のスクリーンショットを見てもらおう。左側に10ピクセルの余白をとってコンテンツA、その右にコンテンツB、というような2段組のレイアウトを組んだとする。スタイルシートでは、コンテンツAに float: left、margin-left: 10px と指定する。ちゃんと正しい位置に配置されているかわかるように背景画像に10ピクセル刻みで縦の罫線を入れてみた。ご覧のとおりMac(およびNetscape6.0以降)では位置のズレはない。 Windows/IE6.0の場合 しかし、Windows版のIE5.5、6.0ではコンテンツAの位置がずれ、余白は10ピクセルより広くなってしまう
フォントサイズについては、私の場合、キーワードによる指定(small、mediumなど)を基本としているが、例えば、smallとx-smallなどはけっこう大きさに差があって、どうしてもその間の大きさの文字を使いたくなる。そんなときは、パーセントによる指定を併用するのだが、70%台のある範囲の値については注意が必要である。 [該当するブラウザ] Windows/IE6.0、IE7.0(5.5以前は未確認) 症状 font-sizeを%で指定した時のIE6の表示 まず、右のスクリーンショットを見てもらおう。 71%よりも72%の方が大きく、73%、74%と文字の大きさが変わらないのは、とりあえずいいとして、その上のサイズの75%になると、今度は逆に小さくなってしまうことがおわかりいただけると思う。その後、78%まで大きさは変わらず、79%でようやく72~74%と同じ大きさを回復する。 ただし
ある要素にfloatを指定するときは、一緒にwidthも指定するのが基本的ルールである。実際、widthを指定しないとどんな不具合が起きるのか、それを検証してみたい。 [該当するブラウザ] Macintosh/IE5.0、IE5.1 症状 widthを指定しないことによる不具合はいくつかあると思うが、ここでは2つのケースを取り上げる。 ひとつは、floatさせたいボックスにtext-alignを指定した場合。たとえば、画像の下にキャプションを右揃えで入れ、その左側に本文を回り込ませたいときなどだ。この形にするためには、画像とキャプションを含むボックスにfloat:rightとtext-align:rightを指定することになるが、そうした時、Macintosh版IEでは本文が回り込まずに画像の下に来てしまう(→サンプルページ1)。これは、text-align:centerとしても同様である
inline-blockとは、displayプロパティの値のひとつで、表示形式を「インラインに流し込むことのできるブロック要素」にするためのもの。まともに対応しているのが、OperaとSafari、それになぜかMac版IEくらいというマイナーな存在だが、なかなか興味深い振る舞いをする値なので、いろいろと検証してみた。 まず、「インラインに流し込むことのできるブロック要素」とはどういうものなのかを見てみるために、.inlineblockというクラスを作り、div要素に指定してみた。また、「インラインに流し込むことのできるブロック要素」とは、言い換えれば、「幅と高さを指定できるインライン要素」ということだから、span要素にも指定した。 インラインブロックの検証 その1 【スタイルシート】 .inlineblock { display: inline-block; width: 100px;
HTML5対応版clearfix(予告) » 最近、あるサイトのソースをXHTML1.0からHTML5に書き換えていて、私家版clearfixに不具合があることを発見した。近... [read more] clearfixの決定版を作る -Mac IE編- » 前回のIE編の冒頭で、私は「CSS自体の正しさとか美しさを優先し、そのためには古いバージョンのブラウザは犠牲になってもしょうがな... [read more] clearfixの決定版を作る -IE編- » 今回は、floatバグ対策における鬼門ともいえるIEのclearfixに挑戦する。しかし、その前に、何をもって「決定版」とするか... [read more] inline-blockの奇妙な世界 » inline-blockとは、displayプロパティの値のひとつで、表示形式を「インラインに流し込むことのできるブロック要素」
単純化するために、AとB、高さの異なるボックスを2つ設定した(A>B)。そして、ボックスAをfloat: leftで左側に配置、ボックスBをfloat: rightで右側に配置、さらに全体をひとつのボックス(クラス名: column)で囲み、それを2回繰り返してみた(→サンプルページ1)。Winows版IEでは問題ないのでOKと思ってしまいそうだが、実はそれ以外のブラウザではちゃんと表示されない。 【スタイルシート】 .column { width: 125px; margin-bottom: 5px; } .box-A { width: 60px; height: 60px; background-color: #000000; float: left; } .box-B { width: 60px; height: 30px; background-color: #cccccc; fl
「表」のほか「構」「予」など、コメントで使うとスタイル指定が無効になるクセ者の文字がいくつかある。Macintosh版のIEでのみ発生するマイナーな現象のせいか、このことに触れている文章をあまり見たことがない。筆者の場合、コメントに「表示」という言葉を使ったため、たまたま遭遇した。 [該当するブラウザ] Macintosh/IE5.0、IE5.1 症状 どのような条件下においてこの現象が発生するか、細かく見ていこう。 まず、外部スタイルシートにおいて、box-A、box-B、box-C、box-Dという4つのボックスを定義する。いずれも、高さ・幅とも80ピクセル、背景色黒、文字色は白。ただし、box-Aとbox-Dの定義の前にはコメントなし。box-Bとbox-Cの定義の前にはコメントあり、前者には「構」、後者には「表」の1文字を入れた。 次に、HTMLファイルでは、テーブルを組んでbox
サイト名は「管理人noriのガラクタ工房」の意。管理人の職業であるWeb制作と、趣味である音楽をテーマに、気の向くまま勝手気ままにつづる極私的備忘録。
floatに起因するレイアウトくずれの多くは、floatをしかるべき場所でクリアすることによって解決する。このことを発見して以来、もっぱら空ボックスにclearを指定するという方法(<div style="clear: both"></div>)を多用してきたが、HTMLにある種の不純物が混じることに居心地の悪さはずっと感じていた(「floatを繰り返すとレイアウトがくずれる」参照)。この気持ち悪さを解消してくれるのが、clearfixというテクニックだ。 基本的な発想は上記の空ボックスによるクリアと同じだが、それをHTMLには一切手を加えず、スタイルシートだけで実現しているところに大きな特徴がある。しかし、ひとくちにclearfixといっても様々なバリエーションがあり、その記述のしかたは微妙に異なる。 例えば、clearfixの提唱者ではないかと類推されるPosition Is Ever
このページを最初にブックマークしてみませんか?
『norisfactory』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く