• Harmonize the table-root border-{top,bottom,left,right} with the corresponding border of all cells forming the border of the table (indenpendently), without actually modifying the border properties of the table-root.
  
  If the table and the cell border styles have the same specificity, keep the cell border style.
  Once this is done, set the table-root border-{…}-width to half the maximum width found during the harmonization processes for that border, then set border-{…}-style to solid, and border-{…}-color to transparent.

Harmonization Algorithm for Collapsed Borders

• Set CurrentlyWinningBorderProperties to “border: 0px none transparent”
• For each border BC_i:
  • Consider the BC_i border’s properties
• If the border separates two columns:
  • For each border BC_i: For each table-column spanned by the C_i cell, if any. Consider the border’s properties of any border of the table-column that would be drawn contiguously to BC_i.
  • For each border BC_i: For each table-column-group containing a column spanned by the C_i cell, if any. Consider the border’s properties of any border of the table-column-group that would be drawn contiguously to BC_i.
• If the border separates two rows:
  • For each border BC_i: For each table-row spanned by the C_i cell, if any. Consider the border’s properties of any border of the table-column that would be drawn contiguously to BC_i.
  • For each border BC_i: For each table-row-group containing a column spanned by the C_i cell, if any. Consider the border’s properties of any border of the table-row-group that would be drawn contiguously to BC_i.
• Return CurrentlyWinningBorderProperties

Specificity of a border style

1. … has the value "hidden" as 'border-style', if only one does
2. … has the biggest 'border-width', once converted into css pixels
3. … has the 'border-style' which comes first in the following list:

   double, solid, dashed, dotted, ridge, outset, groove, inset, none

Computing table measures

Computing Undistributable Space

Computing Cell Measures

cell intrinsic offsets

The cell intrinsic offsets is a term to capture the parts of padding and border of a table cell that are relevant to intrinsic width calculation. It is a set of computed values for border-left-width, padding-left, padding-right, and border-right-width (along with zero values for margin-left and margin-right) defined as follows:

• In separated-borders mode: the computed horizontal padding and border of the table-cell
• In collapsed-borders mode: the computed horizontal padding of the cell and, for border values, the used border-width values of the cell (half the winning border-width)

table intrinsic offsets

The table intrinsic offsets capture the parts of the padding and border of a table that are relevant to intrinsic width calculation. It is a set of computed values for border-left-width, padding-left, padding-right, and border-right-width (along with zero values for margin-left and margin-right) defined as follows:

• In separated-borders mode: the computed horizontal padding and border of the table-root
• In collapsed-borders mode: the used border-width values of the cell (half the winning border-width)

The margins are not included in the table intrinsic offsets because handling of margins depends on the 'caption-side' property. ISSUE(608): Handling of intrinsic offsets when in border collapsing mode

total horizontal border spacing

The total horizontal border spacing is defined for each table:

• For tables laid out in separated-borders mode containing at least one column, the horizontal component of the computed value of the border-spacing property times one plus the number of columns in the table
• Otherwise, 0

offsets-adjusted min-width, width, and max-width

• For table-track and table-track-group boxes, the offsets-adjusted value of width properties is their computed value, irrespective of the value of 'box-sizing' applied on the element.
• For table-cell boxes, the offsets-adjusted value of width properties is their computed value from which the cell's border-{left|right}-width and/or padding-{left|right} have eventually been deduced, depending on the value of 'box-sizing'.
  When the table is laid out in collapsed-borders mode, the border value to deduce is half the value of the winning border value on each side (see conflict resolution explaination note)

Testcase. Testcase. Testcase.

outer min-content and outer max-content widths

The outer min-content and max-content widths are defined for table cells, columns, and column groups. The 'width', 'min-width', and 'max-width' values used in these definitions are the offsets-adjusted values defined above:

• The outer min-content width of a table-cell is max('min-width', min-content width) adjusted by the cell intrinsic offsets.
• The outer min-content width of a table-column or table-column-group is max('min-width', 'width').
• The outer max-content width of a table-cell in a non-constrained column is max('min-width', 'width', min-content width, min('max-width', max-content width)) adjusted by the cell intrinsic offsets.
• The outer max-content width of a table-cell in a constrained column is max('min-width', 'width', min-content width, min('max-width', 'width')) adjusted by the cell intrinsic offsets.
• The outer max-content width of a table-column or table-column-group is max('min-width', min('max-width', 'width')).

percentage contributions

The percentage contribution of a table cell, column, or column group is defined in terms of the computed values of 'width', 'max-width', and 'min-width' that have computed values that are percentages:

min(percentage 'width', percentage 'max-width').

If the computed values are not percentages, then 0% is used for 'width', and an infinite percentage is used for 'max-width'.

Please note that 'min-width' is not included in this computation. As a result, a percentage 'min-width' is ignored. Since 'width' functions like a 'min-width' in table layout and column sizing cannot be both length-based and percent-based, authors should not use 'min-width' on table-internal boxes and prefer to rely on 'width' only instead.

Computing Column Measures

To compute these values, an iterative algorithm is used. First, these values are computed ignoring any cell spanning more than one column. Then, these values are updated by taking into account cells spanning incrementally more columns. When cells that spanned all columns of the table have been considered, this algorithm ends and the values are then finalized.

For the purpose of measuring a column when laid out in fixed mode, only cells which originate in the first row of the table (after reordering the header and footer) will be considered, if any. In addition, the min-content and max-content width of cells is considered zero unless they are directly specified as a length-percentage, in which case they are resolved based on the table width (if it is definite, otherwise use 0). For the purpose of calculating the outer min-content width of cells, descendants of table cells whose width depends on percentages of their parent cell' width are considered to have an auto width. Testcase Testcase

min-content width of a column based on cells of span up to 1

The largest of:

• the width specified for the column:
  • the outer min-content width of its corresponding table-column, if any (and not auto)
  • the outer min-content width of its corresponding table-column-group, if any
  • or 0, if there is none
• the outer min-content width of each cell that spans the column whose colSpan is 1 (or just the one in the first row in fixed mode) or 0 if there is none

max-content width of a column based on cells of span up to 1

The largest of:

• the outer max-content width of its corresponding table-column-group, if any
• the outer max-content width of its corresponding table-column, if any
• the outer max-content width of each cell that spans the column whose colSpan is 1 (or just the one in the first row if in fixed mode) or 0 if there is no such cell

intrinsic percentage width of a column based on cells of span up to 1

The largest of the percentage contributions of each cell that spans the column whose colSpan is 1, of its corresponding table-column (if any), and of its corresponding table-column-group (if any)

min-content width of a column based on cells of span up to N (N > 1)

the largest of the min-content width of the column based on cells of span up to N-1 and the contributions of the cells in the column whose colSpan is N, where the contribution of a cell is the result of taking the following steps:

1. Define the baseline min-content width as the sum of the max-content widths based on cells of span up to N-1 of all columns that the cell spans.
2. Define the baseline border spacing as the sum of the horizontal border-spacing for any columns spanned by the cell, other than the one in which the cell originates.
3. The contribution of the cell is the sum of:
   • the min-content width of the column based on cells of span up to N-1
   • the product of:
     • the ratio of:
       • the max-content width of the column based on cells of span up to N-1 of the column minus the min-content width of the column based on cells of span up to N-1 of the column, to
       • the baseline max-content width minus the baseline min-content width
       or zero if this ratio is undefined, and
     • the outer min-content width of the cell minus the baseline min-content width and the baseline border spacing, clamped to be at least 0 and at most the difference between the baseline max-content width and the baseline min-content width
   • the product of:
     • the ratio of the max-content width based on cells of span up to N-1 of the column to the baseline max-content width
     • the outer min-content width of the cell minus the baseline max-content width and baseline border spacing, or 0 if this is negative

max-content width of a column based on cells of span up to N (N > 1)

The largest of the max-content width based on cells of span up to N-1 and the contributions of the cells in the column whose colSpan is N, where the contribution of a cell is the result of taking the following steps:

1. Define the baseline max-content width as the sum of the max-content widths based on cells of span up to N-1 of all columns that the cell spans.
2. Define the baseline border spacing as the sum of the horizontal border-spacing for any columns spanned by the cell, other than the one in which the cell originates.
3. The contribution of the cell is the sum of:
   • the max-content width of the column based on cells of span up to N-1
   • the product of:
     • the ratio of the max-content width based on cells of span up to N-1 of the column to the baseline max-content width
     • the outer max-content width of the cell minus the baseline max-content width and the baseline border spacing, or 0 if this is negative

intrinsic percentage width of a column based on cells of span up to N (N > 1)

If the intrinsic percentage width of a column based on cells of span up to N-1 is greater than 0%, then the intrinsic percentage width of the column based on cells of span up to N is the same as the intrinsic percentage width of the column based on cells of span up to N-1.

Otherwise, it is the largest of the contributions of the cells in the column whose colSpan is N, where the contribution of a cell is the result of taking the following steps:

1. Start with the percentage contribution of the cell.
2. Subtract the intrinsic percentage width of the column based on cells of span up to N-1 of all columns that the cell spans. If this gives a negative result, change it to 0%.
3. Multiply by the ratio of
   • the column's non-spanning max-content width to
   • the sum of the non-spanning max-content widths of all columns spanned by the cell that have an intrinsic percentage width of the column based on cells of span up to N-1 equal to 0%.
   However, if this ratio is undefined because the denominator is zero, instead use the 1 divided by the number of columns spanned by the cell that have an intrinsic percentage width of the column based on cells of span up to N-1 equal to zero.

min-content width of a column

the min-content width of the column based on cells of span up to N, where N is the number of columns in the table

max-content width of a column

the max-content width of the column based on cells of span up to N, where N is the number of columns in the table

intrinsic percentage width of a column

the smaller of:

• the intrinsic percentage width of the column based on cells of span up to N, where N is the number of columns in the table
• 100% minus the sum of the intrinsic percentage width of all prior columns in the table (further left when direction is "ltr" (right for "rtl")) Testcase

The clamping of the total of the intrinsic percentage widths of columns to a maximum of 100% means that the table layout algorithm is not invariant under switching of columns.

constrainedness

A column is constrained if its corresponding table-column-group (if any), its corresponding table-column (if any), or any of the cells spanning only that column has a computed 'width' that is not "auto", and is not a percentage.

Available Width Distribution

Computing the table width

As noted before, this would usually be the sum of preferred width of all columns, plus any extra. In this case, the width distribution will result in giving each column its preferred width. There are however a few cases where the author asks for some other width explicitly, as well as a few cases where the table cannot be given the width it requires. The caption width minimum (CAPMIN) is the largest of the table captions min-content contribution. The row/column-grid width minimum (GRIDMIN) width is the sum of the min-content width of all the columns plus cell spacing or borders. The row/column-grid width maximum (GRIDMAX) width is the sum of the max-content width of all the columns plus cell spacing or borders. The used width of a table depends on the columns and captions widths as follows:

• If the table-root's 'width' property has a computed value (W) other than auto, the used width is the greater of W, CAPMIN, and GRIDMIN.
  If the used width is greater than GRIDMIN, the extra width should be distributed over the columns. See [[#width-distribution]].
• If the table-root has 'width: auto', the used width is the greater of min(GRIDMAX, the table's containing block width), CAPMIN, and GRIDMIN.

Core distribution principles

This section is not normative.

Rules

Rule 0: In fixed mode, auto and percentages columns are assigned a minimum width of zero pixels, and percentage resolution follows a different set of rules, whose goal is to ensure pixel columns always get assigned their preferred width.

Rule 1: When assigning preferred widths, specified percent columns have a higher priority than specified unit value columns, which have a higher priority than auto columns.

Rule 2: Columns using the same sizing type (percent columns, pixel columns, or auto columns) follow the same distribution method. For example, they all get their min-content width or they all get their max-content width.
There is one exception to this rule. When giving its preferred percent width to a percent-column, if that would result in a size smaller than its min-content width, the column will be assigned its min-content width instead though the percent-columns group as a whole is still regarded as being assigned the preferred percent widths.

Rule 3: The sum of width assgined to all columns should be equal to the assignable table width.

Available sizings

1. min-content width:
   The size required to fit the content of the column
2. min-content width + delta:
   A value between the min-content and preferred widths
3. preferred width:
   The size specified for the column, or the size required to fit the content of the column without breaking
4. preferred width + delta
   A value larger than the preferred width

Distribution algorithm

1. The min-content sizing-guess is the set of column width assignments where each column is assigned its min-content width.
2. The min-content-percentage sizing-guess is the set of column width assignments where:
   • each percent-column is assigned the larger of:
     • its intrinsic percentage width times the assignable width and
     • its min-content width.
   • all other columns are assigned their min-content width.
3. The min-content-specified sizing-guess is the set of column width assignments where:
   • each percent-column is assigned the larger of:
     • its intrinsic percentage width times the assignable width and
     • its min-content width
   • any other column that is constrained is assigned its max-content width
   • all other columns are assigned their min-content width.
4. The max-content sizing-guess is the set of column width assignments where:
   • each percent-column is assigned the larger of:
     • its intrinsic percentage width times the assignable width and
     • its min-content width
   • all other columns are assigned their max-content width.

The following schema describes the algorithm in a different way, to make it easier to understand.

Legend

Sizing algorithms: Each drawing of the table represents a way of sizing the columns. The four cases on the left are the sizing-guesses described above in the spec: min-content, min-content-percentage, min-content-specified, and max-content. The cases on the right are interpolations required for available sizes that do not match exactly one of the four sizing-guesses. Choice of sizing method: The sizing method selection always starts at the min-content sizing-guess (top left), and then proceeds by comparing the available width and the width consumed by the method currently in use. Green arrows indicate the direction you should follow if you have extra space to distribute after applying the current method. Red arrows indicate the direction you should follow if you have distributed too much space by applying the current method and need to backtrack. Columns types: Each type of column (auto, px, %) has its own color in the schema (yellow, blue, orange). In an interpolation: columns that get shrinked down from their size in previous sizing-guess are repainted red, and columns that get expanded from their size in previous sizing-guess are repainted green.

Changes to width distribution in fixed mode

Distributing excess width to columns

• for distributing the excess width of a table to its columns during the computation of the used widths of those columns (for used width calculation), or
• for distributing the excess max-content or min-content width of a cell spanning more than one column to the max-content or min-content widths of the columns it spans (for intrinsic width calculation).

1. If there are non-constrained columns that have originating cells with intrinsic percentage width of 0% and with nonzero max-content width (aka the columns allowed to grow by this rule), the distributed widths of the columns allowed to grow by this rule are increased in proportion to max-content width so the total increase adds to the excess width.
2. Otherwise, if there are non-constrained columns that have originating cells with intrinsic percentage width of 0% (aka the columns allowed to grow by this rule, which thanks to the previous rule must have zero max-content width), the distributed widths of the columns allowed to grow by this rule are increased by equal amounts so the total increase adds to the excess width.
3. Otherwise, if there are (constrained) columns with intrinsic percentage width of 0% and with nonzero max-content width (aka the columns allowed to grow by this rule, which, due to other rules, must have originating cells), the distributed widths of the columns allowed to grow by this rule are increased in proportion to max-content width so the total increase adds to the excess width.
4. Otherwise, if there are columns with intrinsic percentage width greater than 0% (aka the columns allowed to grow by this rule, which, due to other rules, must have originating cells), the distributed widths of the columns allowed to grow by this rule are increased in proportion to intrinsic percentage width so the total increase adds to the excess width.
5. Otherwise, if there is any such column, the distributed widths of all columns that have originating cells are increased by equal amounts so the total increase adds to the excess width.
6. Otherwise, the distributed widths of all columns are increased by equal amounts so the total increase adds to the excess width.

Available Height Distribution

Computing the table height

?Testcase ?Testcase ?Testcase The height of a table is the sum of the row heights plus any cell spacing or borders. If the table has a 'height' property with a value other than auto, it is treated as a minimum height for the table grid, and will eventually be distributed to the height of the rows. The minimum height of a row is the maximum of:

• the computed 'height' (if definite, percentages being considered 0px) of its corresponding table-row (if nay)
• the computed 'height' of each cell spanning the current row exclusively (if definite, percentages being treated as 0px), and
• the minimum height (ROWMIN) required by the cells spanning the row.

To clarify the preceding statements, here is a table of the resulting "A" div height based on the value being used: <section style="height: var(--wrapper-height)"> <table style="height: var(--table-height)"> <tr> <td style="height: var(--table-cell-height)"> <div style="height:100%; background:yellow">A</div> </td> <td style="height: var(--other-table-cell-height)"> B<br>C </td> </tr> </table> </section>

--table-cell-height	--table-height	result
<length>	<any>
<any>	<length>
<any>	<percentage>
auto	auto
<percentage>	auto

Note that neither --other-table-cell-height nor --wrapper-height do influence the algorithm's outcome. A previous version of this specification incorrectly stated that --wrapper-height was taken into account when the table had a percentage height, but compat issues appeared when an implementation landed, and the behavior was then special-cased.

Row layout

baseline of a cell is defined as the baseline of the first in-flow line box in the cell, or the first in-flow table-row in the cell, whichever comes first. If there is no such line box or table-row, the baseline is the bottom of content edge of the cell box.

Here is how this works out in practice: td { vertical-align: baseline; outline: 3px solid silver; } img { float: left; clear: left; width: 32px; height: 32px; } img[title] { float: none; } <table><tr> <td>Baseline</td> <td>Baseline<table><tr><td>After</td></tr></table></td> <td><table><tr><td>Baseline</td></tr></table>After</td> <td><table align=right><tr><td>Before</td></tr></table><p>Baseline</p></td> <td><img src="http://w3.org/favicon.ico" /><p>Baseline</p></td> <td><img src="http://w3.org/favicon.ico" title="Baseline"/><br/><img src="http://w3.org/favicon.ico" title="After"/></td> <td><img src="http://w3.org/favicon.ico" /><img src="http://w3.org/favicon.ico" /><!--Baseline--></td> </tr></table>

For the purposes of finding a baseline, in-flow boxes with a scrolling mechanisms (see the 'overflow' property) must be considered as if scrolled to their origin position.

The baseline of a cell may end up below its bottom border, see the example below.

The cell in this example has a baseline below its bottom border: div { height: 0; overflow: hidden; } <table> <tr> <td> <div> Test </div> </td> </tr> </table>

The 'vertical-align' property of each table cell determines its alignment within the row. Each cell's content has a baseline, a top, a middle, and a bottom, as does the row itself. In the context of table cells, values for 'vertical-align' have the following meanings:

baseline	The baseline of the cell is aligned with the baseline of the other cells of the first row it spans (see the definition of baselines of cells and rows).
top	The top of the cell box is aligned with the top of the first row it spans.
bottom	The bottom of the cell box is aligned with the bottom of the last row it spans.
middle	The center of the cell is aligned with the center of the rows it spans.
...	Other values do not apply to cells; the cell is aligned at the baseline instead.

The maximum distance between the top of the cell box and the baseline over all cells that have 'vertical-align: baseline' is used to set the baseline of the row. If a row doesn't have any cell that has 'vertical-align: baseline', the baseline of that row is the bottom content edge of the lowest cell in the row. The baseline of a table-root is the baseline of its first row, if any. Otherwise, it is the bottom content edge of the table-root. Testcase !!Testcase

To avoid ambiguous situations, the alignment of cells proceeds in the following order:

• First the cells that are aligned on their baseline are positioned. This will establish the baseline of the row.
• Next the cells with 'vertical-align: top' are positioned. The row now has a top, possibly a baseline, and a provisional height, which is the distance from the top to the lowest bottom of the cells positioned so far.
• If any of the remaining cells, those aligned at the bottom or the middle, have a height that is larger than the current height of the row, the height of the row will be increased to the maximum of those cells, by lowering the bottom.
• Finally, assign their position to the remaining cells.

Example showing how the previous algorithm creates the various alignment lines of a row.

Since during row layout the specified heights of cells in the row were ignored and cells that were spanning more than one rows have not been sized correctly, their height will need to be eventually distributed to the set of rows they spanned. This is done by running the same algorithm as the column measurement, with the span=1 value being initialized (for min-content) with the largest of the resulting height of the previous row layout, the height specified on the corresponding table-row (if any), and the largest height specified on cells that span this row only (the algorithm starts by considering cells of span 2 on top of that assignment).

EDITORIAL. Import the relevant section of [[#computing-column-measures]] here.

Rows that see their size increase as a result of applying these steps adjust by lowering their bottom.

The cells whose position depended on the bottom of any updated row must be positioned correctly again in their respective rows. At this point, cell boxes that are smaller than the collective height of the rows they span receive extra top and/or bottom padding such that their content does not move vertically but their top/bottom edges meet the ones of the first/last row they span.

Please note that heights being defined on row groups are being ignored by this algorithm

Core distribution principles

EDITORIAL. TODO. For current proposal, skip to [[#height-distribution-algorithm]].

Investigations on height distribution

Distribution algorithm

The first step is to attribute to each row its base size and its reference size. Its base size is the size it would have got if the table didn’t have a specified height (the one it was assigned when ROWMIN was evaluated). Its reference size is the largest of

• its initial base height and
• its new base height (the one evaluated during the second layout pass, where percentages used in rowgroups/rows/cells' specified heights were resolved according to the table height, instead of being ignored as 0px).

The second step is to compute the final height of each row based on those sizes. If the table height is equal or smaller than sum of reference sizes, the final height assigned to each row will be the weighted mean of the base and the reference size that yields the correct total height. Else, if the table owns any “auto-height” row (a row whose size is only determined by its content size and none of the specified heights), each non-auto-height row receives its reference height and auto-height rows receive their reference size plus some increment which is equal to the height missing to amount to the specified table height divided by the amount of such rows. Else, all rows receive their reference size plus some increment which is equal to the height missing to amount to the specified table height divided by the amount of rows.

The cells whose position depended on the bottom of any updated row must be positioned correctly again in their respective rows. At this point, cell boxes that are smaller than the collective height of the rows they span receive extra top and/or bottom padding such that their content does not move vertically but their top/bottom edges meet the ones of the first/last row they span.

Positioning of cells, captions and other internal table boxes

ISSUE(478): We need a resolution on what visibility:collapse does. Once the width of each column and the height of each row of the table grid has been determined, the final step of algorithm is to assign to each table-internal box its final position. The table-wrapper box is then sized such that it contains the margin box of all table-non-root boxes as well as the table-root border-box.

The position defined here is the position of the children inside the space reserved for the table-wrapper, which excludes only its margins. This is because the captions of the table are located outside the border-box area of the table-root.

The position of any table-caption having "top" as 'caption-side' within the table is defined as the rectangle whose:

• width/height is:
  • the width/height assigned to the caption during layout
• top location is the sum of:
  • the height reserved for previous top captions (including margins), if any
  • any necessary extra top margin remaining after collapsing margins with the previous caption, if any.
• left location is the sum of:
  • the margin left of the caption
  • half of (the table width minus the width of caption and its total horizontal margin).

The position of any table-cell, table-track, or table-track-group box within the table is defined as the rectangle whose:

• width/height is the sum of:
  • the widths/heights of all spanned visible columns/rows
  • the horizontal/vertical 'border-spacing' times the amount of spanned visible columns/rows minus one
• left/top location is the sum of:
  • for top: the height reserved for top captions (including margins), if any
  • the padding-left/padding-top and border-left-width/border-top-width of the table
  • the widths/heights of all previous visible columns/rows
  • the horizontal/vertical 'border-spacing' times the amount of previous visible columns/rows plus one

Reminder: For table-track and table-track-group boxes, all tracks of the opposite direction to the grouping are considered spanned. For instance, a table-header-group is considered to span all the columns, and a table-column-group is considered to span all the rows.

The position of any table-caption having "bottom" as 'caption-side' within the table is defined as the rectangle whose:

• width/height is:
  • the width/height assigned to the caption during layout
• top location is the sum of:
  • the height reserved for top captions (including margins), if any
  • padding-top and border-top-width of the table
  • the height of all visible rows
  • padding-bottom and border-bottom-width of the table
  • the height reserved for previous bottom captions (including margins), if any
  • any necessary extra top margin remaining after collapsing margins with the previous bottom caption, if any.
• left location is the sum of:
  • the margin left of the caption
  • half of (the table width minus the width of caption and its total horizontal margin).

Cell overflow: If the table is laid out in fixed mode, if the content of some cell has grown more than the cell during its second layout pass or if some tracks spanned by visible cells are deemed not visible, the content of some cells may exceed the available space, and cause an overflow. Such overflow should behave exactly like if the cell was an absolutely positioned display:block box with the appropriate alignment in place to keep its content in place relative to its inline-start block-start corner (usually top left). !Testcase !Testcase Testcase

Visible tracks: For the purpose of this algorithm, a column or row is considered a visible track if neither its corresponding table-track nor its table-track-group parent (if any) have 'visibility' set to collapse.

~Testcase !!Testcase !!Testcase !!Testcase Testcase

Absolute Positioning

With a table-root as containing block

If an absolutely positioned element's containing block is generated by a table-wrapper box, the containing block corresponds to the area around which the table margins are applied, including the area where the table border is drawn and the margin area of any table-caption. The offset properties ('top'/'right'/'bottom'/'left') then indicate offsets inwards from the corresponding edges of this containing block, as normal. Absolute positioning occurs after layout of the table and its in-flow contents, and does not contribute to the sizing of any table grid tracks or affect the size/configuration of the table grid in any way.

With a table-internal as containing block

If an absolutely positioned element's containing block is generated by a table-internal, the containing block corresponds to the area starting at the top left corner of the the area that would be assigned to the box during layout but whose size is computed to be the one of the area that would be assigned to the box during layout if all tracks were considered visible (irrespective of 'visibility' being set co collapse on some boxes), not including borders and paddings as appropriate.

This is done so that hiding column does not trigger a layout in the absolutely-positioned boxes, and the content being clipped doesn't seem to be moving. !!Testcase !!Testcase

The offset properties ('top'/'right'/'bottom'/'left') then indicate offsets inwards from the corresponding edges of this containing block, as normal. ISSUE(858): This only works in Firefox. It would make it easier to implement position:sticky in the future, though. [Chrome bug] [Interop risk: Firefox bug]

With a table-internal box as non-containing block parent

The only influence of non-containing block parent of an absolutely-positioned box is to define its static position, in case both top+bottom and/or left+right end up being auto. For table-cells, the absolutely-positioned content is positioned follows the rules for block layout as usual. Due to table fixup, it is not possible to create an absolutely-positioned box that is the child of a table-internal box that is not a table-cell (see note about float and position for more details).

Rendering

Paint order of cells

Table cells are painted in a table-root in DOM order as usual, independently of where cells end up actually being drawn.

Empty cell rendering (separated-borders mode)

			Name: empty-cells
			Value: show | hide
			Initial: show
			Applies to: table-cell boxes
			Inherited: yes
			Media: visual
		

In collapsed-borders mode, this property has no effect. In separated-borders mode, when this property has the value hide, no borders or backgrounds are drawn around/behind empty cells. An empty cell is a table-cell containing neither:

• floating content, nor
• in-flow content (other than white space that has been collapsed away by the 'white-space' property handling).

ISSUE(605): Can we simplify empty-cells:hide?

For example, take the following markup and css: <table> <td><span></span></td> <td></td> <td><span></span></td> </table> table { width: 500px; height: 300px; empty-cells: hide; } table { background: black; border: 10px solid black; } td { background: white; } table { border-spacing: 0px; } td { padding: 0; } The correct rendering of this code snippet is depicted here:

Drawing backgrounds and borders

Drawing table backgrounds and borders

Unlike other boxes types, table and inline-table boxes do not paint their background and borders around their entire client rect. Indeed, the table captions are to be visually positioned between the table margins and its borders, which means the drawing areas of various effects applied to the table-root need to be modified. Painting areas:

• Backgrounds, borders and outlines painted relative to the content-box of a table-root are painted relative to the rectangular area occupied by the table grid and its border spacings.
• Backgrounds, borders and outlines painted relative to the padding-box of a table-root are painted relative to the rectangular area occupied by the table grid and its border spacings, extended on each side by the table-root padding.
• Backgrounds, borders and outlines painted relative to the border-box of a table-root are painted relative to the rectangular area occuped by the table grid and its border spacings, extended on each side by the table-root padding and border-width.

This does not affect other uses of these concepts, like absolute positioning.

!Testcase

Changes in collapsed-borders mode

When a table is laid out in collapsed-borders mode, the rendering of its borders on and those of its table-cells is modified. The following rules describe in which way.

The rules for background and borders painting defined in [[#drawing-backgrounds-and-borders]] still apply if they are not overriden. Borders of a non-empty table-root are not painted in collapsed-borders mode, except if the 'border-image' property is set. In this latter case, the border is drawn as if the table border was twice as big as its used value specify, and as if that excess was rendered inside the padding area of the table-root.

Even if they are not drawn by the table, the table borders still occupy their space in the layout. Cells will render those shared borders.

Drawing cell backgrounds

Anonymous table-cells added by the missing cells fixup step do not render any of their backgrounds. In addition to its own 'background', table-cell boxes also render the backgrounds of the table-track and table-track-group boxes in which they belong. This is actually different from simply inheriting their background because the 'background-origin' and 'background-size' computations will actually be done on the bounds of the grouping boxes, and not on those of the cell. For the purposes of finding the background of each table cell, the different table boxes may be thought of as being on six superimposed layers. The background set in one of the layers will only be visible if the layers above it have a transparent background.

0. The table background is being rendered by the table, and does not affect the cell background.
1. The first background drawn by a cell is the background of its originating table-column-group (if any). For the purpose of background-positioning, it is expected that a column group occupies the largest possible area a single cell could occupy in the row/column grid while originating in the column group and not entering any column not part of the column group.
2. The second background drawn by a cell is the background of its originating table-column (if any). For the purpose of background-positioning, it is expected that a column occupies the largest possible area a single cell could occupy in the row/column grid while originating in the column and not entering any other column.
3. The third background drawn by a cell is the background of its originating table-row-group (if any). For the purpose of background-positioning, it is expected that a row group occupies the largest possible area a single cell could occupy in the row/column grid while originating in the row group and not entering any row not part of the row group.
4. The fourth background drawn by a cell is the background of its originating table-row (if any). For the purpose of background-positioning, it is expected that a row occupies the largest possible area a single cell could occupy in the row/column grid while originating in the row and not entering any other row.
5. The fifth background drawn by a cell is its own background. This is the one that appears on top once all backgrounds have been rendered.

As the figure above shows, although all rows contain the same number of cells, not every cell may have specified content. In separated-borders mode, if the value of their 'empty-cells' property is hide, these empty cells are not rendered at all, as if visibility: hidden was specified on them, letting the table background show through.

Drawing cell borders

In separated-borders mode, borders of table cells are rendered as usual.

Changes in collapsed-borders mode

Borders of a table-cell are rendered in collapsed-borders mode as if the cell border was twice as big as its used value specify, and as if that excess was rendered in the margin area of the cell, with the added constraint that for each side of the border which isn’t located at one of the table edges, the border is actually clipped to the border-box drawing area as its real used value define except if the 'border-image' property is set. If applying the previously-mentioned clipping behavior results in clipping a border over a non-integer amount of device pixels, browsers may decide to snap the clipping area to a device pixel instead by ceiling the x- and y-values of the clipping area. Ceiling the values ensures that in a normal writing mode, the cell which gets the contested pixels between multiple cells is actually the most top left one, which has a greater specificity than the other ones according to this spec. See [[#paint-order]] and [[#border-conflict-resolution-algorithm]].

Border styles (collapsed-borders mode)

Some of the values of the 'border-style' have different meanings for tables in collapsed-borders mode than usual. Those definitions override the default behavior for 'border-style' values. : hidden :: Same as none, but also inhibits any other border (see [[#border-specificity]]). : inset :: Same as ridge. : outset :: Same as groove.

Rendering for visibility: collapse

When a table part has visibility: collapse set, the rendering is handled differently depending if it is on a table-cell, spanning table-cell, or a table-track/table-track-group.

Rendering a visibility: collapse table cell

As stated in CSS 2.2, if a table-cell has its visibility set to that of collapse, it is rendered the same as if it had visibility: hidden set.

This happens when you set visibility:collapse on a table-row that contains a table-cell. If you want to hide a row but continue to display its cells that span other rows, set visibility:visible on those cells to prevent them from inheriting their value.

If the table-cell is spanning more than one table-track, and at least one of those table-track is set to visibility: collapse then clip the content to the table-cell's border-box. This means that the top left (top right in rtl) content of the cell will continue to show, regardless of which of the tracks the cell spans has been collapsed.

Rendering a visibility: collapse table-track or table-track-group

When a table-track or table-track-group has visibility: collapse, all the backgrounds, borders or outlines that are contributed by the cells within the given table-track or table-track-group will continue to be painted on cells that have not been fully collapsed (because they spanned multiple tracks).

Fragmentation

Breaking across fragmentainers

When fragmenting a table, user agents must attempt to preserve the table rows unfragmented if the cells spanning the row do not span any subsequent row, and their height is at least twice smaller than both the fragmentainer height and width. Other rows are said freely fragmentable. When a table doesn't fit entirely in a fragmentainer, at least one row did fit entirely in the fragmentainer, and the first row that does not fit in the fragmentainer is not freely fragmentable. the user agent has to insert some vertical gap between the rows located before and at the overflow point such that the two rows end up separated in sibling fragmentainers. If the fragmentation requires repeating headers and footers, and the footer is repeated, then the footer must come directly after the last row in the fragmentainer and the vertical gap must be inserted after the repeated footer.

When there is no row fitting entirely in the current fragmentainer or when the first row that does not fit in the fragmentainer is freely fragmentable, user agents must attribute all the remaining height in the fragmentainer to the cells of that row, and fit as much content as it can in each of the cells independently, then break to the next fragment and start the content of each cell where it was stopped in its previous fragment (top borders must not be repainted in continuation fragments).

When 'break-before' or 'break-after' is applied to a table-row-group or a table-row box, the user agent has to insert some vertical gap between the rows located before and after the breaking point such that the two rows end up separated in sibling fragmentainers as required by the property value. If the fragmentation requires repeating headers and footers, and the footer is repeated, then the footer must come directly after the last row in the fragmentainer and the vertical gap must be inserted after the repeated footer.

Repeating headers across pages

When rendering the document into a paged media, user agents must repeat header rows and footer rows on each page spanned by a table if the page is the table's fragmentainer, if the header/footer has avoid 'break-inside' applied to it, if the height required to do so is inferior to two quarters of the page height (up to one quarter for header rows, and up to one quarter for footer rows), and if that doesn't cause a row to be displayed twice on that page. When the header rows are being repeated, user agents must leave room and if needed render the table top border. The same applies for footer rows and the table bottom border.

User agents may decide to extend this behavior to more fragmentation contexts, for instance repeat headers/rows across columns in addition to pages. User-agents that are rendering static documents are more likely to adopt this behavior, though this is not required per spec.

Security Considerations

Using CSS Tables does not incur any security risk to mitigate.

Privacy Considerations

Using CSS Tables does not incur any privacy risk to mitigate.

List of bugs being tracked

This section is not normative.

• Align=center attribute overrides css margins in Edge
• Chrome applies nowrap quirks mode fix in DOCTYPE documents too
• Edge does not account for widths of spanned cells
• Chrome and Gecko do not apply display:table-cell on <button>
• Edge's table-cell width unexplainably low due to percentage-max-width on content and colspan
• Table boxes should be wide enough to contain the caption
• Tables containing no row cannot have height in Chrome, but can in Edge/Firefox
• Table-layout:fixed causes different width distribution in Chrome
• Chrome distributes the height to each row differently then IE and firefox
• Height of rows which can overflow varies in Chrome vs Edge (percentage heights during min-height computation)
• Height specified on row groups is not interoperable
• Min-Height specified on rows is not interoperable
• Table with interleaved td[rowspan] rendered wrong in IE (145069)
• Row with explicit 'visibility:visible' lose background color when parent table has 'visibility: hidden'

Appendices

Mapping between CSS & HTML attributes

The default style sheet for HTML4 illustrates how its model maps to css properties and values:

Some extensions to CSS have been used for contraints not mappable to current CSS constructs

	table    { display: table }
	thead    { display: table-header-group }
	tbody    { display: table-row-group }
	tfoot    { display: table-footer-group }
	tr       { display: table-row }
	td, th   { display: table-cell }
	colgroup { display: table-column-group }
	col      { display: table-column }
	caption  { display: table-caption }
	table, thead, tbody, tfoot, tr, td, th, colgroup, col, caption { box-sizing: border-box; }
	thead, tfoot { break-inside: avoid }


	table {
		box-sizing: border-box;
		border-spacing: 2px;
		border-collapse: separate;
		text-indent: initial;
	}

	thead, tbody, tfoot, table > tr { vertical-align: middle; }
	tr, td, th { vertical-align: inherit; }

	td, th { padding: 1px; }
	th { font-weight: bold;	}

	table, td, th { border-color: gray; }
	thead, tbody, tfoot, tr { border-color: inherit; }





	table[frame=box i], table[frame=border i], table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
		border: 1px solid inset;
	}



	table:matches([rules=all i], [rules=rows i], [rules=cols i], [rules=groups i], [rules=none i]) {
		border-collapse: collapse;
		border-style: hidden;
	}

	table:matches([rules=all i], [rules=rows i], [rules=cols i], [rules=groups i], [rules=none i]),
	table:matches([rules=all i], [rules=rows i], [rules=cols i], [rules=groups i], [rules=none i]) > :matches(thead,tbody,tfoot) > tr > :matches(th,td) {
		border-color: black;
	}


	table[border=$border] /* if(parseInt($border) > 0) */ {
		border: /*(parseInt($border) * 1px)*/ outset rgb(128, 128, 128);
	}
	table[border=$border] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) /* if(parseInt($border) > 0) */ {
		border: 1px inset rgb(128, 128, 128);
	}


	table[rules=all i] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) {
		border: 1px solid grey;
	}
	table[rules=rows i] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) {
		border: 1px solid grey;
		border-left: none;
		border-right: none;
	}
	table[rules=cols i] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) {
		border: 1px solid grey;
		border-top: none;
		border-bottom: none;
	}
	table[rules=none i] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) {
		border: none;
	}


	table[rules=groups i] > :matches(thead,tbody,tfoot) {
		border-top-width: 1px; border-top-style: solid;
		border-bottom-width: 1px; border-bottom-style: solid;
	}
	table[rules=groups i] > colgroup {
		border-left-width: 1px; border-left-style: solid;
		border-right-width: 1px; border-right-style: solid;
	}


	table[frame=box i], table[frame=border i], table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
		border-style: outset;
	}
	table[frame=below i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
		border-top-style: hidden;
	}
	table[frame=above i], table[frame=vsides i], table[frame=lhs i], table[frame=rhs i] {
		border-bottom-style: hidden;
	}
	table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=rhs i] {
		border-left-style: hidden;
	}
	table[frame=hsides i], table[frame=above i], table[frame=below i], table[frame=rhs i] {
		border-right-style: hidden;
	}


	table[cellpadding=$x] > :matches(thead,tbody,tfoot) > tr > :matches(th,td) /* if(parseInt($x)>0) */ {
		padding: /*(parseInt($x) * 1px)*/;
	}
	table[cellspacing=$x] /* if(parseInt($x)>0) */ {
		border-spacing: /*(parseInt($x) * 1px)*/;
	}


	table[width=$w] /* if(parseInt($w) > 0) */ {
		width: /*(parseInt($w) * 1px)*/;
	}
	table[width=$w] /* if($w matches /(+|-|)([0-9]+([.][0-9]+|)|([.][0-9]+))[%]/) */ {
		width: /*(parseInt($w) * 1px)*/;
	}
	table[height=$h] /* if(parseInt($h) > 0) {
		height: /*(parseInt($h) * 1px)*/;
	}
	table[height=$h] /* if($h matches /(+|-|)([0-9]+([.][0-9]+|)|([.][0-9]+))[%]/) */ {
		height: /*(parseInt($h) * 1px)*/;
	}


	table[bordercolor=$color] {
		border-color: /*parseHTMLColor($color)*/;
	}
	table[bordercolor] > :matches(tbody, thead, tfoot, tr, colgroup, col),
	table[bordercolor] > :matches(tbody, thead, tfoot) > tr,
	table[bordercolor] > :matches(tbody, thead, tfoot) > tr > :matches(td, th),
	table[bordercolor] > tr > :matches(td, th)
	table[bordercolor] > colgroup > col
	) {
		border-color: inherit;
	}
	table[bgcolor=$color] {
		background-color: /*parseHTMLColor($color)*/;
	}
	table[align=left i] {
		float: left;
	}
	table[align=right i] {
		float: right;
	}
	table[align=center i] {
		margin-left: auto;
		margin-right: auto;
	}


	caption[align=bottom i] { caption-side: bottom; }
	:matches(thead,tbody,tfoot,tr,td,th)[valign=top i] {
		vertical-align: top;
	}
	:matches(thead,tbody,tfoot,tr,td,th)[valign=middle i] {
		vertical-align: middle;
	}
	:matches(thead,tbody,tfoot,tr,td,th)[valign=bottom i] {
		vertical-align: bottom;
	}
	:matches(thead,tbody,tfoot,tr,td,th)[valign=baseline i] {
		vertical-align: baseline;
	}

	:matches(thead,tbody,tfoot,tr,td,th)[align=absmiddle i] {
		text-align: center;
	}

	:matches(colgroup,col,thead,tbody,tfoot,tr,td,th)[hidden] {
		visibility: collapse;
	}

	:matches(td,th)[nowrap] { white-space: nowrap; }
	:matches(td,th)[nowrap][width=$w] /* if(quirksMode && parseInt($w) > 0) */ {
		white-space: normal;
	}

Some of the content here came from the WHATWG spec on the HTML to CSS mapping of tables. However, since they include things which are not true in most browsers, this is not a simple copy. Investigations are therefore required for each and any merge being made from one source to another!

(link here for missing sections)