如何确定嵌套绝对定位元素的宽度？ [英] How are the widths of nested absolutely positioned elements determined?

问题描述

示例：

 < style> 
 div {
 position：absolute; left：auto; right：auto; width：auto; 
 margin：0; padding：0; border：0; 
} 
< / style> 
< div id =containingBlock> 
 foo 
< div id =inner>这是我的文字< / div> 
< / div> 
  

要确定两个div的宽度，我们需要 shrink-to-fit 算法，位于 http://www.w3.org /TR/CSS21/visudet.html#abs-non-replaced-width *

让我们从 #inner ：

• 取得偏好最小宽度

   这个
  是
  我的
  文本
   | ---- |首选最小宽度
    




• 
  
  

   这是我的文字
   | --------------- |首选宽度
    




• 比较可用宽度

  ：

    computed width = min（max（首选最小宽度，可用宽度），
  首选宽度）
    

  轻松。但什么是可用宽度？因为我们没有边距/ paddings / border，它只是 containsBlock 的宽度。但现在我们得到了一个无限循环，因为同样的算法再次适用：




• 获取containsBlock的优先最小宽度 >
  
  

    foo 
   + ------- + 
   | inner | 
   + ------- + 
   |  -   -   - 首选最小宽度
    

换句话说： inner 的宽度，我们必须知道 containsBlock 的宽度，反之亦然。

实际上，在这种情况下，浏览器看起来像是假设 available width = 0 ： http://jsfiddle.net/pxvJJ/6/ 。
但是这不包括在规范中，或者我缺少一些明显的东西？

* _{（注意，这个规范还没有被替换CSS3）}

解决方案

如果我们仔细阅读规范，我们将找到

CSS 2.1没有定义确切的[缩小拟合]算法。

类似于使用自动表布局算法计算表格单元格的宽度

这反过来，是实现依赖的。

所以，上面的例子表明，排除 #inner 在实现直接算法时，计算containsBlock的优选最小宽度可能是个好主意，我们最终会得到：

  | --- |优选最小宽度
 foo 
 + ------- + 
 | inner | 
 + ------- + 
 |  -   -   - 
  

这可能是浏览器所做的。

---

话虽如此，问题是： do 实际上对containsBlock的首选最小宽度有何贡献？

让我们看看如果 #inner 有 position：static; width：auto 。这种情况甚至更难。同样，规范提供了约束

'margin-left'+'border-left-width'+'padding-left'+'width'+'padding-right'+'border- width'+'margin-right'=包含块的宽度

而且，它也不能解决。还是可以吗？有趣的是，它可以！让我们看看实际发生的情况： http://jsfiddle.net/pxvJJ/12/

显然，静态定位的div会有不同的对待。因此，我假设用于确定包含块宽度的算法是这样的：

1. 确定


2. 设置包含块的宽度=这些首选宽度的最大值


3. 计算宽度

我仍然感到困惑为什么（所有）浏览器这样做。在这方面似乎没有理由对待绝对定位的元素。

Example:

<style>
     div {
         position:absolute; left:auto; right:auto; width:auto;
         margin:0; padding:0; border:0;
     }
</style>
<div id="containingBlock">
    foo
    <div id="inner">this is my text</div>
</div>

To determine the widths of both divs, we need the shrink-to-fit algorithm in http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width *

Let's start with #inner:

• get the preferred minimum width

   this
   is
   my
   text
  |----| preferred minimum width
  

• get the preferred width

   this is my text
  |---------------| preferred width
  

• compare both to available width:

  computed width = min(max(preferred minimum width, available width),
                       preferred width)
  

  Easy. But what is available width? Since we got no margins/paddings/borders, it's simply the width of containingBlock. But now we get an infinite loop, since the same algorithm applies again:

• get the preferred minimum width of containingBlock

   foo
   +-------+
   | inner |
   +-------+
  |--?????--| preferred minimum width
  

In other words: to get the width of inner, we must know the width of containingBlock and vice versa.

In reality, it looks like browsers just assume available width = 0 in this case: http://jsfiddle.net/pxvJJ/6/. But this is not covered by the specs, or am I missing something obvious?

* _{(note that this spec has not yet been superseded by CSS3)}

解决方案

If we read carefully through the specs, we'll find that

CSS 2.1 does not define the exact [shrink-to-fit] algorithm.

It's supposed to be

similar to calculating the width of a table cell using the automatic table layout algorithm

which, in turn, is implementation-dependent.

So, the above example shows that excluding #inner from the calculation of containingBlock's preferred minimum width may be a good idea when implementing a straight-forward algorithm, and we'd end up with this:

|---| preferred minimum width
 foo
 +-------+
 | inner |
 +-------+
|--?????--|

which is probably what browsers do.

---

That being said, the question is: Which elements do actually contribute to containingBlock's preferred minimum width?

Let's see what happens if #inner has position:static; width: auto. This case is even harder. Again, the specs give the constraint

'margin-left' + 'border-left-width' + 'padding-left' + 'width' + 'padding-right' + 'border-right-width' + 'margin-right' = width of containing block

with no shrink-to-fit allowed this time. And, again, it cannot be solved. Or can it? Funny enough, it can! Let's see what actually happens: http://jsfiddle.net/pxvJJ/12/

Apparently, the statically positioned divs are treated differently. So I suppose the algorithm to determine width of containing block goes like this:

1. determine the preferred width of all contained block boxes in normal flow.
2. set width of containing block = maximum of those preferred widths
3. calculate the width of all contained boxes, now that width of containing block is known

I am still confused as to why (all) browsers do this. There seems to be no reason for treating absolutely positioned elements differently in this regard.

这篇关于如何确定嵌套绝对定位元素的宽度？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！