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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 07 Jan 2011 21:50:55 +0100
Message-ID: <4D277CAF.4020207@moonhenge.net>
To: "www-style@w3.org" <www-style@w3.org>
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.  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'/

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. 
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.

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.

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Friday, 7 January 2011 20:51:27 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:35 GMT