- 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