This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
17.4 (Tables in the visual formatting model) says: # The computed values of properties 'position', 'float', 'margin-*', # 'top', 'right', 'bottom', and 'left' on the table element are used # on the table wrapper box and not the table box; all other values of # non-inheritable properties are used on the table box and not the # table wrapper box. (Where the table element's values are not used # on the table and table wrapper boxes, the initial values are used # instead.) It seems that a wider set of properties should apply to table wrapper box instead of table box, as described in the comments below.
Reported by Simon Sapin Will a table box ever establish a new stacking context, or will that always be done by the table wrapper? Given currently that we have to choose whether a property affects the table box or the table wrapper box (and can't have both), it seems sensible to have all properties which induce stacking contexts apply to the table wrapper box. In particular, 'z-index' should act on the table wrapper box, and added weight is given by the fact that 'position' acts on the table wrapper box. [In general, 'opacity', 'transform', and other properties that can trigger a stacking context should specify that they act on the table wrapper box, in their respective specifications, until such time as the css3-table spec is created.] Conversation begins: Bug description: http://lists.w3.org/Archives/Public/www-style/2012May/0441.html
Reported by Simon Sapin The 'clear' property should also act on the table wrapper box since otherwise it's not possible to make table wrapper boxes clear floats in the same BFC. UAs seem to support this proposal. Bug report on a related test case, reported by Gérard Talbot: http://lists.w3.org/Archives/Public/www-style/2012Jun/0072.html . The test needs to include a floated caption box with zero margin area width in order to be relevant to the issue. Conversation begins: Bug description: http://lists.w3.org/Archives/Public/www-style/2012Jun/0065.html
UA behaviour report from David Baron: http://lists.w3.org/Archives/Public/www-style/2012Jun/0066.html In addition to 'clear' and 'z-index', Gecko propagates the following to the table wrapper box: 'vertical-align' (for inline-table) 'line-height' (for vertical-align on inline-table) [Also, the following CSS3 properties: 'page-break-before' 'page-break-after' (probably 'page-break-inside' too when it gets implemented) 'transform' 'transform-origin' (for https://bugzilla.mozilla.org/show_bug.cgi?id=722777) 'backface-visibility' (for https://bugzilla.mozilla.org/show_bug.cgi?id=724750) ]
Correction to faulty transcription of David's comment in Comment 3: The following properties are defined in CSS21, not CSS3: 'page-break-before' 'page-break-after' 'page-break-inside'
In response to Comment 3, Simon Sapin suggests the list of non-inheritable CSS21 properties to be used on the wrapper box should be: 'clear' 'z-index' 'vertical-align' 'page-break-before' 'page-break-after' 'page-break-inside' 'counter-reset' 'counter-increment' (He notes that 'line-height' is inherited.) [He also adds 'opacity' to the list of CSS3 properties.] http://lists.w3.org/Archives/Public/www-style/2012Jun/0396.html
Implementers raised a concern about whether 'overflow' should apply to the table wrapper box instead of to the table box.[1] The test http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/ is theoretically relevant to this bug, since the table box has a positive width border and hence it is possible to detect whether 'overflow' is being applied to the table box (and thus clipping the overflowing content at the table box's padding area) or to the parent wrapper box. Gecko, Webkit, Presto and Trident all pass this test. However, it turns out that the test doesn't capture the vagiaries of Webkit and Presto's behaviour. The attached test case below (based on one provided by Øyvind Stenhaug) demonstrates that Gecko and Trident (IE9) apply 'overflow' to the table box, whereas Webkit and Presto (Op12) seem to apply it to the table wrapper box but define the clipping area in a curious manner: it has the size of the table box's padding area in the horizontal dimension, and then it has the size of the table wrapper box's padding area in the vertical dimension (in the case of Webkit) or the size of the table wrapper box's padding area minus the sum of the table box's vertical border widths in the vertical dimension (in the case of Presto). [1] http://lists.w3.org/Archives/Public/www-style/2012Jun/0656.html [2] http://lists.w3.org/Archives/Public/www-style/2011Jul/0462.html
Created attachment 1158 [details] Test to illustrate whether 'overflow' has its effect on the table box or the table wrapper box
Created attachment 1166 [details] Test to illustrate whether 'overflow' has its effect on the table box or the table wrapper box (Revised attachment which fixes an HTML validation error.)
Regarding Comments 6 and 8: The WG resolved[1] that 'overflow' has its effect on the table box of a table element, not the table wrapper box. [1] http://lists.w3.org/Archives/Public/www-style/2012Aug/0298.html