W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: [CSS21] 9.4.1 (Block formatting contexts) Definition - comments on Working Draft

From: Alan Gresley <alan@css-class.com>
Date: Sat, 08 Jan 2011 19:20:25 +1100
Message-ID: <4D281E49.1010008@css-class.com>
To: Anton Prowse <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
On 8/01/2011 7:50 AM, Anton Prowse wrote:
> An editorial suggestion:
> 9.4.1 (Block formatting contexts) says:
> # Floats, absolutely positioned elements, block containers (such as
> # inline-blocks, table-cells, and table-captions) that are not block
> # boxes, and block boxes with 'overflow' other than 'visible' (except
> # when that value has been propagated to the viewport) establish new
> # block formatting contexts.
> and 11.1.1 (Overflow: the 'overflow' property) says:
> # UAs must apply the 'overflow' property set on the root element to
> # the viewport. When the root element is an HTML "HTML" element or an
> # XHTML "html" element, and that element has an HTML "BODY" element
> # or an XHTML "body" element as a child, user agents must instead
> # apply the 'overflow' property from the first such child element to
> # the viewport, if the value on the root element is 'visible'. The
> # 'visible' value when used for the viewport must be interpreted as
> # 'auto'. The element from which the value is propagated must have a
> # used value for 'overflow' of 'visible'.
> So in fact if a block box whose 'overflow' other than 'visible' has been
> propagated to the viewport then its used value is 'visible' and so it's
> no longer under consideration is 9.4.1.

9.4.1 still comes into the equation. Please view these test.



If the used value of overflow was not propagated to the root element, 
then we would expect these test to render like IE7 (when the viewport is 
narrowed enough to cause visual overflow). The auto test shows this 
clearly in IE7.

Note: My JS does not seem to report the used value of the <body> (I'm 
expecting visible) though the overflow has been propagated to the viewport.

> In other words, 9.4.1 can be
> clarified as follows:
> s/block boxes with 'overflow' other than 'visible' (except when that
> value has been propagated to the viewport)/block boxes with used value
> of 'overflow' other than 'visible'/

No since overflow can be propagated to the root element. See test cases 

> The change from (presumably) computed value to used value in 9.4.1
> shouldn't cause any implementation difficulties because for all block
> boxes whose 'overflow' isn't propagated, the used value can only be
> other than visible if the computed value is also other than visible.

I think the later part of the above is correct. To my understanding, the 
computed value is not always the used value.

> Hence under my proposed change, it's known whether the block box
> establishes a BFC as soon as the computed value is calculated, just as
> it is with the current spec.
> I find 9.4.1 much easier to parse under this proposed change, not least
> because it strengthens the separation of Ch.11 from Ch.9.

What is Ch.11 and Ch.9?

> Note that under both formulations, the root element doesn't establish a
> block formatting context. This is conceptually questionable and is the
> subject of Issue 209.

I would go further than saying conceptually questionable.

Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Saturday, 8 January 2011 08:20:58 UTC

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