Bug 17505 - Wider set of properties should apply to table wrapper box instead of table box
Summary: Wider set of properties should apply to table wrapper box instead of table box
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: CSS Level 2 (show other bugs)
Version: unspecified
Hardware: All Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Bert Bos
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-16 09:39 UTC by Anton P
Modified: 2012-12-04 00:50 UTC (History)
0 users

See Also:


Attachments
Test to illustrate whether 'overflow' has its effect on the table box or the table wrapper box (1.43 KB, text/html)
2012-07-15 11:44 UTC, Anton P
Details
Test to illustrate whether 'overflow' has its effect on the table box or the table wrapper box (1.44 KB, text/html)
2012-08-02 06:46 UTC, Anton P
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anton P 2012-06-16 09:39:43 UTC
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.
Comment 1 Anton P 2012-06-16 09:54:26 UTC
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
Comment 2 Anton P 2012-06-16 10:10:40 UTC
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
Comment 3 Anton P 2012-06-16 10:18:12 UTC
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)
]
Comment 4 Anton P 2012-06-16 12:08:58 UTC
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'
Comment 5 Anton P 2012-06-24 14:25:49 UTC
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
Comment 6 Anton P 2012-07-15 11:36:32 UTC
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
Comment 7 Anton P 2012-07-15 11:44:43 UTC
Created attachment 1158 [details]
Test to illustrate whether 'overflow' has its effect on the table box or the table wrapper box
Comment 8 Anton P 2012-08-02 06:46:49 UTC
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.)
Comment 9 Anton P 2012-08-09 05:37:38 UTC
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