![[関西]WEBデザイン 交流会[大阪]](https://logo-imagecluster.img.mixi.jp/photo/comm/94/64/4999464_227s.gif){kind=logo}
今まで、深く理解せず利用していたテクニックがあります。
ネガティブマージンと、こちらのフロートさせた直後のテキストの回りこみをさせずにテキストを表示するテクニックです。
最近、仕事で忙しく一度に二つの質問をすると頭、こんがらがってしまうので、とりあえず、後者の質問をさせて頂いた後に前者のネガティブマージンの理解をしたいと思っております。
既知のようにIE6には以下の不具合があります。
http://
■⇒画像
■ああ
ああ
本来ならば、テキストは、
■ああ
ああ
のように回り込むはずですよね。
しかし、これをWEB標準準拠で、正式な理屈でIE6のバグを再現させたような方法が以下のテクニックになります。
http://
http://
http://
これが理解できません。
理解せず、今まで使ってきました。
※ちなみに、IE6用にZOOM: 1;を指定している意味はわかります。
旧IEでのhaslayoutバグを利用して、haslayoutプロパティをtrueにすることにより、IE6でのバグをワザと再現させている。
そして今回、色々調べてるうちにoverflowプロパティの仕様で以下のような事を知ることができました。
http://
今回の件、関係のないことかもしれませんが・・・。
上記を踏まえてもイマイチ理解できません。
なぜ、フロートしたボックスの後続のフロートもクリアもしていない要素にoverflow: autoを指定したら、
【floatに後続するボックスの幅がfloatに合わせて短縮される】のを再現できるのでしょうか？
W3Cの仕様では、通常フローで幅を指定してない場合、親要素まで伸びます。
高さは、内容物によって変わります。
フロートしたボックスの後続の要素が上記だった場合、
いくら、overflow: autoを指定した場合でも、
■ああ
ああ
となるはずではないのでしょうか？
理由が説明してあるサイトを見つけることができずご質問させていただきました。
よろしくお願いいたします。
ネガティブマージンと、こちらのフロートさせた直後のテキストの回りこみをさせずにテキストを表示するテクニックです。
最近、仕事で忙しく一度に二つの質問をすると頭、こんがらがってしまうので、とりあえず、後者の質問をさせて頂いた後に前者のネガティブマージンの理解をしたいと思っております。
既知のようにIE6には以下の不具合があります。
http://
■⇒画像
■ああ
ああ
本来ならば、テキストは、
■ああ
ああ
のように回り込むはずですよね。
しかし、これをWEB標準準拠で、正式な理屈でIE6のバグを再現させたような方法が以下のテクニックになります。
http://
http://
http://
これが理解できません。
理解せず、今まで使ってきました。
※ちなみに、IE6用にZOOM: 1;を指定している意味はわかります。
旧IEでのhaslayoutバグを利用して、haslayoutプロパティをtrueにすることにより、IE6でのバグをワザと再現させている。
そして今回、色々調べてるうちにoverflowプロパティの仕様で以下のような事を知ることができました。
http://
今回の件、関係のないことかもしれませんが・・・。
上記を踏まえてもイマイチ理解できません。
なぜ、フロートしたボックスの後続のフロートもクリアもしていない要素にoverflow: autoを指定したら、
【floatに後続するボックスの幅がfloatに合わせて短縮される】のを再現できるのでしょうか？
W3Cの仕様では、通常フローで幅を指定してない場合、親要素まで伸びます。
高さは、内容物によって変わります。
フロートしたボックスの後続の要素が上記だった場合、
いくら、overflow: autoを指定した場合でも、
■ああ
ああ
となるはずではないのでしょうか？
理由が説明してあるサイトを見つけることができずご質問させていただきました。
よろしくお願いいたします。
|
|
|
|
コメント(9)
> ととマン さん
僕もfloatとoverflowの関係がけっこう気になっていて考えたことを。
ブロック要素の高さはheight:autoの場合は中のコンテンツに合わせて決定される可変なものです。
heightを指定すれば中のコンテンツの量と関係なく高さが決定され、
親要素からコンテンツがはみ出す場合は、overflowの概念もわかりやすいと思います。
では、height:autoで、overflow:hiddenがしてある場合の挙動はどうなるのか。
というか、height:autoでoverflow（はみ出し）があるものなのか。
inline要素にheightを指定することと同じように意味をなさないものではないか。
しかし、overflowする場合はあり
・まず、今回問題にしているfloatしてる要素がある場合。
・position:relativeで位置を指定してる要素がある場合。
・position:absoluteで位置を指定してる要素がある場合。
と、ここまで書きましたが、時間がないので、とりあえずここで終わります。
すみません。僕も整理されているわけではなく試行錯誤しながら書いているので、時間がなくなってしまいました。
あと、途中のため、解説書きたい人がいても、書きづらいかもしれませんが、全然、書いてください。
他の人の解説見たいし、続きを書くのもいつになるかわからないので。
僕もfloatとoverflowの関係がけっこう気になっていて考えたことを。
ブロック要素の高さはheight:autoの場合は中のコンテンツに合わせて決定される可変なものです。
heightを指定すれば中のコンテンツの量と関係なく高さが決定され、
親要素からコンテンツがはみ出す場合は、overflowの概念もわかりやすいと思います。
では、height:autoで、overflow:hiddenがしてある場合の挙動はどうなるのか。
というか、height:autoでoverflow（はみ出し）があるものなのか。
inline要素にheightを指定することと同じように意味をなさないものではないか。
しかし、overflowする場合はあり
・まず、今回問題にしているfloatしてる要素がある場合。
・position:relativeで位置を指定してる要素がある場合。
・position:absoluteで位置を指定してる要素がある場合。
と、ここまで書きましたが、時間がないので、とりあえずここで終わります。
すみません。僕も整理されているわけではなく試行錯誤しながら書いているので、時間がなくなってしまいました。
あと、途中のため、解説書きたい人がいても、書きづらいかもしれませんが、全然、書いてください。
他の人の解説見たいし、続きを書くのもいつになるかわからないので。
皆様、コメント有難うございます！！
W3Cで明確に定義されてなく、曖昧な概念であれば、各ブラウザによって解釈が異なってもおかしくありません。
しかし、モダンブラウザと呼ばれる、最新のW3Cに忠実なFirefox Opera Google Chrome Safari IE8標準準拠モードでまったく同じ挙動になるので、
やはり、これはW3Cの仕様で理論づけをされていると私は思います。
私は、まだまだCSSに関しては、勉強不足で、
W3CのCSS2.ｘの仕様書をまだまだ、理解できていない部分が多数ある為、ご質問させて頂きました。
kskさん
お忙しい中、
とても、興味深いコメントありがとうございます。
『では、height:autoで、overflow:hiddenがしてある場合の挙動はどうなるのか。』
実は、これは私も、同じことを考えて、各ブラウザで検証してみたことがあるんです。
それは、幅を固定でpxで指定して、
高さをheight:autoにして、そのボックスにoverflow:hiddenを指定したんです。
仰るとおり、height:autoが有効になっているので、
高さに関してはoverflow:hiddenは、意味のないものでした。
しかし、幅を超えたものに関しては、表示されませんでした。
この挙動は理解できます。
hiddenは、枠がはみ出たものを表示しない。
height:autoなら高さの枠は自動的に延びる。
枠が無限に伸び続ける＝枠を超えることはない。
すなわち、指定する意味はあるが、結果的に意味のない指定となっている。
『inline要素にheightを指定することと同じように意味をなさないものではないか。』
これは、ちょっと違うような気がします。
なぜなら、W3Cの仕様では、確かインラインボックスには、元々高さと幅という概念がありません。
中にある、行ボックス(テキスト等の内容物)にも高さは存在しません。
そして、行ボックスの周りにあるインラインボックスのパディング、ボーダー、左右マージンも
高さではありません。
では、line-heightというのは何？
ってことになるんですが、
これは、W3Cの仕様や色々なサイトをみて私は、
インラインボックスには、関係なく
line-heightは、
その親要素のブロックボックスに関係し、インラインボックスにレイヤーとして高さという概念をブロックボックス内に存在させていると理解しております。
モダンブラウザでは、この理屈どおりに全て挙動します。
試しにブロック要素で、line-height1.0に指定してテキストを囲むと。
そのテキストは匿名インラインボックスとなります。
そしてそのブロック要素のブロックボックスの高さを、
Safari IE8の開発ツールで調べると・・・・
line-heightで設定した高さが維持されてます。
ここまでは簡単なことです。
しかし、
ブロック要素で、line-height1.0に指定して更にその子要素としてインライン要素でテキストを囲むと・・・・。
インラインボックスとブロックボックスの高さに違いがでます。
インラインボックスの高さは、
内容物（行ボックス）そのもの＋行ボックスの周りにあるパディング、ボーダー。
（高さとして表示されるが、厳密には高さではない。）
ブロックボックスの高さ、
line-heightの高さになります。
あれ？line-height1.0ということは、内容物（テキスト）と同じなんじゃ・・・？
と思うかと思いますが、実は・・・・。
フォントサイズで指定したサイズと、実際に画面上に表示される大きさは違うんです。
これは、内容物に関しては、W3Cで明確に定義されていないからです。
CSS3.0では、定義されるみたいですが。
line-heightに関しては、フォントサイズで指定したサイズでしっかり算出しております。
なので差がでるんです。
私が検証した結果、13pxを指定したテキストで、line-height1.0を指定したところ、
ブロックボックスは13px
インラインボックスは、なんと16pxとなりました。
つまり、内容物が16pxだが、高さというレイヤー13pxで存在する。
だから、内容物（行ボックス）より小さい数値で、Line-heightを設定すると、例えば0.5等・・・
隣の行に、テキストや内容物がはみ出すのです。
まさに、overflow:hiddenのように。
インラインボックスのパディングとボーダーが、隣の行に割り込むのはこの理屈です。
あくまで枠が、Line-heightなのです。
その為、インラインボックスにheightを『指定すること自体、意味がないもの』では、ないのでしょうか？
W3Cで明確に定義されてなく、曖昧な概念であれば、各ブラウザによって解釈が異なってもおかしくありません。
しかし、モダンブラウザと呼ばれる、最新のW3Cに忠実なFirefox Opera Google Chrome Safari IE8標準準拠モードでまったく同じ挙動になるので、
やはり、これはW3Cの仕様で理論づけをされていると私は思います。
私は、まだまだCSSに関しては、勉強不足で、
W3CのCSS2.ｘの仕様書をまだまだ、理解できていない部分が多数ある為、ご質問させて頂きました。
kskさん
お忙しい中、
とても、興味深いコメントありがとうございます。
『では、height:autoで、overflow:hiddenがしてある場合の挙動はどうなるのか。』
実は、これは私も、同じことを考えて、各ブラウザで検証してみたことがあるんです。
それは、幅を固定でpxで指定して、
高さをheight:autoにして、そのボックスにoverflow:hiddenを指定したんです。
仰るとおり、height:autoが有効になっているので、
高さに関してはoverflow:hiddenは、意味のないものでした。
しかし、幅を超えたものに関しては、表示されませんでした。
この挙動は理解できます。
hiddenは、枠がはみ出たものを表示しない。
height:autoなら高さの枠は自動的に延びる。
枠が無限に伸び続ける＝枠を超えることはない。
すなわち、指定する意味はあるが、結果的に意味のない指定となっている。
『inline要素にheightを指定することと同じように意味をなさないものではないか。』
これは、ちょっと違うような気がします。
なぜなら、W3Cの仕様では、確かインラインボックスには、元々高さと幅という概念がありません。
中にある、行ボックス(テキスト等の内容物)にも高さは存在しません。
そして、行ボックスの周りにあるインラインボックスのパディング、ボーダー、左右マージンも
高さではありません。
では、line-heightというのは何？
ってことになるんですが、
これは、W3Cの仕様や色々なサイトをみて私は、
インラインボックスには、関係なく
line-heightは、
その親要素のブロックボックスに関係し、インラインボックスにレイヤーとして高さという概念をブロックボックス内に存在させていると理解しております。
モダンブラウザでは、この理屈どおりに全て挙動します。
試しにブロック要素で、line-height1.0に指定してテキストを囲むと。
そのテキストは匿名インラインボックスとなります。
そしてそのブロック要素のブロックボックスの高さを、
Safari IE8の開発ツールで調べると・・・・
line-heightで設定した高さが維持されてます。
ここまでは簡単なことです。
しかし、
ブロック要素で、line-height1.0に指定して更にその子要素としてインライン要素でテキストを囲むと・・・・。
インラインボックスとブロックボックスの高さに違いがでます。
インラインボックスの高さは、
内容物（行ボックス）そのもの＋行ボックスの周りにあるパディング、ボーダー。
（高さとして表示されるが、厳密には高さではない。）
ブロックボックスの高さ、
line-heightの高さになります。
あれ？line-height1.0ということは、内容物（テキスト）と同じなんじゃ・・・？
と思うかと思いますが、実は・・・・。
フォントサイズで指定したサイズと、実際に画面上に表示される大きさは違うんです。
これは、内容物に関しては、W3Cで明確に定義されていないからです。
CSS3.0では、定義されるみたいですが。
line-heightに関しては、フォントサイズで指定したサイズでしっかり算出しております。
なので差がでるんです。
私が検証した結果、13pxを指定したテキストで、line-height1.0を指定したところ、
ブロックボックスは13px
インラインボックスは、なんと16pxとなりました。
つまり、内容物が16pxだが、高さというレイヤー13pxで存在する。
だから、内容物（行ボックス）より小さい数値で、Line-heightを設定すると、例えば0.5等・・・
隣の行に、テキストや内容物がはみ出すのです。
まさに、overflow:hiddenのように。
インラインボックスのパディングとボーダーが、隣の行に割り込むのはこの理屈です。
あくまで枠が、Line-heightなのです。
その為、インラインボックスにheightを『指定すること自体、意味がないもの』では、ないのでしょうか？
Reek_CR-Zさん ィシィさん
コメント有難うございます。
ィシィさんが、
仰るとおり、HTMLで、ブロック要素ですが、CSSでも、P要素は、初期値がdisplay ブロックです。
つまり、元々ブロックボックスです。
Reek_CR-Zさんが仰るとおりだと、IE６のバグ解釈そのものに・・・・・ｗｗｗｗ
すいません。。。せっかくコメントしてくれたのに、揚げ足とって。。。
そもそも、フロートは『回り込みじゃない』ですよね？
ご質問させて頂いた内容では、
フロートしている後続のPブロックボックスは、
浮いているインラインイメージというレイアーの下に、
ウィンドウに合わせて100％の幅で存在しているのが、
W3Cのフロートの厳密な仕様なはずです。
そして、浮いているインラインイメージにテキストは、被さって見えなくなるはずです。
『しかし』テキストや内容物は特別な扱いで、
横にずれて、あいている領域に詰め込まれ（流し込まれ）右に表示されているというのが、
厳密な仕様理論なはずです。
この仕様通りなら、上に被さっている画像の下にあるpブロックボックスは、ウィンドウの幅100％なはず。
しかし、overflow: auto等をPブロックボックスに指定すると・・・・。
幅が浮いている画像に合わせて短縮されると・・・・。
なぜだｗｗ
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
CSSテクニック 更新情報
CSSテクニックのメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- お洒落な女の子が好き
- 90069人
- 2位
- 写真を撮るのが好き
- 208326人
- 3位
- 酒好き
- 170699人