Overview.bs

<h1>CSS Table Module Level 3</h1>
<pre class='metadata'>
Shortname: css-tables-3
Level: 3
Status: ED
Work Status: Exploring
Group: csswg
ED: https://drafts.csswg.org/css-tables-3/
TR: https://www.w3.org/TR/CSS2/tables.html
Editor: Francois Remy, Microsoft
Editor: Greg Whitworth, Microsoft
Former editor: Bert Bos, W3C
Former editor: David Baron, Mozilla
Former editor: Markus Mielke, Microsoft
Former editor: Saloni Mira Rai, Microsoft
Abstract: This CSS module defines a two-dimensional grid-based layout system, optimized for tabular data rendering. In the table layout model, each display node is assigned to an intersection between a set of consecutive rows and a set of consecutive columns, themselves generated from the table structure and sized according to their content.
Ignored Terms: block-level box
</pre>

<pre class=link-defaults>
spec:css21; type:property; text:min-width
spec:css21; type:property; text:max-width
</pre>

<!--------------------------------------------------------------------------------->
<h2 id="intro">Introduction</h2>

	<p><em>This section is not normative</em></p>
	<p>
		Many types of information (ex: weather readings collected over the past year)
			are best visually represented in a two-axis grid
			where rows represent one item of the list
				(ex: a date, and the various weather properties measured during that day),
			and where columns represent the successive values of an items property
				(ex: the temperatures measured over the past year).
	<p>
		Sometimes, to make the representation easier to understand,
			some cells of the grid are used to represent a description or summary of their parent row/column,
			instead of actual data.
		This happens more frequently for
			the cells found on the first row and/or column (called headers)
			or the cells found on the last row and/or column (called footers).

	<p>
		This kind of tabular data representation is usually known as tables.
		Tables layout can be abused to render other grid-like representations like calendars or timelines,
			though authors should prefer other layout modes
			when the information being represented does not make sense as a data table.
	<p>
		The rendering of tables in HTML has been defined for a long time in the HTML specification.
		However, its interactions with features defined in CSS remained for a long time undefined.
		The goal of this specification is to define
			the expected behavior of user agents supporting both HTML tables and CSS.
	<p>
		Please be aware that some behaviors defined in this document
			will not be the most logical or useful way of solving the problem they aim to solve,
			but such behaviors are often the result of compatibility requirements and not a deliberate choice
			of the editors of this specification.
		Authors wishing to use more complex layouts 
			are encouraged to rely on more modern CSS modules such as CSS Grids.

<!--------------------------------------------------------------------------------->
<h2 id="content-model">Content Model</h2>

	<!--------------------------------------------------------------------------------->
	<h3 id="table-structure">Table Structure</h3>

		<p>
			The CSS table model is based on the HTML4 table model,
				in which the structure of a table closely parallels the visual layout of the table.
			In this model, a table consists of an optional caption and any number of rows of cells.

		<p>
			In addition, adjacent rows and columns may be grouped structurally and
			this grouping can be reflected in presentation (e.g., a border may be drawn around a group of rows).

		<p>
			The table model is said to be "row primary" since 
				authors specify rows, not columns, explicitly in the document language.
			Columns are derived once all the rows have been specified:
				the first cell of the first row belongs to the first column
					and as many other columns as spanning requires (and it creates them if needed),
				and the following cells of that row each belong to the next available column
					and as many other columns as spanning requires (creating those if needed);
				the cells of the following rows each belong to the next available column for that row (taking rowspan into account)
					and as many other columns as spanning requires (creating those if needed).
				<span class="hint">(see [[#dimensioning-the-row-column-grid]])</span>.

		<p>
			To summarize, an instance of the table model consists of:
			<ul class="compact">
				<li>Its <a href="#table-root-element">table-root element</a> containing:
				<ul>
					<li>Zero, one or more <a href="#table-row">table rows</a>, optionally in <a href="#table-row-grouping-element">row groups</a>,
						<ul><li>Each of them contaning one or more <a href="#table-cell">table cells</a></li></ul>
					<li>Optionally: one or more <a href="#table-column">table columns</a>,
						optionally in <a href="#table-column-group">column groups</a>
					<li>Optionally: one or more <a href="#table-caption">table caption</a>.
				</ul>
			</ul>
			
			<style>
				ul.compact { margin-top: -1em !important; list-style-type: disc; }
				ul.compact li { margin-top: 0 !important; margin-bottom: 0 !important; list-style-type: disc; }
			</style>

		<figure>
			<img src="images/table-structure.png" width=493 />
			<figcaption>Two representations of the structure of a table (tree vs layout)</figcaption>
		</figure>

		<p>
			The CSS model does not require that the document language include elements that correspond to each of these components.
			For document languages (such as XML applications) that do not have pre-defined table elements,
				authors must map document language elements to table elements.
			This is done with the 'display' property.

		<p>
			The following 'display' values assign table formatting rules to an arbitrary element:

		<dl id="display-types">
			<dt><dfn>table</dfn> (equivalent to HTML: &lt;table&gt;)
			<dd>Specifies that an element defines a block-level table:
				it is a rectangular block that participates in a block formatting context.

			<dt><dfn>inline-table</dfn> (equivalent to HTML: &lt;table&gt;)
			<dd>Specifies that an element defines an inline-level table:
				it is a rectangular block that participates in an inline formatting context).

			<dt><dfn>table-row</dfn> (equivalent to HTML: &lt;tr&gt;)
			<dd>Specifies that an element is a row of cells.

			<dt><dfn>table-row-group</dfn> (equivalent to HTML: &lt;tbody&gt;)
			<dd>Specifies that an element groups some amount of rows.

			<dt><dfn>table-header-group</dfn> (equivalent to HTML: &lt;thead&gt;)
			<dd>Like table-row-group but, for layout purposes, 
				the first such row group is always displayed before all other rows and row groups.
				
				<div class="advisement">
					If a table owns multiple <code>display: table-header-group</code> boxes,
						only the first is treated as a header; 
						the others are treated as if they had <code>display: table-row-group</code>.
				</div>

			<dt><dfn>table-footer-group</dfn> (equivalent to HTML: &lt;tfoot&gt;)
			<dd>Like table-row-group but, for layout purposes,  
				the fist such row group is always displayed after all other rows and row groups.
				
				<div class="advisement">
					If a table owns multiple <code>display: table-footer-group</code> boxes, 
						only the first is treated as a footer;
						the others are treated as if they had <code>display: table-row-group</code>.
				</div>

			<dt><dfn>table-column</dfn> (equivalent to HTML: &lt;col&gt;)
			<dd>Specifies that an element describes a column of cells.

			<dt><dfn>table-column-group</dfn> (equivalent to HTML: &lt;colgroup&gt;)
			<dd>Specifies that an element groups one or more columns.

			<dt><dfn>table-cell</dfn> (equivalent to HTML: &lt;td&gt; or &lt;th&gt;)
			<dd>Specifies that an element represents a table cell.

			<dt><dfn>table-caption</dfn> (equivalent to HTML: &lt;caption&gt;)
			<dd>Specifies a caption for the table.
				Table captions are positioned between the table margins and its borders.
		</dl>

		<p class="advisement">
			Authors must not assign a display type from the previous list to replaced elements (like input fields or images).
			When the 'display' property of a replaced element computes to one of these values, 
				it is handled instead as would 
				<code>inline</code> (for <a>inline-table</a>, <a>table-cell</a>, <a>table-column</a>) or 
				<code>block</code> (for all other values).
			Whitespace collapsing and box generation must happen around those replaced elements 
				like if they never had any other display type.
			<br/>
			<span class="issue">This is a breaking change from css 2.1 but matches implementations</span>
		</p>
		
		<h4 id="terminology">Terminology</h2>

			<p>
				In addition to the table structure display types,
				the following wording is also being used in this spec:

			<dl>

				<dt><dfn id="table-wrapper-box">table-wrapper</dfn> box
				<dd>
					An anonymous box <a href="#fixup-algorithm">generated around table-root boxes</a> to account for any space occupied by each <a>table-caption</a> it owns.

				<dt><dfn id="table-root-element">table-root</dfn> box or element
				<dd>
					A <a>table</a> or <a>inline-table</a> box.

				<dt><dfn id="table-non-root-element">table-non-root</dfn> box or element
				<dd>
					A <a>proper table child</a>, or a <a>table-cell</a> box.

				<dt><dfn id="table-row-grouping-element">table-row-grouping</dfn> box or element
				<dd>
					A
					<a>table-row-group</a>,
					<a>table-header-group</a>, or
					<a>table-footer-group</a> box.

				<dt><dfn id="table-track">table-track</dfn> box or element
				<dd>
					A
					<a>table-row</a>, or
					<a>table-column</a> box.

				<dt><dfn id="table-track-grouping-element">table-track-grouping</dfn> box or element
				<dd>
					A
					<a>table-row-grouping</a>, or
					<a>table-column-group</a> box.

				<dt><dfn id="proper-table-child-element">proper table child</dfn> box or element
				<dd>
					A
					<a>table-track-grouping</a>,
					<a>table-track</a>, or
					<a>table-caption</a> box.

				<dt><dfn id="proper-table-row-parent-element">proper table-row parent</dfn> box or element
				<dd>
					A <a>table-root</a> or a <a>table-row-grouping</a> box.

				<dt><dfn id="table-internal-element">table-internal</dfn> box or element
				<dd>
					A <a>table-cell</a>, <a>table-track</a> or <a>table-track-grouping</a> box.

				<dt><dfn id="tabular-container">tabular container</dfn>
				<dd>
					A <a>table-row</a> or <a>proper table-row parent</a> box.

				<dt><dfn id="consecutive-boxes">consecutive</dfn> boxes
				<dd>
					Two sibling boxes are consecutive
						if they have no intervening siblings
						other than, optionally, an anonymous inline containing only white spaces.
					A sequence of sibling boxes is consecutive
						if each box in the sequence is consecutive to the one before it in the sequence.
				
				<dt><dfn id="table-slot">slot</dfn>
				<dd>
					A <a>slot</a> is an available space created 
						by the intersection of a row and a column in the table grid.
					
			</dl>
			
			<p class="issue">
				We should define the table grid, table grid rows, table grid columns, 
					and in general what spanning means for table-cells 
					(e.g. a rowspanning table-cell, a colspanning table-cell, etc).
				Inspiration can be taken from 
					<a href="https://drafts.csswg.org/css-grid/#grid-concepts">CSS Grid</a> and/or 
					<a href="https://html.spec.whatwg.org/#table-processing-model">HTML</a>.


	<!--------------------------------------------------------------------------------->
	<h3 id="fixup">Fixup</h3>

		<p>
			Document languages other than HTML may not contain all the elements in the CSS 2.1 table model.
			In these cases, the "missing" elements must be assumed in order for the table model to work.

		<p>
			Any <a>table-internal</a> element will automatically generate necessary anonymous table objects around itself, if necessary.
			Any descendant of a <a>table-root</a> that is not table-internal 
				must have a set of ancestors in the table consisting of
				at least three nested objects corresponding to
				a <a>table</a>/<a>inline-table</a> element,
				a <a>table-row</a> element, and
				a <a>table-cell</a> element.
			Missing elements cause the generation of anonymous boxes according to the following rules:

		<!--------------------------------------------------------------------------------->
		<h4 id="fixup-algorithm">Fixup Algorithm</h4>

			<p>
				For the purposes of these rules, out-of-flow elements are represented as inline elements of zero width and height.
				Their containing blocks are chosen accordingly.

			<p>
				The following steps are performed in three stages:

			<ol>
				<li><b>Remove irrelevant boxes:</b>
					<ol>
						<li>Children of a <a>table-column</a> are treated as if they had <code>display: none</code>.

						<li>Children of a <a>table-column-group</a> which are not a <a>table-column</a> are treated
							as if they had <code>display: none</code>.

						<li>Anonymous inline boxes which contain only white space and
							are between two immediate siblings each of which is a <a>table-non-root</a> box,
							are treated as if they had <code>display: none</code>.

						<li>Anonymous inline boxes which contain only white space,
							are the first and/or last child of a <a>tabular container</a>,
							and whose immediate sibling (if any) is a <a>table-non-root</a> box,
							are treated as if they had <code>display: none</code>.
							<div class="issue">
								This (combined with previous rule) is a breaking change from <a href="https://drafts.csswg.org/css2/tables.html#anonymous-boxes">CSS 2.1</a>.
								Edge is the only implementation of the complex version so we might as well drop it.
								The spec now covers Firefox behavior.
								Chrome collapses everything which is a bug anyway.
								<a href="https://jsfiddle.net/nbh4r9u8/1/" class="hint">!!Testcase</a>.
								<a href="https://jsfiddle.net/nbh4r9u8/2/" class="hint">!Testcase</a>.
								<a href="https://jsfiddle.net/nbh4r9u8/3/" class="hint">!Testcase</a>.
							</div>

					</ol>
				</li>
				<li><b>Generate missing child wrappers:</b>
					<ol>
						<li>An anonymous <a>table-row</a> box must be generated
							around each sequence of consecutive children of a <a>table-root</a> box
							which are not <a>proper table child</a> boxes.
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/2/">!!Testcase</a>

						<li>An anonymous <a>table-row</a> box must be generated
							around each sequence of consecutive children of a <a>table-row-grouping</a> box
							which are not <a>table-row</a> boxes.
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/3/">!Testcase</a>

						<li>An anonymous <a>table-cell</a> box must be generated
							around each sequence of consecutive children of a <a>table-row</a> box
							which are not <a>table-cell</a> boxes.
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/4/">!Testcase</a>

					</ol>
				</li>
				<li><b>Generate missing parents:</b>
					<ol>
						<li>An anonymous <a>table-row</a> box must be generated
							around each sequence of consecutive <a>table-cell</a> boxes
							whose parent is not a <a>table-row</a>.
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/5/">Testcase</a>

						<li>An anonymous <a>table</a> or <a>inline-table</a> box must be generated
							around each sequence of consecutive <a>proper table child</a> boxes
							which are misparented.
							If the box's parent is an inline box, 
								then an <a>inline-table</a> box must be generated;
								otherwise it must be a <a>table</a> box.
							<ul>
								<li>A <a>table-row</a> is misparented
									if its parent is neither a <a>table-row-grouping</a> nor a <a>table-root</a> box.
								<li>A <a>table-column</a> box is misparented
									if its parent is neither a <a>table-column-group</a> box nor a <a>table-root</a> box.
								<li>A <a>table-row-grouping</a>, <a>table-column-group</a>, or <a>table-caption</a> box is misparented
									if its parent is not a <a>table-root</a> box.
							</ul>
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/7/">Testcase</a>
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/8/">Testcase</a>
							<a class="hint" href="https://jsfiddle.net/hj2w7wwa/9/">!Testcase</a>

						<li>An anonymous <a>table-wrapper</a> box must be generated around each <a>table-root</a>. 
							Its display type is <code>inline-block</code> for <a>inline-table</a> boxes and block for <a>table</a> boxes. 
							The table wrapper box establishes a block formatting context. 
							The table-root box (not the table-wrapper box) is used when doing baseline vertical alignment for an <a>inline-table</a>. 
							The width of the table-wrapper box is the border-edge width of the table box inside it. 
							Percentages which would depend on the 'width' and 'height' on the table-wrapper box's size are relative to the table-wrapper box's containing block instead, not the table-wrapper box itself.

							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.) 
							<p class="note">
								Since this does not have any effect on layout, 
									implementations are free not to generate this box when the table-root has no table-caption.
								

					</ol>
				</li>
			</ol>

			<div class="note">
				Please note that some layout modes such as flexbox and grid <a href="http://www.w3.org/TR/css-display-3/#blockify">override the display type</a> of their children.
				These transformations happen before the table fixup.
			</div>

		<!--------------------------------------------------------------------------------->
		<h4 id="fixup-examples">Examples</h4>

			<div class="example">
				<xmp class="lang-markup">
					<div class="row">
						<div class="cell">George</div>
						<div class="cell">4287</div>
						<div class="cell">1998</div>
					</div>
				</xmp>

				<p>Here is the associated styles:</p>
				<pre class="lang-css">
					.row { display: table-row }
					.cell { display: table-cell }
				</pre>

				<p>After fixup, this will produce layout boxes as though this was the initial HTML:</p>
				<xmp class="lang-markup">
					<table>
						<tr>
							<td>George</td>
							<td>4287</td>
							<td>1998</td>
						</tr>
					</table>
				</xmp>
			</div>

			<div class="example">
				<p>In this example, three <a>table-cell</a> anonymous boxes are assumed to contain the text in the rows. The text inside
				of the divs with a <code>display: table-row</code> are encapsulated in anonymous inline boxes, as explained in
				<a href="https://www.w3.org/TR/CSS21/visuren.html#anonymous" target="_blank">visual formatting model</a>:</p>

				<xmp class="lang-markup">
					<div class="inline-table">
						<div class="row">This is the top row.</div>
						<div class="row">This is the middle row.</div>
						<div class="row">This is the bottom row.</div>
					</div>
				</xmp>

				<pre class="lang-css">
					.inline-table { display: inline-table; }
					.row { display: table-row; }
				</pre>

				<p>This will produce layout boxes as though this was the initial HTML:</p>
				<xmp class="lang-markup">
					<table>
						<tr>
							<td>This is the top row.</td>
						</tr>
						<tr>
							<td>This is the middle row.</td>
						</tr>
						<tr>
							<td>This is the bottom row.</td>
						</tr>
					</table>
				</xmp>
			</div>

<!--------------------------------------------------------------------------------->
<h2 id="layout">Layout</h2>

	<!--------------------------------------------------------------------------------->
	<h3 id="layout-principles">Core layout principles</h3>

		<p>
			Unlike other block-level boxes, tables do not fill their containing block by default.
			When their 'width' computes to <code>auto</code>, they behave as if they had <code>fit-content</code> specified instead.
			This is different from most block-level boxes, which behave as if they had <code>fill-available</code> instead.

		<p>
			The <dfn id="min-content-width-of-a-table">min-content width of a table</dfn> is 
				the width required to fit all of its columns min-content widths and its undistributable spaces.

		<p>
			The <dfn id="max-content-width-of-a-table">max-content width of a table</dfn> is 
				the width required to fit all of its columns max-content widths and its undistributable spaces.

		<p>
			If the width assigned to a table is larger than its <a href="#min-content-width-of-a-table">min-content width</a>,
				the <a href="#width-distribution">Available Width Distribution</a> algorithm
				will adjust column widths in consequence.

		<p>
			This section overrides the general-purpose rules that apply to calculating widths described in other specifications.
			In particular, if the margins of a table are set to <code>0</code> and the width to <code>auto</code>,
				the table will not automatically size to fill its containing block.
			However, once the used value of <code>width</code> for the table is found (using the algorithms given below)
				then the other parts of those rules do apply.
			Therefore, a table can be centered using left and right <code>auto</code> margins, for instance.

	<!--------------------------------------------------------------------------------->
	<h3 id="table-layout-algorithm">Table layout algorithm</h3>
	
		<p>To layout a table, user agents must apply the following actions:
			<ol>
				<li><b>Determine the number of rows/columns the table requires.</b><br/>
					This is done by executing the steps described in [[#dimensioning-the-row-column-grid]].
				
				<li><b>&lbrack;A&rbrack; If the row/column grid has at least one <a>slot</a>:</b>
					<ol>
						<li><b>Ensure each cell <a>slot</a> is occupied by at least one cell.</b><br/>
							This is done by executing the steps described in [[#missing-cells-fixup]].
					
						<li><b>Compute the minimum width of each column.</b><br/>
							This is done by executing the steps described in [[#content-measure]].
							
						<li><b>Compute the width of the table.</b><br/>
							This is done by executing the steps described in [[#computing-the-table-width]].
							
						<li><b>Distribute the width of the table among columns.</b><br/>
							This is done by executing the steps described in [[#width-distribution-algorithm]].
							
						<li><b>Compute the height of the table.</b><br/>
							This is done by executing the steps described in [[#computing-the-table-height]].
							
						<li><b>Distribute the height of the table among rows.</b><br/>
							This is done by executing the steps described in [[#height-distribution-algorithm]].
							
					</ol>
					
					<b>&lbrack;B&rbrack; Else, if the table is empty:</b>
					<ol>
						<li><b>Compute the width of the table.</b><br/>
							This is done by returning the largest value of <a href="#capmin">CAPMIN</a> 
							and the computed width of the table box (including borders and paddings)
								if it is definite (use zero otherwise).
					
						<li><b>Compute the height of the table.</b><br/>
							This is done by returning the sum of all table-caption heights
								(their width being set to the table width, 
								with margins taken into consideration appropriately)
							and the computed height of the table box (including borders and paddings)
								if it is definite (use zero otherwise).
							
					</ol>
					
				<li><b>Assign to each table-caption and table-cell their position and size.</b><br/>
					This is done by running the steps of [[#bounding-box-assignment]].
					
			</ol>
			
		<figure>
			<p class="note">
				The following schema describes the algorithm in a different way,
					to make it easier to understand.
			</p>
			<img src="images/CSS-Tables-Layout-Merged.svg" style="width: 100%" />
			<figcaption>Overview of the table layout algorithm. Not normative.</figcaption>
		</figure>

	<!--------------------------------------------------------------------------------->
	<h3 id="dimensioning-the-row-column-grid">Dimensioning the row/column grid</h3>

		<p>
			Like mentioned in the <a href="#table-structure">Table structure</a> section,
				how many rows and columns a table has
				can be determined from the table structure.
			Both dimensioning the row/column grid and assigning table-cells their <nobr>slot(s)</nobr> in that grid
				do require running the HTML Algorithms for tables.

		<p class="note">
			CSS Boxes that do not originate from an HTML table element equivalent to their display type 
				need to be converted to their HTML equivalent before we can apply this algorithm.

		<div class="example">
			<xmp class="lang-markup">
				<ul class="table">
					<li><b>One</b><i>1</i></li>
					<li><b>Two</b><i>2</i></li>
					<li><b>Three</b><i>3</i></li>
				</ul>
				<style>
					ul.table { display: table; }
					ul.table > li { display: table-row; }
					ul.table > li > * { display: table-cell; }
				</style>
			</xmp>
			produces the same row/column grid as
			<xmp class="lang-markup">
				<table><tbody>
					<tr>
						<td></td>
						<td></td>
					</tr>
					<tr>
						<td></td>
						<td></td>
					</tr>
					<tr>
						<td></td>
						<td></td>
					</tr>
				</tbody></table>
			</xmp>
		</div>

		<div class="example">
			<pre class="lang-markup" style="margin-bottom:0;padding-bottom:0;">
				&lt;!-- built using dom api, as this would be fixed by the html parser --&gt;
			</pre>
			<xmp class="lang-markup" style="margin-top:0;padding-top:0;">
				<grid style="display: table">
					<row style="display: table-row">
						<th rowspan="2">1</th>
						<colgroup style="display: table-cell" span="2" colspan="2">2</colgroup>
					</row>
					<tr>
						<td>A</td>
						<td>B</td>
						<td>C</td>
					</tr>
				</grid>
			</xmp>
			produces the same row/column grid as
			<xmp class="lang-markup">
				<table>
					<tr>
						<th rowspan="2">1</th>
						<td>2</td>
					</tr>
					<tr>
						<td>A</td>
						<td>B</td>
						<td>C</td>
					</tr>
				</table>
			</xmp>
			Note how the second cell of the first row doesn't have ```colspan=2``` applied, because its originating element is not an HTML TD element.

			<a class="hint" href="https://jsfiddle.net/eqrwaLyc/">Testcase</a>.
			<a class="hint" href="https://jsfiddle.net/eqrwaLyc/1/">!!Testcase</a>.
			<a class="hint" href="https://jsfiddle.net/sckxeLmh/2/">!Test case</a>.
			<a class="hint" href="https://jsfiddle.net/sckxeLmh/4/">!!Test case</a>.
			<a class="hint" href="https://jsfiddle.net/sckxeLmh/5/">!!Test case</a>.

		</div>

		<p>
			Apply the <a href="https://www.w3.org/TR/html5/tabular-data.html#forming-a-table">HTML5 Table Formatting algorithm</a>,
				where boxes act like <a href="#display-types">the HTML element equivalent to their display type</a>,
				and use the attributes of their originating element only if it as an HTML element of the same type
				(otherwise, they act like they didnt't have any attribute).

		<p class="note">
			The HTML Table Formatting algorithm sometimes generates more tracks than necessary to layout the table properly.
			Those tracks have historically been ignored by user agents, 
			so the next step just gets rid of them entirely to avoid dealing with them as exceptions later in the spec.
			
		<p>
			Modify iteratively the obtained grid by merging consecutive tracks as follows: 
			As long as there exists an <a>eligible track</a> in the obtained row/column grid such that
				there is no table-column/table-row box defining the said track explicitly, and
				both the said track and the previous one are spanned by the exact same set of cells,
				those two tracks must be merged into one single track for the purpose of computing the layout of the table.
			Change the spanning of the cells contained in those tracks
				accordingly so that no difference would be detectable in terms of slot assignment.
			<span class="hint">(see <a href="#spanning-ghost-rows">spanning-ghost-rows test cases</a>)</span>

		<p>
			For tables <a>in auto mode</a>, every track is an <dfn>eligible track</dfn> for the purpose of the track-merging algorithm.
			For tables <a>in fixed mode</a>, only rows are eligible to be merged that way; which means that every column is preserved.
				
		<p>
			Finally, assign to the <a>table-root</a> element its correct number of rows and columns (from its mapped element),
				and to each <a>table-cell</a> element its accurate table-row-start/table-column-start/table-row-span/table-column-span (from its mapped element).

	<!--------------------------------------------------------------------------------->
	<h3 id="missing-cells-fixup">Missing cells fixup</h3>

		<p class=note>
			The following section clarifies and extends the CSS 2.1 statement saying that
				missing cells are rendered as if an anonymous table-cell box occupied their position in the grid
				(a "missing cell" is a cell in the row/column grid that is not occupied by an element or pseudo-element).

		<p>
			Once the amount of columns in a table is known, any table-row-group element must be modified such that
				each of its rows owns enough cells to fill all the columns of the table, when taking spanning into account.
			New table-cell anonymous boxes must be appended to its rows content until this condition is met.

		<p>
			Beside their display type, those anonymous boxes do not receive any specific or default styling,
				except where otherwise mentioned by this specification
				(meaning 
					their background is “transparent”, 
					their padding is “0px” and 
					their border is “none” by default).

	<!--------------------------------------------------------------------------------->
	<h3 id="layout-modes">Table layout modes</h3>

		<p>
			This section covers the flags which modify the way tables are being laid out.
			There are three major flags for table layout: 'table-layout', 'border-collapse', and 'caption-side'.
			The 'border-collapse' flag has an optional 'border-spacing' parameter.

		<!--------------------------------------------------------------------------------->
		<h4 id="table-layout-property">The Table-Layout property</h4>

			<pre class='propdef'>
				Name: table-layout
				Value: auto | fixed
				Initial: auto
				Applies To: table-root boxes.
				Inherited: yes
			</pre>
			
			<p>
				A table-root is said to be laid out <dfn>in fixed mode</dfn>
					whenever the computed value of the 'table-layout' property is equal to <code>fixed</code>,
					and the specified width of the table root is either 
						a <code>&lt;length-percentage&gt</code>,
						<code>min-content</code> or
						<code>fit-content</code>.
				When the specified width is not one of those values, 
					or if the computed value of the 'table-layout' property is <code>auto</code>,
					then the table-root is said to be laid out <dfn>in auto mode</dfn>.

			<p>
				When a table-root is laid out <a>in fixed mode</a>,
				the content of its table-cells is ignored for the purpose of width computation,
				the aggregation algorithm for column sizing considers only table-cells belonging to the first row track,
				such that layout only depends on the values explicitly specified for the table-columns or cells of the first row of the table;
				columns with indefinite widths are attributed their fair share of the remaining space
				after the columns with a definite width have been considered, or 0px if there is no remaining space
				(see [[#computing-column-measures]]).

		<!--------------------------------------------------------------------------------->
		<h4 id="border-collapse-property">The Border-Collapse property</h4>

			<pre class='propdef'>
				Name: border-collapse
				Value: separate | collapse
				Initial: separate
				Applies To: table-root boxes.
				Inherited: yes
			</pre>

			<p>
				When the 'border-collapse' property has <code>collapse</code> as its value,
				the borders of adjacent cells are merged together such that each cell draws only half of the shared border.
				As a result, some other properties like 'border-spacing' will not applied in this case (see [[#collapsed-style-overrides]]),
				(see [[#border-collapsing]]).

			<p>
				A <a>table-root</a> element is said to be laid out <dfn>in collapsed-borders mode</dfn> in this case.
				Otherwhise, the <a>table-root</a> element is said to be laid out <dfn>in separated-borders mode</dfn>.

			<!--------------------------------------------------------------------------------->
			<h5 id="border-spacing-property">The Border-Spacing property</h5>

			<pre class='propdef'>
				Name: border-spacing
				Value: <​length​>{1,2}
				Initial: 0px 0px
				Applies To: table-root boxes when 'border-collapse' is <code>separate</code>.
				Inherited: yes
				Computed Value: two absolute lengths
				Media: visual
				Animatable: yes
			</pre>

			<p>
				The lengths specify the distance that separates adjoining cell borders <a>in separated-borders mode</a>,
					and must not be strictly negative.

			<p>
				If one length is specified, it gives both the horizontal and vertical spacing.
				If two are specified, the first gives the horizontal spacing and the second the vertical spacing.

			<p>
				See [[#computing-undistributable-space]] for details on how this affects the table layout.


		<!--------------------------------------------------------------------------------->
		<h4 id="caption-side-property">The Caption-Side property</h4>

			<pre class='propdef'>
				Name: caption-side
				Value: top | bottom
				Initial: top
				Applies to: <code>table-caption</code> boxes
				Inherited: yes
				Media: visual
			</pre>

			<p>
				This property specifies the position of the caption box with respect to the table box.
				Values have the following meanings:

			<dl>
				<dt><dfn id="caption-side-top">top</dfn>
				<dd>
					Positions the caption box above the table box.

				<dt><dfn id="caption-side-bottom">bottom</dfn>
				<dd>
					Positions the caption box below the table box.
			</dl>

			<div class="note">
				CSS2 described a different width and horizontal alignment behavior.
				That behavior was supposed to be introduced in CSS3 
					using the values <code>top-outside</code> and <code>bottom-outside</code>.
				<a href="http://fantasai.inkedblade.net/style/discuss/captions/">#REF</a>
			</div>

			<div class="note">
				Gecko also supports the "left" and "right" values. It was never well defined though.
				<a href="http://codepen.io/FremyCompany/pen/YwGPWw">#REF</a>
			</div>

			<div classs="note">
				Gecko has a bug when dealing with multiple captions.
				<a class="hint" href="http://codepen.io/FremyCompany/pen/WrJxwP">!Testcase</a>
			</div>

			<div class="example">
				<p>
					To align caption content horizontally within the caption box, use the 'text-align' property.
				<p>
					In this example, the 'caption-side' property places captions below tables.
					The caption will be as wide as the parent of the table, and caption text will be left-justified.
				<pre>
					caption {
						caption-side: bottom;
		  				width: auto;
		  				text-align: left
					}
				</pre>
			</div>

	<!--------------------------------------------------------------------------------->
	<h3 id="style-overrides">Style overrides</h3>

		<p>
			Some css properties behave differently inside css tables.
			The following sections list the exceptions and their effects.

		<!--------------------------------------------------------------------------------->
		<h4 id="global-style-overrides">Overrides applying in all modes</h4>

			<p>
				The following rules apply to all tables, irrespective of the layout mode in use:

			<ul>
				<li>All css properties of <a>table-track</a> and <a>table-track-grouping</a> boxes are ignored, 
					except when explicitely specified by this specification.

				<li>The 'margin' of <a>table-cell</a> boxes is ignored (as if it was set to 0px).

				<li>The 'background' of <a>table-cell</a> boxes
					are painted using a special background painting algorithm described in [[#drawing-cell-backgrounds]].
				
				<li>The 'opacity' of <a>table-cell</a> boxes
					applies using a special value combining its parent tracks values, as described in [[#TODO]].

				<li>The 'transform' of <a>table-cell</a> boxes
					applies using a special value combining its parent tracks values, as described in [[#TODO]].
			</ul>


		<!--------------------------------------------------------------------------------->
		<h4 id="collapsed-style-overrides">Overrides applying in collapsed-borders mode</h4>

			<p>
				When a table is laid out <a>in collapsed-borders mode</a>, the following rules apply:

			<ul>
				<li>The 'padding' of the <a>table-root</a> element is ignored (as if it was set to 0px).

				<li>The 'border-spacing' of the <a>table-root</a> element is ignored (as if it was set to 0px).

				<li>The 'border-radius' of both <a>table-root</a> and <a>table-non-root</a> boxes
					is ignored (as it it was set to 0px).
				<li>The values used for the layout and rendering of the borders of the <a>table-root</a> element
						and the <a>table-cell</a> boxes it owns are
						determined using a special conflict resolution algorithm described in [[#border-collapsing]].
			</ul>


	<!--------------------------------------------------------------------------------->
	<h3 id="border-collapsing">Border-collapsing</h3>

		<div class="note">
			<p>
				This entire section is a proposal to make the rendering of collapsed borders sane.
				As implementations diverge very visibly, it is expected to require more discussion than some other parts.
				Since browsers handle this so differently, convergence cannot happen without reimplementation.
				A major concern for this proposal was to support as many cases as possible, and yet
					keep the effort required for a new implementation of tables as low as possible.

			<p>
				<b>Background:</b>
				CSS+HTML allow unprecedented combinations of border modes for table junctions,
					and it makes it difficult to support all cases properly;
					in fact some combinations are not <a href="https://en.wikipedia.org/wiki/Well-posed_problem">well-posed problems</a>,
					so no rendering algorithm could be optimal.
			<p>
				Because they grew from something simple (HTML) to something very complex (HTML+CSS),
					the current table rendering models (backgrounds and borders) used by web browsers are insane
					(in the sense they are buggy, not interoperable and not CSSish at all).
				Many usual CSS assumptions are broken, and renderings diverge widely.

			<p>
				This proposal aims at fixing this situation.

		</div>

		<div class="issue">
			<strong>This proposal does not respect these stated CSS 2.1 requirements:</strong><br/>
			UAs must compute an initial left and right border width for the table
				by examining the first and last cells in the first row of the table.
			The left border width of the table is half of the first cell's collapsed left border,
				and the right border width of the table is half of the last cell's collapsed right border.
			If subsequent rows have larger collapsed left and right borders,
				then any excess spills into the margin area of the table.
		</div>

		<div class="issue">
			This proposal is doing worse than Edge and Firefox (but better than Chrome) when
				row- or colspanned cells have border styles which conflict with their neighbors,
				and those neighbors have different styles which conflict with each other.
			This is a necessary trade-of to make the model sane.
		</div>

		<!--------------------------------------------------------------------------------->
		<h4 id="conflict-resolution-for-collapsed-borders">Conflict Resolution for Collapsed Borders</h4>

		<p>
			When they are laid out <a>in collapsed-borders mode</a>,
				<a>table-root</a> and <a>table-cell</a> boxes sharing a border attempt to unify their borders
				so that they render using the same style, width, and color (whenever this is possible).
			This is accomplished by running the following algorithm.

		<!--------------------------------------------------------------------------------->
		<h5 id="border-conflict-resolution-algorithm">Conflict Resolution Algorithm for Collapsed Borders</h5>
		<div class="note">
			For the purpose of this algorithm, &#8220;harmonizing&#8221; a set of borders means
				applying the <a href="#border-style-harmonization-algorithm">&#8220;Harmonization Algorithm for Collapsed Borders&#8221;</a> on the given set of borders, and 
				set those borders' used values to the value resulting from the algorithm,
				except for cells having a 'border-image-source' different from none:
				those keep their initial values.
		</div>

		<p><b>For any <a>table-cell</a> element C° of a <a>table-root</a> element:</b>

		<ul>
			<li>Resolve conflicts with border-right:
			<ul>
				<li>Let C be an ordered set of <a>table-cell</a> element borders, sorted in Row/Column order of their parent cell;
					initially, let C contain only C°&#8217;s border-right

				<li>Add to the set C the border-left of all cells located after C°
					sharing a section of their border-left with C°&#8217;s border-right

				<li>Repeat the following two instructions, until no new cell is added to C:
				<ul>
					<li>For all newly-added cells C<sub>i</sub> having a rowspan greater than one,
						add to the set C the border-right of all cells located before C<sub>i</sub>
						sharing a section of their border-right with C<sub>i</sub>&#8217;s border-left

					<li>For all newly-added cells C<sub>i</sub> having a rowspan greater than one,
						add to the set C the border-left of all cells located after C<sub>i</sub>
						sharing a section of their border-left with C<sub>i</sub>&#8217;s border-right
				</ul>

				<li>Harmonize the conflicting borders of C
			</ul>

			<li>Resolve conflicts with border-bottom:
			<ul>
				<li>Let C be an ordered set of <a>table-cell</a> element borders, sorted in Row/Column order of their parent cell;
					initially, let C contain only C°&#8217;s border-bottom

				<li>Add to the set C the border-top of all cells located after C°
					sharing a section of their border-top with C°&#8217;s border-bottom

				<li>Repeat the following two instructions, until no new cell is added to C:
				<ul>
					<li>For all newly-added cells C<sub>i</sub> having a colspan greater than one,
						add to the set C the border-bottom of all cells located before C<sub>i</sub>
						sharing a section of their border-bottom with C<sub>i</sub>&#8217;s border-top

					<li>For all newly-added cells C<sub>i</sub> having a colspan greater than one,
						add to the set C the border-top of all cells located after C<sub>i</sub>
						sharing a section of their border-top with C<sub>i</sub>&#8217;s border-bottom
				</ul>

				<li>Harmonize the conflicting borders of C
			</ul>

			<li>Divide the used width of all borders by two.<br>
				<div class="note">
					This effect will be compensated at rendering time wherever needed,
					but is required for layout correctness.
					<span class="hint">(see [[#drawing-collapsed-borders-2]])</span>
				</div>
		</ul>
		
		<p>
			<b>Then, for that <a>table-root</a> element:</b>
		</p>

		<ul>
			<li>Harmonize the <a>table-root</a> element 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 <a>table-root</a> element.<br>
				<br>
				If the table and the cell border styles have the same specificity, 
					keep the cell border style.
				<br>
				Once this is done, set the <a>table-root</a> element border-{&#8230;}-width
					to half the maximum width found during the harmonization processes for that border,
					then set border-{&#8230;}-style to solid, and border-{&#8230;}-color to transparent.
		</ul>

		<!--------------------------------------------------------------------------------->
		<div class="note">
			Implementations may of course choose to skip some of the steps of the previous algorithm,
			provided they can prove those have no visible impact on the final results;
			certain borders are harmonized more than once using the previous steps which is completely unnecessary,
			but preventing this would make the spec harder to read.
		</div>

		<div class="example">
			To help the reader get a better idea of what this algorithm is doing,
			the main steps of applying the previous algorithm over a sample table have been outlined here:
			<br/>
			<br/>
			<a href="https://jsfiddle.net/bn3d1sm4/">https://jsfiddle.net/bn3d1sm4/</a><br/>
			<a href="https://jsfiddle.net/bn3d1sm4/1/">https://jsfiddle.net/bn3d1sm4/1/</a><br/>
			<a href="https://jsfiddle.net/bn3d1sm4/2/">https://jsfiddle.net/bn3d1sm4/2/</a><br/>
			&#8230;<br/>
			<a href="https://jsfiddle.net/bn3d1sm4/15/">https://jsfiddle.net/bn3d1sm4/15/</a><br/>
		</div>

		<!--------------------------------------------------------------------------------->
		<h5 id="border-style-harmonization-algorithm">Harmonization Algorithm for Collapsed Borders</h5>
		<div class="note">
			For the purpose of this algorithm, &#8220;considering&#8221; a border&#8217;s properties means
			that &#8220;if its properties are <a href="border-specificity">more specific</a> than CurrentlyWinningBorderProperties,
			set CurrentlyWinningBorderProperties to its properties&#8221;.
		</div>
		
		<div class="issue">
			There is an outstanding proposal from Fantasai to 
				change the "more specific than" part of these rules 
				to "as specific or more than". 
			This would change the priority order 
				from
					cell, track, track-group, table
				to
					table, track-group, track, cell.
			
		</div>

		<p>
			Given an ordered set of borders (BC<sub>1,</sub> BC<sub>2</sub>, &#8230; located in cells C<sub>1,</sub> C<sub>2</sub>, &#8230;)
			execute the following algorithm to determine the used value of the border properties for those conflicting borders.

		<ul>
			<li>
				Set CurrentlyWinningBorderProperties to &#8220;border: 0px none transparent&#8221;

			<li>
				For each border BC<sub>i</sub>:
				<ul>
					<li>Consider the BC<sub>i</sub> border&#8217;s properties
				</ul>

			<li>
				If the border separates two columns:
				<ul>
					<li>For each border BC<sub>i</sub>:
						Find the table-column element in which the C<sub>i</sub> cell is located, if any.
						If the BC<sub>i</sub> border is such that 
							there is a border of the table-column element that would be drawn contiguously to it, 
							consider its border&#8217;s properties.

					<li>For each border BC<sub>i</sub>:
						Find the table-column-group element in which the C<sub>i</sub> cell is located, if any.
						If the BC<sub>i</sub> border is such that 
							there is a border of the table-column-group element that would be drawn contiguously to it, 
							consider its border&#8217;s properties.
				</ul>

			<li>
				If the border separates two rows:
				<ul>
					<li>For each border BC<sub>i</sub>:
						Find the table-row element in which the C<sub>i</sub> cell is located, if any.
						If the BC<sub>i</sub> border is such that 
							there is a border of the table-row element that would be drawn contiguously to it,
							consider its border&#8217;s properties.

					<li>For each border BC<sub>i</sub>:
						Find the table-row-group element in which the C<sub>i</sub> cell is located, if any.
						If the BC<sub>i</sub> border is such that 
							there is a border of the table-row-group element that would be drawn contiguously to it,
							consider its border&#8217;s properties.
				</ul>

			<li>
				Return CurrentlyWinningBorderProperties
		</ul>

		<!--------------------------------------------------------------------------------->
		<h5 id="border-specificity">Specificity of a border style</h5>

		<p>
			Given two borders styles, the border style having the most specificity is the border style which&#8230;

		<ol>
			<li>&#8230; has the value "hidden" as 'border-style', if only one does
			<li>&#8230; has the biggest 'border-width', once converted into css pixels
			<li>&#8230; has the 'border-style' which comes first in the following list:
				<pre>double, solid, dashed, dotted, ridge, outset, groove, inset, none</pre>
			</ol>

		<p>
			If none of these criterion matches, then both borders share the same specificity.

	<!--------------------------------------------------------------------------------->
	<h3 id="content-measure">Computing table measures</h3>

		<!--------------------------------------------------------------------------------->
		<h4 id="computing-undistributable-space">Computing Undistributable Space</h3>

			<p>
				The <dfn>undistributable space</dfn> of the table is the sum of 
					the distances between the borders of consecutive table-cells
					(and between the border of the table-root and the table-cells).

			<p>
				The distance between the borders of two consecutive table-cells is the 'border-spacing', if any.

			<p>
				The distance between 
					the table border and 
					the borders of the cells on the edge of the table
				is 
					the table's padding for that side, 
					plus the relevant border spacing distance (if any).

			<div class="example">
				For example, on the right hand side, the distance is padding-right + horizontal border-spacing.
			</div>

		<!--------------------------------------------------------------------------------->
		<h4 id="computing-cell-measures">Computing Cell Measures</h3>

			<p>
				The following terms are parameters of tables or table cells.
				These parameters encapsulate the differences
					between tables with different values of 'border-collapse' (separate or collapse)
					so that the remaining subsections of this section do not need to refer to them differently.

			<dl>
				<!--------------------------------------------------------------------------------->
				<dt><dfn>cell intrinsic offsets</dfn></dt>
				<dd>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:
					<ul>
						<li><a>In separated-borders mode</a>: the computed horizontal padding and border of the table-cell
						<li><a>In collapsed-borders mode</a>: the computed horizontal padding of the cell and, for border values,
							the used border-width values of the cell (half the winning border-width)
					</ul>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>table intrinsic offsets</dfn></dt>
				<dd>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:
					<ul>
						<li><a>In separated-borders mode</a>: the computed horizontal padding and border of the table-root
						<li><a>In collapsed-borders mode</a>: the used border-width values of the cell (half the winning border-width)
							<div class="issue">
								Is this the correct way to account for the various changes 
								that have gone into CSS2.1 
								regarding which border sticks out into the margin?
							</div>
					</ul>

					<p class="note">
						The margins are not included in the table intrinsic offsets
							because handling of margins depends on the 'caption-side' property.
					<div class="issue">But doesn't that break handling of percentage padding?
						<a class="hint" href="https://jsfiddle.net/j5dbco4m/">
							I don't think so because they are resolved based on parent anyway
						</a>
					</div>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>total horizontal border spacing</dfn></dt>
				<dd>The total horizontal border spacing is defined for each table:
					<ul>
						<li>For tables laid out <a>in separated-borders mode</a> 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
						<li>Otherwise, 0
					</ul>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>outer min-content</dfn> and <dfn>outer max-content</dfn> widths</dt>
				<dd>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 those defined <a href="#TODO">above</a>:
					<ul>
						<li>The <b>outer min-content width</b> of a table cell is
								<code>max('min-width', min('max-width', min-content width))</code>
								adjusted by the cell intrinsic offsets.
							<div class="issue">
								Should 'max-width' really be able to override the min-content width?
								An alternative expression is <code>max('min-width', min-content width)</code>
								@ FR: I think we should choose this option.
							</div>
							<div class="issue">
								Should 'min-width' affect outer min-content widths at all?
								@ FR: I think it should, yes. That's interoperable.
							</div>

						<li>The <b>outer min-content width</b> of a table column or column group is
							<code>'min-width'</code>.
							<div class="issue">
								Should 'min-width' affect outer min-content widths at all?
							</div>

						<li>The <b>outer max-content width</b> of a table cell in a non-constrained column is
								<code>max('min-width', min('max-width', max-content width))</code>
								adjusted by the cell intrinsic offsets.
							<div class="issue">
								Should 'max-width' be able to override the intrinsic min-content width?
								An alternative expression is <code>max('min-width', min-content width, min('max-width', max-content width)</code>.
							</div>

						<li>The <b>outer max-content width</b> of a table cell in a constrained column is
								<code>max('min-width', min('max-width', max('width', min-content width)))</code>
								adjusted by the cell intrinsic offsets.
							<div class="issue">
								Should 'max-width' be able to override the min-content width?
								An alternative expression is <code>max('min-width', min-content width, min('max-width', 'width'))</code>.
							</div>
							<div class="issue">
								I think we should define those things better. 
								Min-width covers both 'min-width' and 'width', 
									and width seems to cover the 'width' specified on the column
									(at least based on this <a href="https://jsfiddle.net/ovesmumh/1/">!!Testcase</a>).
							</div>

						<li>The <b>outer max-content width</b> of a table column or column group is
								<code>max('min-width', min('max-width', 'width'))</code>.
					</ul>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>percentage contribution</dfn>s</dt>
				<dd>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:<br/>
					<br/>
					<code>max(percentage 'min-width', min(percentage 'width', percentage 'max-width'))</code>.<br/>
					<br/>
					If the computed values are not percentages, 
						then <code>0%</code> is used for 'width' or 'min-width',and 
						an <code>infinite</code> percentage is used for 'max-width'.

			</dl>

			<div class="issue">
				These definitions need to account for the 'box-sizing' property.
			</div>


		<!--------------------------------------------------------------------------------->
		<h4 id="computing-column-measures">Computing Column Measures</h3>

			<p>
				This subsection defines terms for various parameters associated with each column of a table.
				These parameters are used in the following two subsections as part of
					the rules for computing intrinsic widths of tables and
					computing the column widths of a table.
					
			<p class="advisement">
				For the purpose of measuring a column when laid out <a>in fixed mode</a>, 
					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).

			<p>
				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. 
				<a href="https://jsfiddle.net/0e12ve9b/1/">Testcase</a>
				<a href="https://jsfiddle.net/0e12ve9b/3/">Testcase</a>

			<dl>
				<!--------------------------------------------------------------------------------->
				<dt><dfn>intermediate min-content width for span 1</dfn></dt>
				<dd>The largest of:
					<ul>
						<li>the outer min-content width of the column group, if any
						<li>the outer min-content width of the column, if any
						<li>the outer min-content width of each cell in the column whose column-span is 1
							(or just the one in the first row <a>in fixed mode</a>) 
							or 0 if there is none
					</ul>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>intermediate max-content width for span 1</dfn></dt>
				<dd>The largest of:
					<ul>
						<li>the outer max-content width of the column group, if any
						<li>the outer max-content width of the column, if any
						<li>the outer max-content width of each cell in the column whose column-span is 1
							(or just the one in the first row if <a>in fixed mode</a>) 
							or 0 if there is no such cell
					</ul>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>intermediate intrinsic percentage width for span 1</dfn></dt>
				<dd>The largest of the percentage contributions of
						each cell in the column whose column-span is 1,
						of the column (if any), and
						of the column group (if any)

				<!--------------------------------------------------------------------------------->
				<dt><dfn>intermediate min-content width for span N (N > 1)</dfn></dt>
				<dd>the largest of the intermediate min-content width for span N-1 and the contributions
						of the cells in the column whose column-span is N,
						where the contribution of a cell is the result of taking the following steps:
					<ol>
						<li>Define the baseline (min-content / max-content) width
							as the sum of the intermediate (min-content / max-content) widths
							for span N-1 of all columns that the cell spans.

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

						<li>The contribution of the cell is the sum of:
							<ul>
								<li>the min-content width of the column for span N-1
								<li>the product of:
									<ul>
										<li>the ratio of:
											<ul>
												<li>the intermediate max-content width for span N-1 of the column
													minus the intermediate min-content width for span N-1 of the column, to
												<li>the baseline max-content width minus the baseline min-content width
											</ul>
											or zero if this ratio is undefined, and

										<li>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
									</ul>
								<li>the product of:
									<ul>
										<li>the ratio of the intermediate max-content width
											for span N-1 of the column to the baseline max-content width
										<li>the outer min-content width of the cell
											minus the baseline max-content width and baseline border spacing,
											or 0 if this is negative
									</ul>
							</ul>
					</ol>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>intermediate max-content width for span N (N > 1)</dfn></dt>
				<dd>The largest of the intermediate max-content width
					for span N-1 and the contributions of the cells in the column whose column-span is N,
					where the contribution of a cell is the result of taking the following steps:
					<ol>
						<li>Define the baseline max-content width as
							the sum of the intermediate max-content widths
							for span N-1 of all columns that the cell spans.

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

						<li>The contribution of the cell is the sum of:
							<ul>
								<li>the max-content width of the column for span N-1
								<li>the product of:
									<ul>
										<li>the ratio of the intermediate max-content width
											for span N-1 of the column to the baseline max-content width
										<li>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
									</ul>
							</ul>
					</ol>


				<!--------------------------------------------------------------------------------->
				<dt><dfn>intermediate intrinsic percentage width for span N (N > 1)</dfn></dt>
				<dd>If the intermediate intrinsic percentage width for span N-1 is greater than 0%,
					then the intermediate intrinsic percentage width for span N is
					the same as the intermediate intrinsic percentage width for span N-1.<br/>
					<br/>
					Otherwise, it is the largest of the contributions of the cells in the column
					whose column-span is N,
					where the contribution of a cell is the result of taking the following steps:
					<ol>
						<li>Start with the percentage contribution of the cell.
						<li>Subtract the intermediate intrinsic percentage width for span N-1 of all columns that the cell spans.
							If this gives a negative result, change it to 0%.
						<li>Multiply by the ratio of
							<ul>
								<li>the column's non-spanning max-content width to
								<li>the sum of the non-spanning max-content widths of all columns spanned by the cell
									that have an intermediate intrinsic percentage width for span N-1 equal to 0%.
							</ul>
							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 intermediate intrinsic percentage width for span N-1 equal to zero.
					</ol>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>min-content width</dfn></dt>
				<dd>the intermediate min-content width for span N, where N is the number of columns in the table

				<!--------------------------------------------------------------------------------->
				<dt><dfn>max-content width</dfn></dt>
				<dd>the intermediate max-content width for span N, where N is the number of columns in the table

				<!--------------------------------------------------------------------------------->
				<dt><dfn>intrinsic percentage width</dfn></dt>
				<dd>the smaller of:
					<ul>
						<li>intermediate intrinsic percentage width for span N,
							where N is the number of columns in the table
						<li>100% minus the sum of the intrinsic percentage width of all prior columns in the table
							(further left (right) when direction is "ltr" ("rtl"))
					</ul>
					<p class="note">
						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.
					</p>

				<!--------------------------------------------------------------------------------->
				<dt><dfn>constrainedness</dfn></dt>
				<dd>A column is constrained if
						the column group (if any),
						the column (if any),
						or any of the non-column-spanning cells in the column
					has a computed 'width' that is not "auto",
						and is not a percentage.

					<div class="issue">
						Do we need intermediate constrainedness?
						It's easier to implement that way, but does it actually make any difference?
					</div>

			</dl>

			<div class="note">
				In a future revision of this specification, this algorithm will need to account 
					for character-alignment of cells ('<<string>>' values of the 'text-align' property).
				This requires (based on the 9 March 2011 editor's draft of css3-text) separately tracking max-content widths
					for the part of the column before the center of the alignment string and
					the part of the column after the center of the alignment string.
				For tracking min-content widths, there are two options:
					either not track them, or track three values:
					two values as for max-content widths for any cells that do not have break points in them,
					and a fourth value for any cells that do have break points in them
					(and to which character alignment is therefore not mandatory).
			</div>

			<div class="issue">
				The handling of the 'max-width' property with this algorithm is very poor.
				It ought to have an effect stronger
					than the one it has on the outer intrinsic widths of the element on which it is specified.
				It probably ought to be a separate parameter of the column
					(though how it interacts with the min-content width would need to be defined).
			</div>

			<div class="issue">
				The way this describes distribution of widths from column-spanning cells is wrong.
				For min-content and max-content widths it should refer to the rules
					for distributing excess width to columns for intrinsic width calculation.
					<span class="highlight">FR: Not sure what this means</span>
			</div>
					
			<div class="issue">
				Is 0% really treated like 0 rather than like a percentage value?
				(e.g., if it's the only non-spanning percentage in a column that has a spanning cell with a percentage width?)
			</div>


	<!--------------------------------------------------------------------------------->
	<h3 id="width-distribution">Available Width Distribution</h3>

		<!--------------------------------------------------------------------------------->
		<h4 id="computing-the-table-width">Computing the table width</h3>

			<p>
				Before deciding on the final width of all columns, 
					it is necessary to compute the width of the table itself.
			
			<p class="note">
				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.

			<p>
				The <dfn id="capmin">caption width minimum (CAPMIN)</dfn> is 
					the largest of the <a href="#table-caption">table captions</a> <a>min-content contribution</a>.
				
			<p>
				The <dfn id="gridmin">row/column-grid width minimum (GRIDMIN)</dfn> width is
					the sum of the <a>min-content width</a> of all the columns
					plus cell spacing or borders.
					
			<p>
				The <dfn id="gridmax">row/column-grid width maximum (GRIDMAX)</dfn> width is
					the sum of the <a>max-content width</a> of all the columns 
					plus cell spacing or borders.

			<p>
				Column and caption widths influence the final table width as follows:

			<ul>
				<li>If the <a>table-root</a> element's 'width' property has a computed value (<dfn>W</dfn>) 
					other than <code>auto</code>,
						the used width is the greater of
							<a>W</a>, 
							<a href="#capmin">CAPMIN</a>, and 
							<a href="#gridmin">GRIDMIN</a>.
					<div class="note">
						If the used width is greater than <a href="#gridmin">GRIDMIN</a>, 
						the extra width should be distributed over the columns.	
						<span class=hint>See [[#width-distribution]].</span>
					</div>

				<li>If the <a>table-root</a> element has 'width: auto',
						the used width is the greater of 
							min(<a href="#gridmax">GRIDMAX</a>, the table's containing block width), 
							<a href="#capmin">CAPMIN</a>, and 
							<a href="#gridmin">GRIDMIN</a>.
			</ul>
			
			<p>
				The <a>assignable table width</a> can easily be determined from the table used width.
				This is the width that we will be able to allocate to the columns.
			
			<div class="note">
				In this algorithm, rows (and row groups) and columns (and column groups) both constrain
				and are constrained by the dimensions of the cells they contain.
				Setting the width of a column might indirectly influence the height of a row, and vice versa.
			</div>

		<!--------------------------------------------------------------------------------->
		<h4 id="width-distribution-principles">Core distribution principles</h3>

			<p style="font-style: italic">
				This section is not normative.

			<h5 id="width-distribution-principles-rN">Rules</h5>

			<p>
				Ideally, each column should get its preferred width (usually its <a>max-content width</a>).
				However, the <a>assignable table width</a> calculated before
					could be either too big or too small to achieve this result,
					in which case the user agent must assign adhoc widths to columns
					as described in the width distribution algorithm.

			<p>
				This algorithm follows three rules when determining a column's used width:

			<p id="width-distribution-principles-r1">
				<b>Rule 1: </b>
				<span>
					When assigning preferred widths, 
					specified percent columns have a higher priority 
					than specified unit value columns, which have a higher priority 
					than auto columns.
				</span>

			<p id="width-distribution-principles-r2">
				<b>Rule 2: </b>
				<span>
					Columns using the same sizing type (eg: absolute, relative, auto) follow the same distribution method.
					For example, they all get their <a>min-content width</a> or they all get their <a>max-content width</a>.
					<br/>
					<span class="note" style="display: block; margin-top: 0.5em">
						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 <a>min-content width</a>,
							the column will be assigned its <a>min-content width</a> instead
							though the percent-columns group as a whole is still regarded
							as being assigned the preferred percent widths.
					</span>
				</span>

			<p id="width-distribution-principles-r3">
				<b>Rule 3: </b>
				<span>
					The sum of width assgined to all columns should be equal to the <a>assignable table width</a>.
				</span>

			<style>
				#width-distribution-principles-r1,
				#width-distribution-principles-r2,
				#width-distribution-principles-r3 {
					display: flex;
				}

				#width-distribution-principles-r1 > :first-child,
				#width-distribution-principles-r2 > :first-child,
				#width-distribution-principles-r3 > :first-child {
					flex-shrink: 0; flex-basis: 5em;
				}

				#width-distribution-principles-r1 > *,
				#width-distribution-principles-r2 > *,
				#width-distribution-principles-r3 > * {
					display: inline-block;
				}
			</style>

			<h5 id="width-distribution-principles-rR">Available sizings</h5>

			<p>
				All three types of columns have the following possible used widths.
				<ol>
					<li>min-content width: <br/>
						<span class="hint">The size required to fit the content of the column</span>
					<li>min-content width + delta: <br/>
						<span class="hint">A value between the min-content and preferred widths</span>
					<li>preferred width: <br/>
						<span class="hint">The size specified for the column, 
							or the size required to fit the content of the column without breaking</span>
					<li>preferred width + delta<br/>
						<span class="hint">A value larger than the preferred width</span>
						
			<p>
				The distribution algorithm defines those values and explains when to use them.

		<!--------------------------------------------------------------------------------->
		<h4 id="width-distribution-algorithm">Distribution algorithm</h3>

			<p>
				When a table is laid out at a given used width,
					the used width of each column must be determined as follows.

			<p class="note">
				For the purpose of this algorithm, we clarify that
				the <dfn>assignable table width</dfn> is
					the used width of the table
					minus the total horizontal border spacing.

			<ol>
				<li>Define the <dfn>min-content guess</dfn> as the set of column width assignments
					where each column is assigned its min-content width.

				<li>Define the <dfn>min-content-percentage guess</dfn>
					as the set of column width assignments where:
					<ul>
						<li>each column with an intrinsic percentage width greater than 0%
							is assigned the larger of:
							<ul>
								<li>its intrinsic percentage width times the assignable width and
								<li>its min-content width.
							</ul>

						<li>all other columns are assigned their min-content width.
					</ul>

				<li>Define the <dfn>min-content-specified guess</dfn>
					as the set of column width assignments where:
					<ul>
						<li>each column with an intrinsic percentage width greater than 0%
							is assigned the larger of:
							<ul>
								<li>its intrinsic percentage width times the assignable width and
								<li>its min-content width
							</ul>

						<li>any other column that is constrained
							is assigned its max-content width

						<li>all other columns are assigned their min-content width.
					</ul>

				<li>Define the <dfn>max-content guess</dfn>
					as the set of column width assignments where:
					<ul>
						<li>each column with an intrinsic percentage width greater than 0%
							is assigned the larger of:
							<ul>
								<li>its intrinsic percentage width times the assignable width and
								<li>its min-content width
							</ul>

						<li>all other columns are assigned their max-content width.
					</ul>

			<div class="note">
				Note that the assignable width is greater than or equal to the table width using the min-content guess,
					and that the widths for each column in the four guesses
					(min-content guess, min-content-percentage guess, min-content-specified guess, and max-content guess)
					are in nondecreasing order.
			</div>

			<p>
				If the <a>assignable table width</a> is less than or equal to the <a>max-content guess</a>,
					the used widths of the columns must be the linear combination (with weights adding to 1)
					of the two consecutive guesses whose width sums bound the available width.

			<p>
				Otherwise, the used widths of the columns are the result of starting from the <a>max-content guess</a>
					and distributing the excess width to the columns of the table
					according to the rules for <a>distributing excess width to columns</a> for used width calculation.

		<figure>
			<p class="note">
				The following schema describes the algorithm in a different way,
					to make it easier to understand.
			</p>
			<img src="images/CSS-Tables-Column-Width-Assignment.svg" style="width: 100%" />
			<figcaption>Overview of the width distribution algorithm. Not normative.</figcaption>
		</figure>

		<p class="issue">
			Edge and Chrome ignores "min-width: %" while Firefox applies it properly.
			Firefox continues to apply a "min-width: %" when a "width: px" is specified (the width is ignored).
			We should decide on what is the right behavior and make sure it is written in the spec.

		<h5 id="distributing-width-to-columns">Distributing excess width to columns</h5>

		<p>
			The rules for <dfn>distributing excess width to columns</dfn> can be invoked in two ways:
			<ul>
				<li>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

				<li>for distributing the excess max-content or min-content width of a column-spanning cell
					to the max-content or min-content widths of the columns it spans (for intrinsic width calculation).
			</ul>

		<p>
			The rules for these two cases are largely the same, but there are slight differences.

		<p>
			The remainder of this section uses the term <dfn>distributed width</dfn> to refer to the one of these widths that is being distributed,
			and the <dfn>excess width</dfn> is used to refer to the amount by which the width being distributed
			exceeds the sum of the distributed widths of the columns it is being distributed to.

		<ol>

			<li>If there are non-constrained columns that have originating cells
					with intrinsic percentage width of 0% and
					with nonzero max-content width
					<i class="hint">(aka the columns allowed to grow by this rule)</i>,
				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.

			<li>Otherwise, if there are non-constrained columns that have originating cells
					with intrinsic percentage width of 0%
					<i class="hint">(aka the columns allowed to grow by this rule,
					which thanks to the previous rule must have zero max-content width)</i>,
				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.

			<li>Otherwise, if there are (constrained) columns
					with intrinsic percentage width of 0% and
					with nonzero max-content width
					<i class="hint">(aka the columns allowed to grow by this rule, which, due to other rules, must have originating cells)</i>,
				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.

			<li>Otherwise, if there are columns
					with intrinsic percentage width greater than 0%
					<i class="hint">(aka the columns allowed to grow by this rule, which, due to other rules, must have originating cells)</i>,
				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.

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

			<li>Otherwise, 
					the distributed widths of all columns
					are increased by equal amounts
					so the total increase adds to the excess width.
		</ul>
		
		<div class="advisement">
			These rules do not apply when the table is laid out <a>in fixed mode</a>.
			In this case, the simpler rules that follow apply instead:
			<ul><li>If there are any columns with no width specified, the excess width is distributed in equally to such columns
				<li>otherwise, if there are columns with non-zero length widths from the base assignment, the excess width is distributed proportionally to width among those columns
				<li>otherwise, if there are columns with non-zero percentage widths from the base assignment, the excess width is distributed proportionally to percentage width among those columns
				<li>otherwise, the excess width is distributed equally to the zero-sized columns</ul>
		</div>

	<!--------------------------------------------------------------------------------->
	<h3 id="height-distribution">Available Height Distribution</h3>

		<!--------------------------------------------------------------------------------->
		<h4 id="computing-the-table-height">Computing the table height</h3>
				
			<p class="note">
				<a class="hint" href="https://jsfiddle.net/bsgt4wbx/">?Testcase</a>
				<a class="hint" href="https://jsfiddle.net/bsgt4wbx/1/">?Testcase</a>
				<a class="hint" href="https://jsfiddle.net/bsgt4wbx/3/">?Testcase</a>
				
			<p>
				The <strong>height of a table</strong> is the sum of the table-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, 
					and will be distributed to the height of the table-rows. 
			
			<p>
				The <strong>minimum height of a table-row</strong> is the maximum of:
				<ul><li>the row's computed 'height' (if definite, percentages being considered 0px)
					<li>the computed 'height' of each cell spanning the current row exclusively (if definite, percentages being treated as 0px), and 
					<li>the minimum height (<a>ROWMIN</a>) required by the cells spanning the row.</ul>
			<p>
				<dfn id="ROWMIN">ROWMIN</dfn> is defined as the sum of the <a href="#TODO">minimum height of the rows</a> 
					after a first row layout pass.
					
			<p>
				Once the table height has been determined, a second row layout pass must happen
					to assign the correct minimum height to table rows, by taking percentages used in rows/cells specified 'height' into account.
					
			<p>
				Then, if the sum of the new heights of the table rows after this second pass 
				is different from what is needed to fill the table height,
					the height distribution algorithm defined <a href="#height-distribution-algorithm">below</a> is applied
					(either to size rows intermediately between their first minimum height and their new,
					or to increase the heights of rows beyond their new minimum height;
					in neither case, this will have an impact on the baseline of the rows).
					
			<div class="advisement">
				Once the final size of the table and the rows has been determined, 
					the content of the table-cells must also go through a second layout pass,
					where this time percentage-based heights are resolved against their parent cell height.
			</div>

			<div class="note">
				It is possible that this second layout pass (where height percentages are being resolved)
					will make some cell contents overflow their parent cell. This is by design. 
			</div>
					
		<!--------------------------------------------------------------------------------->
		<h4 id="row-layout">Row layout</h3>
		
			<p>
				The <strong>minimum height of a row</strong> (without spanning-related height distribution)
					is defined as the height of 
					an hypothetical linebox containing the cells originating in the row
					and where cells spanning multiple rows are considered having a height of 0px
					(but their correct baseline).
				In this hypothetical linebox, cell heights are considered auto, 
					but their other properties are conserved.
					
			<p>
				For the purpose of calculating this height, 
					descendants of table cells whose height depends on percentages of their parent cell' height
					are considered to have an auto height 
						if they have 'overflow' set to <code>visible</code> or <code>hidden</code>
						or if they are replaced elements,
					and a 0px height if they have not. 
				<a href="https://jsfiddle.net/0e12ve9b/">Testcase</a>
				<a href="https://jsfiddle.net/0e12ve9b/3/">!!Testcase</a>
			
			<p>
				The <strong>baseline of a cell</strong> 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. 
					
			<div class="example">
				<p>
					Here is how this works out in practice:

				<xmp>
					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>
				</xmp>
				
				<figure>
					<img src="images/td-baseline-example-rendering.png" width="585" height="185" />
					<figcaption>Rendering of <a href="https://jsfiddle.net/x8sh0f60/3/">this example</a> in a compliant browser</figcaption>
				</figure>
			</div>
					
			<p class="advisement">
				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. 
					
			<p class="note">
				The baseline of a cell may end up below its bottom border, 
					see the example below.
					
			<div class="example">
				<p>
					The cell in this example has a baseline below its bottom border:

				<xmp>
					div { height: 0; overflow: hidden; }

					<table>
					<tr>
					<td>
					<div> Test </div>
					</td>
					</tr>
					</table>
				</xmp>
			</div>
					 
			<p>
				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. 
			
			<p>
				In the context of table cells, values for 'vertical-align' have the following meanings:
				
			<table class="def">
				<tr>
					<th valign=top>baseline</th>
					<td>The baseline of the cell is put at the same height as the baseline of the first of the rows it spans (see below for the definition of baselines of cells and rows).</td>
				<tr>
					<th valign=top>top</th>
					<td>The top of the cell box is aligned with the top of the first row it spans.</td>
				<tr>
					<th valign=top>bottom</th>
					<td>The bottom of the cell box is aligned with the bottom of the last row it spans.</td>
				<tr>
					<th valign=top>middle</th>
					<td>The center of the cell is aligned with the center of the rows it spans.</td>
				<tr>
					<th valign=top title="sub, super, text-top, text-bottom, &lt;length>, &lt;percentage>">...</th>
					<td>Other values do not apply to cells; the cell is aligned at the baseline instead.</td>
			</table>
						
			<p>
				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 has no cell box aligned to its baseline, 
					the baseline of that row is the bottom content edge of the lowest cell in the row.
			
			<div class="advisement">
				<p>
					To avoid ambiguous situations, 
					the alignment of cells proceeds in the following order:

				<ul><li>First the cells that are aligned on their baseline are positioned. 
						This will establish the baseline of the row. 
					<li>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.
					<li>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.
					<li>Finally, assign their position to the remaining cells.
			</div>
			
			<div class="example">
				<p>
					Example showing how the previous algorithm creates the various alignment lines of a row.
					
				<figure>
					<a href="http://www.w3.org/TR/CSS2/images/longdesc/cell-align-desc.html"><img src="images/cell-align-explainer.png" width="375" height="241"></a>
					<figcaption>
						Diagram showing the effect of various values of 'vertical-align' on table cells.
						Cell boxes 1 and 2 are aligned at their baselines. Cell box 2 has the largest height above the baseline, so that determines the baseline of the row.
					</figcaption>
				</figure>
			</div>

			<p>
				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 for spans N>1, 
					with the span=1 value being initialized with the largest of 
					the resulting height of the previous row layout,
					and the largest specified height of cells that span this row only.
			
			<div class="issue">
				Import the relevant section of [[#computing-column-measures]] here.
			</div>
			
			<p>
				Rows that see their size increase as a result of applying these steps
					adjust by lowering their bottom.
						
			<div class="advisement">
				<p>
					The cells whose position depended on the bottom of any updated row
						must be positioned correctly again in their respective rows.
				
				<p>
					At this point, cell boxes that are smaller than the height of the rows they span 
						receive extra top and/or bottom padding 
						such that their content does not move vertically
						but their top and bottom edges meet the ones of the rows they span.
						
			</div>	
					
			<div class="note">
				Please note that heights being defined on row groups are being ignored by this algorithm
			</div>

		<!--------------------------------------------------------------------------------->
		<h4 id="height-distribution-principles">Core distribution principles</h3>

			<div class="issue">
				TODO. For current proposal, skip to [[#height-distribution-algorithm]].
			</div>
			
			<div class="note">

				<p style="font-weight: bold; font-size: 120%;">
					Investigations on height distribution

				<p>
					Initial analysis shows that there are indeed similarities between width and height distribution.
					There are also differences which I described here below:

				<p>
					In many case, all browsers apply a distribution algorithm that favors percentages over pixels over auto.
					<span class="hint"><a href="https://jsfiddle.net/xg2ss965/2/">Case 6</a></span>.

				<p>
					A difference with the width distribution algorithm is that
						if the sum of all rows' heights is higher than 100%,
						then all browsers enter a completely different mode.
						<a href="https://jsfiddle.net/6ec0hxgx/">Case 7</a>.
						<span class="hint">
							NOTE: The sum counts as well percentage heights and pixels heights,
							since at this point you can safely resolve percentages.
						</span>
						<br/>

					In this case, pixel-tracks are sized properly first.
					Then, percentage tracks get the remaining space proportionally to their height percentage up to their height percentage.
					Finally, auto tracks get to fill the remaining space, if there is any auto track.
					If there is none, percentage tracks continue growing above their height percentage until all the space is filled.
					<a href="https://jsfiddle.net/xg2ss965/1/">Case 9</a>.

				<p>
					The height distribution algorithm also caps the sum of percentage heights to 100% in all browsers but Edge.
					That means that some rows get an arbitrary 0% height.
					<a href="https://jsfiddle.net/xg2ss965/">Case 8</a>.

				<p>
					In Edge and Firefox, empty tracks do not get an increased size by this distribution if there are filled auto tracks.
					In Chrome, empty tracks count as distributable tracks as well even if there are other auto tracks.

					<ul class="inline hint">
					<li>Case 1: <a href="https://jsfiddle.net/Lh9shm8p/">height</a> vs <a href="https://jsfiddle.net/wza8huh7/">width</a>
					<li>Case 2: <a href="https://jsfiddle.net/Lh9shm8p/1/">height</a> vs <a href="https://jsfiddle.net/wza8huh7/1/">width</a>
					<li>Case 3: <a href="https://jsfiddle.net/Lh9shm8p/2/">height</a> vs <a href="https://jsfiddle.net/wza8huh7/2/">width</a>
					<li>Case 4: <a href="https://jsfiddle.net/Lh9shm8p/3/">height</a> vs <a href="https://jsfiddle.net/wza8huh7/3/">width</a>
					<li>Case 5: <a href="https://jsfiddle.net/Lh9shm8p/4/">height</a> vs <a href="https://jsfiddle.net/wza8huh7/4/">width</a>
					</ul>

					<style>
						ul.inline { display: inline; margin: 0; padding: 0; }
						--ul.inline::before { content:"("; display: inline; }
						--ul.inline::after { content:")"; display: inline; }
						ul.inline > li { display: inline; margin: 0; padding: 0; }
						ul.inline > li::after { content:", "; display: inline; }
						ul.inline > li:last-of-type::after { content:""; display: none; }
					</style>

				<p id="min-content-and-percentages">
					Intersting test cases about min-content and content using percentage sizes:
					<ul class="compact">
						<li><a href="https://jsfiddle.net/gzapbyeg/1/">Case 10</a>.
						<li><a href="https://jsfiddle.net/gzapbyeg/2/">Case 11</a>.
					</ul>
					<br/>
					Chrome and Edge apply percentages on the final layout.
					All browsers work around them during the first pass
						by considering them 0% (Chrome) or
						by ignoring the declaration (Edge, Firefox).
					The difference of choice is visible in
					<a href="https://jsfiddle.net/vmfrLzke/1/">Case 12</a>.
					<a href="http://codepen.io/FremyCompany/pen/obdYjv?editors=1100">Case 13</a>.
			</div>

		<!--------------------------------------------------------------------------------->
		<h4 id="height-distribution-algorithm">Distribution algorithm</h3>

			<p>
				The first step is to attribute to each row its base size and its reference size. 
				
			<p>
				Its <strong>base size</strong> 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).
					
			<p>
				Its <strong>reference size</strong> is the largest of 
				<ul><li>its initial base height and 
					<li>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).</ul>
						
			<p>
				The second step is to compute the final height of each row based on those sizes.
				
			<p>
				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.
			<p>
				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.
					
			<p>
				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.
					
			<div class="advisement">
				<p>
					The cells whose position depended on the bottom of any updated row
						must be positioned correctly again in their respective rows.
				
				<p>
					At this point, cell boxes that are smaller than the height of the rows they span 
						receive extra top and/or bottom padding 
						such that their content does not move vertically
						but their top and bottom edges meet the ones of the rows they span.
						
			</div>	
			
	<!--------------------------------------------------------------------------------->
	<h3 id="bounding-box-assignment">Positioning of cells, captions and other internal table boxes</h3>

		<div class="issue">
			We need a resolution on what visibility:collapse does.
			The current proposal is to do like "hidden" but in addition
				use the following formula to shift back the next rows/columns
				to accomodate the disappearance of <a href="#visible-track">collapsed tracks</a>.
			The total width/height of the table would not be affected, 
				only the bounding client rectangles of the cells would be.
			<a class="hint" href="http://codepen.io/FremyCompany/pen/KVRzWe?editors=1100">!!Testcase</a>.
			<a class="hint" href="http://codepen.io/FremyCompany/pen/KVRzQx?editors=1100">!!Testcase</a>.
			<a class="hint" href="http://codepen.io/FremyCompany/pen/MKGyBx?editors=1100">!!Testcase</a>.
		</div>
		
		<p>
			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.
		<p>
			The <a>table-wrapper</a> box is then sized such that 
				it contains the margin box of all <a>table-non-root</a> boxes 
				as well as the <a>table-root</a> border-box.
		
		<div class="note">
			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.
		</div>
			
		<p>
			The <b>position of any table-caption having "top" as 'caption-side'</b> within the table is defined as the rectangle whose:
			<ul class="compact">
				<li>width/height is:
					<ul><li>the width/height assigned to the caption during layout</ul>
				<li>top location is the sum of:
					<ul><li>the height reserved for previous top captions (including margins), if any
						<li>any necessary extra top margin remaining after collapsing margins with the previous caption, if any.</ul>
				<li>left location is the sum of:
					<ul><li>the margin left of the caption
						<li>half of (the table width minus the width of caption and its total horizontal margin).</ul>
			</ul>

		<p>
			The <b>position of any table-cell, table-track, or table-track-grouping box</b> within the table is defined as the rectangle whose:
			<ul class="compact">
				<li>width/height is the sum of:
					<ul><li>the widths/heights of all spanned <a href="#visible-track">visible</a> columns/rows
						<li>the horizontal/vertical 'border-spacing' times the amount of spanned <a href="#visible-track">visible</a> columns/rows minus one
					</ul>
				<li>left/top location is the sum of:
					<ul><li>for top: the height reserved for top captions (including margins), if any
						<li>the padding-left/padding-top and border-left-width/border-top-width of the table
						<li>the widths/heights of all previous <a href="#visible-track">visible</a> columns/rows
						<li>the horizontal/vertical 'border-spacing' times the amount of previous <a href="#visible-track">visible</a> columns/rows plus one
					</ul>
			</ul>
			
		<div class="advisement">
			For table-track and table-track-grouping 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.
		</div>
		
		<p>
			The <b>position of any table-caption having "bottom" as 'caption-side'</b> within the table is defined as the rectangle whose:
			<ul class="compact">
				<li>width/height is:
					<ul><li>the width/height assigned to the caption during layout</ul>
				<li>top location is the sum of:
					<ul><li>the height reserved for top captions (including margins), if any
						<li>padding-top and border-top-width of the table
						<li>the height of all <a href="#visible-track">visible</a> rows
						<li>padding-bottom and border-bottom-width of the table
						<li>the height reserved for previous bottom captions (including margins), if any
						<li>any necessary extra top margin remaining after collapsing margins with the previous bottom caption, if any.</ul>
				<li>left location is the sum of:
					<ul><li>the margin left of the caption
						<li>half of (the table width minus the width of caption and its total horizontal margin).</ul>
			</ul>
			
		<div class="advisement">
			<strong>Cell overflow: </strong>
			If the table is laid out <a>in fixed mode</a>,
			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 <a href="#visible-track">visible</a>,
				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).
			<a class="hint" href="https://jsfiddle.net/24bz3Lp1/">!Testcase</a>
			<a class="hint" href="https://jsfiddle.net/24bz3Lp1/1/">!Testcase</a>
			<a class="hint" href="https://jsfiddle.net/24bz3Lp1/3/">Testcase</a>
		</div>

		<div class="advisement">
			<strong>Visible tracks: </strong>
			For the purpose of this algorithm, a column or row 
			is considered a <dfn id="visible-track">visible track</dfn> if both of those conditions apply:
			<ul><li>It is not explicitly defined by a table-column or table-row element, or:<br/>
					It is explicitly defined by a table-column or table-row element that does not have visibility:collapse
				<li>It is not logically contained in a table-column-grouping or table-row-grouping element, or:<br/>
					It is logically contained in a table-column-grouping or table-row-grouping element that does not have visibility:collapse</ul>
		</div>

		<div class="example">
			<figure>
				<img alt="A table with a caption above it, showing how the caption margins are totally nested inside the table margins, but are outside the border-box of the table nonetheless." src="images/table_container.png" width="533" height="483">
				<figcaption>Diagram of a table with a caption above it.</figcaption>
			</figure>
		</div>
		
		<div class="note">
			<a id="spanning-ghost-rows" class="hint" href="https://jsfiddle.net/3pox7b4f/">~Testcase</a>
			<a class="hint" href="https://jsfiddle.net/3pox7b4f/1/">!!Testcase</a>
			<a class="hint" href="https://jsfiddle.net/3pox7b4f/3/">!!Testcase</a>
			<a class="hint" href="https://jsfiddle.net/3pox7b4f/4/">!!Testcase</a>
			<a class="hint" href="https://jsfiddle.net/3pox7b4f/5/">Testcase</a>
		</div>

<!--------------------------------------------------------------------------------->
<h2 id="rendering">Rendering</h2>

	<!--------------------------------------------------------------------------------->
	<h3 id="paint-order">Paint order of cells</h3>

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

	<!--------------------------------------------------------------------------------->
	<h3 id="empty-cell-rendering">Empty cell rendering (separated-borders mode)</h3>

		<p>
			Cells are <dfn id="empty-cell">empty</dfn> unless they contain one or more of the following:
			<ul><li>floating content, or
				<li>in-flow content (other than white space that has been collapsed away by the 'white-space' property handling).</ul>

		<div class="issue">
			Chrome simplified this to just matching :empty.
		</div>

		<pre class="propdef">
			Name: empty-cells
			Value: show | hide
			Initial: show
			Applies to: <code>table-cell</code> boxes
			Inherited: yes
			Media: visual
		</pre>

		<p>
			<a>In collapsed-borders mode</a>,
				this property has no effect.

		<p>
			<a>In separated-borders mode</a>,
				this property controls the rendering of borders and backgrounds
				around cells that have no visible content.

		<p>
			When this property has the value <code>hide</code>,
				no borders or backgrounds are drawn around/behind empty cells.

		<p>
			Furthermore, if all the cells in a row have a value of <code>hide</code> and have no visible content,
				then the row has zero height and the vertical border-spacing applies to one side of the row only.

		<div class="issue">
			<p>The behavior of empty-cells:hide is a strange exception.
			<ol><li>Why not just say that the cell has "visibility: hidden"?
				<li>Why not just say that the row has "display: none"?
					<a class="hint" href="https://jsfiddle.net/2oy2qt2q/3/">!!Testcase</a>
			</ol>
		</div>

		<div class="example">
			<p>For example, take the following markup and css:
			<xmp class="lang-markup">
				<table>
					<td><span></span></td>
					<td></td>
					<td><span></span></td>
				</table>
			</xmp>
			<xmp class="lang-css">
				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; }
			</xmp>
			<p>The correct rendering of this code snippet is depicted here:
			<figure>
				<img src="images/empty-cells-example.gif" width=500 height=300 />
				<figcaption>Rendering of three columns whose middle one is hidden by empty-cells:hide</figcaption>
			</figure>
		</div>

	<!--------------------------------------------------------------------------------->
	<h3 id="drawing-backgrounds-and-borders">Drawing backgrounds and borders</h3>
	
		<!--------------------------------------------------------------------------------->
		<h4 id="drawing-table-backgrounds-and-borders">Drawing table backgrounds and borders</h4>
		
			<p>
				Unlike other boxes types, table and inline-table boxes 
					do not render their background and borders around their entire client rect.
				Indeed, the table captions are positioned between the table margins and its borders.
				Given backgrounds extends and original form the border-box area of an element
					(or one of the area contained inside the boder-box area like content-box),
					they are affected by this positioning scheme.
				
			<p>
				The padding of the table is accounted around the area occupied by the row/column grid
				Borders of the table box are rendered around the area occupied by the row/column grid and its padding.
				That area which contains the borders is the rectangular area 
					which comprises of the full width of the table box, 
					but does not contain the vertical areas occupied by the captions or their margins.
				
			<p>
				The border-box of the table is relative to the area described previously.
				The padding-box of the table is the rectangular area contained inside the border-box which
					does not interesct with the table borders (independently of whether the table draws them or not).
				The content-box of the table is the rectangular area contained inside the padding-box which
					does not interesct with the table paddings (this includes border-spacings at the edge of the table).
				
		<!--------------------------------------------------------------------------------->
		<h5 id="drawing-collapsed-borders-1">Changes in collapsed-borders mode</h3>

			<p>
				When a table is laid out <a>in collapsed-borders mode</a>,
					the rendering of its borders on and those of its table-cells is modified.
				The following rules describe in which way.
				
			<p cass="note">
				The rules for background and borders painting defined in [[#drawing-backgrounds-and-borders]] 
					still apply if they are not overriden.
					
			<p>
				Borders of a <a>table-root</a> element are not laid out <a>in collapsed-borders mode</a>,
					except if the 'border-image' property is set (or if the table has no cell).
					
			<p>
				In this 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 <a>table-root</a> element.

			<p class="note">
				Even if they are not drawn by the table, the table borders still occupy their space in the layout. 
					Cells will <a href="#drawing-cell-borders">render those shared borders</a>.
		
		<!--------------------------------------------------------------------------------->
		<h4 id="drawing-cell-backgrounds">Drawing cell backgrounds</h4>

			<p class="advisement">
				Anonymous table-cells added by the <a href="#missing-cells-fixup">missing cells fixup</a> step
					do not render any of their backgrounds.

			<p>
				In addition to its own 'background', <a>table-cell</a> boxes also 
					render the backgrounds of the <a>table-track</a> and <a>table-track-grouping</a> 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.

			<p>
				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 on an element in one of the layers will only be visible
					if the layers above it have a transparent background.

			<p><figure>
				<img src="https://www.w3.org/TR/CSS2/images/tbl-layers.png">
				<figcaption>Schema of table layers.</figcaption>
				</figure></p>

			<ol start="0">
				<li>The table background is being rendered by the table,
					and does not affect the cell background.

				<li>The first background drawn by a cell is the background of its originating column group.
					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.

				<li>The second background drawn by a cell is the background of its originating column.
					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.

				<li>The third background drawn by a cell is the background of its originating row group.
					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.

				<li>The fourth background drawn by a cell is the background of its originating row.
					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.

				<li>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.
			</ol>

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

		<!--------------------------------------------------------------------------------->
		<h4 id="drawing-cell-borders">Drawing cell borders</h4>
		
			<p>
				In separated-borders mode, borders of table cells are rendered as usual. 
								
			<!--------------------------------------------------------------------------------->
			<h5 id="drawing-collapsed-borders-2">Changes in collapsed-borders mode</h3>

			<p>
				Borders of a <a>table-cell</a> element are rendered <a>in collapsed-borders mode</a>
					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.

			<p>
				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.
					<span class="hint">See [[#paint-order]] and [[#border-conflict-resolution-algorithm]].</span>

		<!--------------------------------------------------------------------------------->
		<h4 id="border-style-overrides">Border styles (collapsed-borders mode)</h4>

			<p>
				Some of the values of the 'border-style' have different meanings for tables <a>in collapsed-borders mode</a> than usual.
				Those definitions override the default behavior for 'border-style' values.

				: hidden
				:: Same as <code>none</code>, but also inhibits any other border (see [[#border-specificity]]).
				: inset
				:: Same as <code>ridge</code>.
				: outset
				:: Same as <code>groove</code>.


<!--------------------------------------------------------------------------------->
<h2 id="fragmentation">Fragmentation</h2>
	
	<!--------------------------------------------------------------------------------->
	<h3 id="breaking-rules">Breaking across fragmentainers</h3>
	
		<p>
			When fragmenting a table, user agents must attempt 
				to preserve the table rows unfragmented
				if their height is at least twice smaller than the table width.
			Other rows are said <dfn id="freely-fragmentable">freely fragmentable</dfn>.
				
		<p>
			When a table doesn't fit entirely in a fragmentainer,
				and the first row that does not fit in the fragmentainer is not <a>freely fragmentable</a>.
				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.
			Cells spanning across those two rows are 
				divided into two fragments (one in each fragmentainer),
				whose height is kept equal to the rows they span in each of these fragments, and 
				their content is fragmented among those two fragments, in parallel.
		
		<figure>
			<img src="./images/CSS-Tables-Fragmentation-1.svg" style="width:100%; max-width: 500px;" />
			<figcaption>Expected rendering of table fragmented across two pages</figcaption>
		</figure>
		
		<p>
			When there is no row fitting entirely in the current fragmentainer
			or when the first row that does not fit in the fragmentainer is <a>freely fragmentable</a>,
				user agents must split each cell of the row in two fragments (one in each fragmentainer)
				so that all fragments in the same fragmentainer continue to share the same height.
			Then, the user agent must fragment the content of each cell 
				among its two fragments, in parallel. 
				
		<figure>
			<img src="./images/CSS-Tables-Fragmentation-2.svg" style="width:100%; max-width: 500px;" />
			<figcaption>Expected rendering of table containing a tall row fragmented across two pages</figcaption>
		</figure>
	
		<p>
			When 'break-before' or 'break-after' is applied 
			to a <a>table-row-grouping</a> or a <a>table-row</a> box,
				the user agent has to insert some horizontal 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.
		
	<!--------------------------------------------------------------------------------->
	<h3 id="repeated-headers">Repeating headers across pages</h3>

		<p>
			When rendering the document into a paged media, 
				user agents must repeat 
					<a href="#table-header-group">header rows</a> and 
					<a href="#table-footer-group">footer rows</a>  
				on each page spanned by a table.
				
		<p>
			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.
			
		<figure>
			<img src="./images/CSS-Tables-Repeating-Headers.svg" style="width:100%; max-width: 500px;" />
			<figcaption>Expected rendering of table with headers and footers fragmented across two pages</figcaption>
		</figure>
			
		<p>
			When doing so doesn't leave enough space to insert at least one content row,
				users agents must drop the repeated footer.
			
		<p>
			When doing so still doesn't leave enough space to insert at least one content row,
				users agents must drop the repeated header.
				
		<p class="advisement">
			User agents may decide to extend this behavior to every fragmentation context,
				and not just to the main document's paging fragmentation context. 
			User-agents that are rendering static documents are more likely to adopt this behavior,
				though this is not required per spec.

<!--------------------------------------------------------------------------------->
<h2 id="security">Security Considerations</h2>

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

<!--------------------------------------------------------------------------------->
<h2 id="privacy">Privacy Considerations</h2>

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

<!--------------------------------------------------------------------------------->
<h2 id="bug-list">List of bugs being tracked</h2>

<p style="font-size: italic">
	This section is not normative.

<ul class="bug-list">

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/jWzpjq?editors=1100">
				Align=center attribute overrides css margins in Edge
			</a>
		</summary><aside>
			Chrome and Firefox let CSS win.<br/>
			Edge hides every border + table/row-group/row background.<br/>
			<br/>
			This specification says that Chrome and Firefox are right.<br/>
			[[#mapping]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/ZQxVMo?editors=1100">
				Chrome applies nowrap quirks mode fix in DOCTYPE documents too
			</a>
		</summary><aside>
			Edge and Firefox do not apply the fix in normal mode.<br/>
			Chrome also applies it for css widths, which is not what the spec says to do.<br/>
			<br/>
			The WHATWG spec says that Chrome is wrong.<br/>
			This spec is aiming to state the same thing.<br/>
			[[#mapping]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/RrMvPR?editors=1100">
				Edge does not account for widths of spanned cells
			</a>
		</summary><aside>
			Chrome and Firefox merge the two columns so are not affected.<br/>
			Edge does not then is confused about what to do.<br/>
			<br/>
			The specs says that Edge is wrong.<br/>
			[[#dimensioning-the-row-column-grid]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="https://jsfiddle.net/6L94pxgn/1/#6188753">
				Chrome and Gecko do not apply display:table-cell on &lt;button>
			</a>
		</summary><aside>
			Also <a href="https://jsfiddle.net/6L94pxgn/3/">@lt;fieldset></a>. 
			This specification says that Chrome and Firefox are worng.<br/>
			[[#style-overrides]]
		</aside></details>
	</li>
	
	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/xZWmXy?editors=1100">
				Edge's table-cell width unexplainably low due to percentage-max-width on content and colspan
			</a>
		</summary><aside>
			Edge has issues with percentage widths.<br/>
			<br/>
			This specification should say that Chrome and Firefox are right, I guess.<br/>
			[[#computing-cell-measures]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/PZRdzo?editors=1100">
				Table boxes should be wide enough to contain the caption
			</a>
		</summary><aside>
			Chrome uses the CSS21 algorithm that fulfill this.<br/>
			Firefox and Edge use David Baron's algorithm that doesn't.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			Chrome behavior is simpler to spec but not intuitive.<br/>
			[[#computing-the-table-width]]
			<br/>
			<br/>
			This may be solved by <a href="https://lists.w3.org/Archives/Public/www-style/2010Sep/0186.html">
				www-list</a> on the width of the table boxes in relation to their table captions
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/VeXVwz?editors=1100">
				Tables containing no row cannot have height in Chrome, but can in Edge/Firefox
			</a>
		</summary><aside>
			Chrome has table height = 0px.<br/>
			Firefox and Edge have table height = specified height.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			Firefox and Edge match author intentions better.<br/>
			[[#computing-the-table-height]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/yeKRGW?editors=1100">
				Table-layout:fixed causes different width distribution in Chrome
			</a>
		</summary><aside>
			Chrome starts to value px then percentages.<br/>
			Others continue to value percentage then px.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			It is intended to specify the Edge/Firefox behavior.<br/>
			[[#width-distribution]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/XXEoWe?editors=1100">
				Chrome distributes the height to each row differently then IE and firefox
			</a>
		</summary><aside>
			Chrome distributes rather equally.<br/>
			Edge and Firefox work more similarly to width distribution.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			I think it makes sense to behave similarly for width and height, though.<br/>
			[[#height-distribution]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/PZRdOP?editors=1100">
				Height of rows which can overflow varies in Chrome vs Edge
				(percentage heights during min-height computation)
			</a>
		</summary><aside>
			Chrome chooses table constraints over the no-scroll constraint.<br/>
			Edge and Firefox do the opposite.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			Edge's behavior is right by default due to CSS Sizing, though.<br/>
			It would make sense to do what Chrome is doing when elements have non-visible overflow-y.<br/>
			[[#height-distribution]] <a href="#min-content-and-percentages">#REF</a>
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/MKVPGR?editors=1100">
				Height specified on row groups is not interoperable
			</a>
		</summary><aside>
			Chrome ignores the height.<br/>
			Firefox respects the height.<br/>
			IE applies the height to each cell.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			An author would expect the Firefox behavior.<br/>
			[[#height-distribution]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/MKVPGR?editors=1100">
				Min-Height specified on rows is not interoperable
			</a>
		</summary><aside>
			Chrome and Firefox ignore the height.<br/>
			Edge applies the height.<br/>
			<br/>
			This specification has no opinion yet on the matter.<br/>
			An author would expect the Edge behavior.<br/>
			[[#height-distribution]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://jsfiddle.net/ArtyomShegeda/Ffjhn/1/">
				Table with interleaved td[rowspan] rendered wrong in IE (145069)
			</a>
		</summary><aside>
			Edge height-sizing has issues with this crossed-rowspan table.<br/>
			<br/>
			There is no doubt this is a bug, but it is a good test case for the algorithm.<br/><br/>
			[[#height-distribution]]
		</aside></details>
	</li>

	<li>
		<details><summary tabindex="0">
			<a href="http://codepen.io/FremyCompany/pen/MKVqXQ?editors=1100">
				Row with explicit 'visibility:visible' lose background color
				when parent table has 'visibility: hidden'
			</a>
		</summary><aside>
			Chrome only hides table background + border.<br/>
			Firefox hides table background + border, and row-group background.<br/>
			Edge hides every border + table/row-group/row background.<br/>
			<br/>
			This specification currently says that Chrome is right.<br/>
			[[#drawing-cell-backgrounds]]<br/>
			<div class="issue">
				Should we hide the row-group background
					by saying cells only draw the backgrounds
					of visibility:visible grouping elements?
			</div>
		</aside></details>
	</li>

</ul>

<style>

	ul.bug-list {
		list-style-type: none;
		padding: 0;
		font-size: 80%;
	}
	ul.bug-list > li {
		margin: 0; margin-bottom: 10px;
	}
	ul.bug-list > li > details {
		background: #efefef;
		padding: 10px;
	}
	ul.bug-list > li > details > aside {
		background: #f7f7f7;
		padding: 10px; font-weight: normal;
	}
	ul.bug-list > li > details > summary > a {
		border-bottom-color: transparent;
	}

</style>

<!--------------------------------------------------------------------------------->
<h2 id="appendices">Appendices</h2>

	<!--------------------------------------------------------------------------------->
	<h3 id="mapping">Mapping between CSS &amp; HTML attributes</h3>

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

		<div class="note">
			Some extensions to CSS have been used for contraints not mappable to current CSS constructs
			</div>

		<pre class="lang-css">

	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; }

<!--
	Non-border built-ins
-->
	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; }

<!--
	Border built-ins
-->


<!--
	FRAME (part 1/2)
	http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_table_frame
-->
	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;
	}


<!--
	RULES (part 1/3)
	http://codepen.io/FremyCompany/pen/GopJMp
-->
	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;
	}

<!--
	BORDER
	http://codepen.io/FremyCompany/pen/EPVjNp
-->
	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);
	}

<!--
	RULES (part 2/3)
	http://codepen.io/FremyCompany/pen/GopJMp
-->
	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;
	}

<!--
	RULES (part 3/3)
	http://codepen.io/FremyCompany/pen/jWbPXY
	https://jsfiddle.net/ewv08n0r/
-->
	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;
	}

<!--
	FRAME (part 2/2)
	http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_table_frame
-->
	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;
	}

<!--
	Others:
-->
	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 /(+|-|)(&#91;0-9&#93;+(&#91;.&#93;&#91;0-9&#93;+|)|(&#91;.&#93;&#91;0-9&#93;+))&#91;%&#93;/) */ {
		width: /*(parseInt($w) * 1px)*/;
	}
	table[height=$h] /* if(parseInt($h) > 0) {
		height: /*(parseInt($h) * 1px)*/;
	}
	table[height=$h] /* if($h matches /(+|-|)(&#91;0-9&#93;+(&#91;.&#93;&#91;0-9&#93;+|)|(&#91;.&#93;&#91;0-9&#93;+))&#91;%&#93;/) */ {
		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;
	}

<!--
	NON-TABLE ATTRIBUTES:
-->
	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;
	}

</pre>

	<div class="note">
		Some of the content here came from the WHATWG spec on the
		<a href="https://html.spec.whatwg.org/#tables-2">HTML to CSS mapping of tables</a>.
		However, since they include <a href="https://jsfiddle.net/8t78exf1/">things which are not true</a> 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!
	</div>

				
<!--------------------------------------------------------------------------------->
<h2 id="TODO">(link here for missing sections)</h2>
<style>

	.hint { opacity: 0.5; transition: opacity 0.25s; }
	.hint:hover { opacity: 1; }

	.highlight { background: yellow; }

	/* fallback for summary/details */
	details { display: block; font-weight: normal !important; }
	details:not([open]) > aside { display: none; }
	details:not([open]) > summary { display: block; }
	details:not([open]) > summary:focus + aside { display: block; }
	#if-css-supports ::-webkit-details-marker, details:not([open]) > aside { display: block; }
	#if-css-supports ::-moz-details-marker,    details:not([open]) > aside { display: block; }
	#if-css-supports ::-ms-details-marker,     details:not([open]) > aside { display: block; }
	#if-css-supports ::details-marker,         details:not([open]) > aside { display: block; }

</style>