- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 02 Aug 2010 15:37:33 -0700
- To: Anton Prowse <prowse@moonhenge.net>
- CC: "www-style@w3.org" <www-style@w3.org>
On 08/01/2010 11:22 AM, Anton Prowse wrote: > 10.6.7 ('Auto' heights for block formatting context roots) says:[1] > > # In addition, if the element has any floating descendants whose > # bottom margin edge is below the bottom, then the height is increased > # to include those edges. Only floats that are children of the element > # itself or of descendants in the normal flow are taken into account, > # e.g., floats inside absolutely positioned descendants or other > # floats are not. > > Issue 1: > > s/below the bottom/below the bottom of the content area/ Assumed editorial. Replaced with "the element's bottom content edge". > Issue 2: > > The second sentence is clumsy and misses some important cases. Floats > that are children of child inline-blocks, tables or inline-tables should > also be excluded. The sentence needs replacing with > > | Only floats which are participate in this block formatting context > | taken into account. > > and the first sentence of the section modified as follows: > > | In certain cases (see the preceding sections), the height of an > | element is computed as follows: > > s/element/element that establishes a block formatting context/ Assumed editorial. Fixed. > It's possible, however, that 10.6.7 is being deliberately decoupled from > BFCs, perhaps for use on non-BFCs in future CSS levels. (Although note > that the title mentions BFCs.) In this case, the faulty sentence will > simply have to list the exceptions in full. At this point it seems unlikely that anything other than a block box would be treated as a non-BFC block container. > Issue 3: > > 10.6.1 (Inline, non-replaced elements), 10.6.3 (Block-level non-replaced > elements in normal flow when 'overflow' computes to 'visible') and > 10.6.7 ('Auto' heights for block formatting context roots) claim to > describe element behaviour, but are really describing box behaviour. If > this doesn't get cleaned up,(*) I think it would instead be worthwhile > to clearly state in 10.6.1 and 10.6.3 that those subsections apply to > anonymous boxes. > > (*) Besides the box under consideration, the many mentions of children > and descendants in these sections also refer to boxes, since those terms > leave various gaps (generated content, "loose" content without an > inline-level parent, etc) when taken only in the context of elements. Generated content is associated with pseudo-elements; most, if not all, of the spec's layout sections treats these as regular elements. I don't want to tackle box vs. element here. It's really, really hard for me to deal with issues when they're tangled up together in a single thread. ~fantasai
Received on Monday, 2 August 2010 22:38:09 UTC