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

Re: [CSS21] 10.6.1, 10.6.3 and 10.6.7 - editorial issues

From: Peter Moulder <peter.moulder@monash.edu>
Date: Wed, 04 Aug 2010 17:58:23 +1000
To: www-style@w3.org
Message-id: <20100804075823.GA8516@bowman.infotech.monash.edu.au>
On Tue, Aug 03, 2010 at 11:39:47PM -0700, fantasai wrote:
> On 08/02/2010 11:44 PM, Peter Moulder wrote:
> >On Mon, Aug 02, 2010 at 03:51:48PM -0700, fantasai wrote:
> >>On 08/01/2010 09:44 PM, Peter Moulder wrote:
> >>>
> >>>[...]
> >>>I'm also content with the existing approach of "certain cases (see ...)"
> >>>if instead the following changes were made [assuming I'm correct about
> >>>when the rules of section 10.6.7 do apply]:
> >>>
> >>>   - Change "(see the preceding sections)" to
> >>>     ["(see sections 10.6.4 and 10.6.6)"].
> >
> >>Changed "(see the preceding sections)" to
> >>"(see e.g. sections 10.6.4 and 10.6.6)"
> >>since it is probably not an exhaustive list.
> >
> >I'm not sure I understand; why do you say that?
> Table cells, for example, follow the same rules when calculating
> their preferred widths. And any block formatting context roots
(I assume you actually meant to write `heights' here.)

> introduced in CSS3 will also follow those rules in certain
> circumstances.

OK.  I think the relevant text in tables.html is just "the minimum height
required by the content", which would be why I didn't find it.

I also wonder whether it's intended that 10.6.7 rules apply to table-caption
and anonymous table wrapper boxes, which I think are the only other block
formatting context roots in CSS2.1.

I see that gecko and webkit get different answers to the question of whether
table-captions include or ignore their floats when determining their height
(at least with the relatively old versions I have handy).

As fantasai's comment would suggest, both gecko and webkit consider the float
as part of "the height required by the content".

Ultimately, the right approach for 10.6.7 may well be to use the "block
formatting context roots" approach rather than the "certain cases" approach;
though that would have to wait until after the element/box cleanup, and when
it's clearer what boxes do establish new block formatting contexts.

(Test case for table-captions appended if you're interested.  I haven't checked
it carefully.)


<title>Test of height rules for block formatting context roots</title>
<p>Section 17.4 says that table-caption boxes are block-level boxes,
and the opinion on www-style seems to be that it's intended that they follow
section 10.6.3 rules for determining their heights, i.e. that the height ignores
any floats.  However, section 9.4.1 says that table-captions establish new block formatting
contexts, so I wonder whether section 10.6.7 rules would instead apply, where
the height includes any floats that belong to that block formatting context.</p>

<div style="display:table; background-color: #9f9;">
<div style="display:table-row;"><div style="display:table-cell;">A table cell.  We give it lots of text to make it wide and thus make the anonymous table wrapper box wide.<p style="float:right; width: 10em;">We also give it a float, to check whether the table cell's height includes or ignores the float.</p></div></div>
<div style="display:table-caption; caption-side: bottom; background-color: #f79;"><p style="float:left; width: 10em; margin: 0.2em;">This is a float, which I hope will be tall enough to extend well past the rest of the caption.</p>This is the main caption text.</div>
<div style="display:table-caption; caption-side: bottom; background-color: #f97;">This is the second caption.</div>
<p>Here's some text below the table.  Its position should indicate the height of the anonymous table wrapper box, if we want to test collapsing margin behaviour.</p>
<p>Result: both gecko and webkit include the float in the table cell's height.  In gecko the table-caption includes its float in its height, while in webkit the height ignores the float.  Neither show the second caption, for some reason; I haven't checked that they should.</p>
Received on Wednesday, 4 August 2010 07:58:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:28:14 UTC