W3C home > Mailing lists > Public > www-style@w3.org > October 2010

Re: [CSS21] Issue 142: the term "ancestor box"

From: Bert Bos <bert@w3.org>
Date: Wed, 6 Oct 2010 18:28:14 +0200
To: W3C style mailing list <www-style@w3.org>
Message-Id: <201010061828.14389.bert@w3.org>
On Monday 23 August 2010 04:22:24 Boris Zbarsky wrote:
> On 8/22/10 9:19 AM, Bert Bos wrote:
> > This is proposed text for issue 142[1]. Section 10.1 uses the term
> > "ancestor box," by which it means the "box of an ancestor element."
> > But apparently the term causes confusion. That is probably because
> > in some cases and in some implementations the boxes form a tree.
> > (CSS doesn't say that the boxes form a tree, only that each box is
> > associated with an element and the elements form a tree.)
> >
> > So here is a rewrite to avoid the term. The following all occur in
> > section 10.1:
> >
> >    - Replace the first occurrence of "ancestor box" by "ancestor
> >      element".
> This doesn't give correct behavior with table anonymous boxes, as far
> as I can tell.  Specifically, given this markup:
>    <div id="outer">
>      <div id="row" style="display: table-row">
>        <div id="inner"/>
>      </div>
>    </div>
> the proposed wording makes the "outer" div the containing block of
> the "inner" one, whereas the desired containing block, and the one
> all UAs use in practice, is the content edge of the anonymous
> table-cell box generated between the table-row and the "inner" block

Is that really desired? It seems to me that the anonymous table cell 
isn't a good choice for a containing block, because you cannot put 
properties on it. If the "inner" element has 'width: 50%', you want 
that to be 50% of something that you can control. The "outer" element 
fits that bill.

(The example is a bit artificial, too. When you use table layout, you 
typically have at least a 'display: table' or a 'display-table-cell' 

> (which does not have an element associated with it, last I checked,
> contrary to the "each box is associated with an element" claim above,
> by the way).

The anonymous table cell is one of the boxes of the "row" element, in my 
view. That element has, in this example, two boxes: a row and a cell 
(which happen to coincide).

> I haven't thought through other possible issues so far past that.

After applying issue 120[1], bullet point 2 of section 10.1 reads:

   2. For other elements [i.e., other than the root element. BB], if the
      element's position is 'relative' or 'static', the containing block
      is formed by the content edge of the nearest block container
      ancestor box.

Where "block container box" is defined in 9.2.1 as: "A block container 
box either contains only block-level boxes or establishes an inline 
formatting context and thus contains only inline-level boxes."

That makes my original suggestion of replacing "ancestor box" 
by "ancestor element" impossible. We somehow have to keep the three 
words "block container box" and replace "ancestor" with something 
before or after that term.

The decision on issue 198 (about the containing block of a float inside 
a run-in) introduces an exception to the rule that the containing block 
is found by walking up the element tree: it states that the containing 
block of such a float is the content edge of the element that the run-in 
runs in to.

Combining that, bullet 2 of section 10.1 could become:

   2. For other elements, if the element's position is 'relative'
      or 'static', the containing block is one of the following:
         a. If the element is a 'run-in' that is rendered inline in a
            sibling element, then its containing block is the content
            edge of the principal box of that sibling.
         b. Otherwise, if the parent has a principal box that is a block
            container box (e.g., if the parent is a 'table-cell' or
            a 'block'), then the containing block is the content edge of
            the parent's principal box.
         c. Otherwise the containing block is the same as that of the

Still no anonymous boxes that establish containing blocks, and I think 
that is correct. Take this example:

    <div id=outer style="height: 20em">
      Some text <button style="height: 50%">before</button> the image.
      <img src="x.png" alt="x" style="display: block">

The text is wrapped in an anonymous block box, but the height 
of the BUTTON is 50% of the "outer" element, not of that anonymous box.

Here is another example, a variation of Boris's:

    <div id="outer">
      <div id="cell" style="display: table-cell">
        <div id="inner"/>

The containing block of "inner" is the content edge of "cell", because 
"cell" is a block container.

Another variation, very similar to the one above:

    <div id="outer">
      <div id="table" style="display: table">
        <div id="inner"/>

The containing block of "inner" is the content edge of "table", because 
"table" is a block container.

Boris's original example is different, because a row box is not a block 

    <div id="outer" style="height: 20em">
      <div id="row" style="display: table-row">
        <div id="inner" style="height: 50%"/>

The containing block of "inner" is now the content edge of "outer." If 
that is surprising, then maybe the issue is that the table row is not 
considered. I don't believe it is a problem that the anonymous cell is 
ignored. After all, you can't even see it.

[1] http://wiki.csswg.org/spec/css2.1#issue-120

> >    - Replace the occurrence of "ancestor boxes" (in the example) by
> >      "ancestor elements".
> >
> >    - Replace the phrase "the nearest positioned ancestor box" (at
> > the end of the example) by "the padding edge of the nearest
> > positioned ancestor".
> These changes look fine.
> -Boris

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Wednesday, 6 October 2010 16:29:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:39 UTC