135

CSSボックスモデルの仕様を見ると、次のことがわかります。

[マージン]パーセンテージは、生成されたボックスを含むブロックの幅を基準にして計算されます。これは「margin-top」と「margin-bottom」にも当てはまることに注意してください。含まれているブロックの幅がこの要素に依存している場合、結果のレイアウトはCSS2.1では定義されていません。 （強調鉱山）

これは確かに真実です。しかし、なぜですか？いったい何が誰かにこのようにそれを設計することを強いるでしょうか？必要なシナリオを考えるのは簡単です。たとえば、特定のものを常にページの上部から25％下に配置することは簡単ですが、垂直方向のパディングを水平方向のサイズに対して水平方向のパディングにする理由を思い付くのは困難です。親。

これが私が言及している現象の例です：

<div style="border: 1px solid red; margin: 0; padding: 0; width: 200px; height: 800px;">
  This div is 200x800.
  <div style="border: 1px solid blue; margin: 10% 0 0 10%;">
    This div has top-margin of 10% and left-margin of 10% with respect to its parent.
  </div>
</div>

http://jsfiddle.net/8JDYD/

4

5 に答える 5

60

論理的に理にかなっているので、私のコメントを回答に転送します。ただし、これは根拠のない推測であることに注意してください。仕様がこのように書かれている理由の実際の理由は、技術的にはまだ不明です。

要素の高さは、子の高さによって定義されます。要素にパディングトップがある場合：10％（親の高さに対して）、それは親の高さに影響します。子の高さは親の高さに依存し、親の高さは子の高さに依存するため、高さが不正確になるか、無限ループになります。確かに、これはオフセット親===親の場合にのみ影響しますが、それでも影響します。解決するのが難しい奇妙なケースです。

更新：最後の数文は完全に正確ではない可能性があります。葉の要素（子のない子）の高さは、その上のすべての要素の高さに影響するため、さまざまな状況に影響します。

于 2012-06-12T21:03:31.700 に答える
30

「n％」マージン（およびパディング）がmargin-top / margin-right / margin-bottom / margin-leftで同じであるためには、4つすべてが同じベースに対して相対的である必要があります。上/下が左/右とは異なるベースを使用している場合、「n％」のマージン（およびパディング）は、4つの側面すべてで同じことを意味するわけではありません。

（幅に対して上下の余白があると、奇妙なCSSハックが可能になり、ボックスが再スケーリングされた場合でも、アスペクト比が変わらないボックスを指定できることに注意してください。）

于 2013-08-18T02:40:50.953 に答える
4

このJSFiddle（Chrome 46.0.2490.86）で遊んだ後、この投稿（中国語で書かれた）を参照した後、@ChuckKollarsからの回答に投票します。

無限計算の推測に対する主な理由は、次のとおりです。使用widthすると、同じ無限計算の問題に直面します。

このJSFiddleを見てください。parentディスプレイはinline-block、マージン/パディングを定義するのに適しています。にchildはマージン値があります20%。無限の計算予想に従う場合：

  1. の幅childはparent
  2. の幅parentはchild

しかし、その結果、Chromeはどこかで計算を停止し、次のようになります。

ここに画像の説明を入力してください

JSFiddleで「結果」パネルを水平方向に展開しようとすると、幅が変わらないことがわかります。の内容は2行child（たとえば1行ではない）に折り返されていることに注意してください。なぜですか？Chromeはどこかにハードコーディングしているだけだと思います。コンテンツを編集してさらに作成すると（ JSFiddle）、水平方向に余分なスペースがある限り、Chromeはコンテンツを2行保持します。child

したがって、次のことがわかります。無限の計算を防ぐ方法がいくつかあります。

私は次の推測に同意します。この設計は、同じ基準に基づいて4つのマージン/パディング値を維持するためのものです。

この投稿（中国語で書かれている）も別の理由を提案しています：それは読書/植字の方向性のためです。幅を固定し、高さを無限に（事実上）、上から下に読みます。

于 2015-11-26T03:19:58.910 に答える
3

OPは、CSS仕様で上下のマージンのパーセンテージを幅の％として定義する理由を尋ねていることを理解しています（想定されるように、高さではありません）が、潜在的な解決策を投稿することも役立つと思いました。

最近のほとんどのブラウザはvwとvhをサポートするようになり、ビューポートの幅と高さに対してマージン番号を指定できるようになりました。

スクロールバーがない場合、100vw / 100vhは（それぞれ）100％幅/ 100％高さに等しくなります。スクロールバーがある場合、ビューポート番号はこれを考慮しません（％数は考慮します）。ありがたいことに、ほぼすべてのブラウザが17pxのスクロールバーサイズを使用しているため（ここを参照）、csscalc関数を使用してこれを説明できます。スクロールバーが表示されるかどうかわからない場合、このソリューションは機能しません。

例：水平スクロールバーがないと仮定すると、高さの50％の上部マージンは、「margin-top：50vh;」として定義できます。水平スクロールバーの場合、これは「margin-top：calc（0.5 *（100vh-17px））;」として定義できます。（calcのマイナス演算子とプラス演算子には両側にスペースが必要であることを忘れないでください！）。

于 2016-01-05T17:16:56.817 に答える
1

この質問は少し古いことは知っていますが、CSS3用に更新したいと思います。CSS2.1仕様では、パディングのパーセンテージとマージンは、含まれているブロックの幅に対して定義されると規定されていることは事実ですが、常にそうであるとは限りません。書き込みモードによって異なります。これはCSS3の仕様から直接来ています：

当然の結果として、CSS2.1の包含ブロック幅に関して常に計算されるマージンおよびパディングプロパティのパーセンテージは、CSS3の包含ブロックのインラインサイズに関して計算されます。

これについては、CSSを使用したアスペクト比に関するチュートリアルで説明します。

具体的には、水平書き込みモードと垂直書き込みモードでのパディングの割合に関するセクションがあります。デフォルトでは、要素には水平書き込みモードがあり、テキストは左から右に水平に（「インライン」方向に）流れます。ただし、writing-modeCSSプロパティを使用すると、実際にモードを垂直に設定できます（テキストは右から左または左から右に流れます）。水平書き込みモードと垂直書き込みモードの図を次に示します。

テキストが上から下に垂直に流れる水平書き込みモード。 矢印はドキュメントの上部を左から右に指し、インライン方向としてラベル付けされています。 別の矢印は上から下を指し、ブロック方向としてラベル付けされています。

テキストが水平方向に流れる垂直書き込みモード。 横軸はブロック方向としてラベル付けされていますが、縦軸はインライン方向としてラベル付けされています。 テキストは横向きにレンダリングされます。

これらは、書き込みモードに関するMDNドキュメントから取得されます。

垂直書き込みモードでは、パーセンテージのパディングは、幅ではなく、含まれているブロックの高さに関連します。

ここに証拠があります：

.document {
  writing-mode: vertical-rl;
  width: 100%;
  height: 100vh;
}

.parent {
   width: 100%;
   height: 200px;
   background-color: black;
   color: white;
}

.child {
  padding: 10%;
  background-color: white;
  color: black;
  border: solid 1px;
}
<div class="document">
  <div class="parent">
    <div class="child">
      Child
    </div>
  </div>
</div>

子は20pxのパディングを取得します。これは、含まれているブロックの高さ（200px）の10％です。

質問の理由については、これはここの他の投稿で十分にカバーされていました。

于 2020-09-24T12:19:58.043 に答える