- From: Arron Eicholz <Arron.Eicholz@microsoft.com>
- Date: Wed, 16 Mar 2011 22:42:21 +0000
- To: Anton Prowse <prowse@moonhenge.net>
- CC: "www-style@w3.org" <www-style@w3.org>
On Friday, January 07, 2011 12:51 PM 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. 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. > Thank you for your feedback. The CSSWG resolved not to make these changes to the CSS 2.1 specification[1]. We will be reevaluating this issue for errata and future versions of CSS. Please respond before 18 March, 2011 if you do not accept the current resolution. [1] http://w3.org/TR/CSS
Received on Wednesday, 16 March 2011 22:42:54 UTC