4

taken from HTML5 A vocabulary and associated APIs for HTML and XHTML Editor's Draft 27 October 2009

4.9.1 The table element

Status: open issues around @summary, additions to cell. API, and @orientation

The table element represents data with more than one dimension, in the form of a table.

The table element takes part in the table model.

Tables must not be used as layout aids. Historically, some Web authors have misused tables in HTML as a way to control their page layout. This usage is non-conforming, because tools attempting to extract tabular data from such documents would obtain very confusing results. In particular, users of accessibility tools like screen readers are likely to find it very difficult to navigate pages with tables used for layout.

There are a variety of alternatives to using HTML tables for layout, primarily using CSS positioning and the CSS table model.

User agents that do table analysis on arbitrary content are encouraged to find heuristics to determine which tables actually contain data and which are merely being used for layout. This specification does not define a precise heuristic.

Tables have rows and columns given by their descendants. A table must not have an empty row or column, as described in the description of the table model.

The orientation attribute has cna have the values horizontal and vertical, which indicate whether the table should be read in rows (horizontally), in colums (rows). rows is the default value. Auditory user agents MUST read the table according to this attribute, across rows when it is set to rows and down columns when it is set to columns. User Agents MAY make use of the orientation when splitting tables, such as for small screens or printing. See the National Braille Association's Tape Recording Manual [http://www.rfbd.org/about.htm] for further explaination of rows and columns.

The summary attribute provides a summary of the table's purpose for user agents rendering to non-visual media such as speech and Braille.

Earlier versions of HTML suggested using summary to provide structural information about the table. This version adds the orientation attribute, and methods on the cell interface that allow user agents to derive that information from the table markup.

Authors SHOULD use summary to provide information that is obvious to visual users of the table, but would be difficult to determine by navigating the table cell by cell in an auditory user agent, and which cannot be derived by the user agent from the markup. The information provided by the summary is needed by users who cannot see the table, but would usually be redundant for those who can. Authors SHOULD use summary to highlight general idea that is to be drawn from the table, describe trends, high and low points, and the like. When a user with a non-visual user agent encounters a table, the summary should give him enough information to decide if he wishes to explore the table in detail, which can be quite time-consuming.

The information provided by the summary is needed by users who cannot see the table, but would usually be redundant for those who can. For tables where the relationships are not obvious to users who can see the layout, or in other situations where text describing the structure of the table might be useful to sighted users as well as users of screen-readers and Braille devices, it is better to describe the structure using the a


	caption


	legend

, or surrounding text instead of, or in addition to,


	summary

. Authors MUST do this in a way that is associated with the table via markup, such that user agents and assistive technology can programmatically determine the relationship. When using summary in combination with another technique, authors MUST NOT duplicate the text, but instead use summary for the parts of the description that are only useful to users who cannot see the table.

User agents MUST expose summary text in the accessibility API on their platform as specified in the Mappings from HTML to Platform APIs document [note: This document is still under development and does not yet have a stable URL. It will have one before last call]. Visual user agents SHOULD NOT render summary visually in non-editing scenarios, and SHOULD render summary visually in editing scenarios. Non-visual user agents MUST render summary.

Authoring tools MUST make it possible for authors to add and edit summary. WSYIWYG authoring tools SHOULD render it visually.

Examples:

Significant Floods of the 20th Century
[M, million; B, billion]
Flood Type	Map no.	Date	Area or stream with flooding	Reported deaths	Approximate cost (uninflated)	Comments
Regional flood	1	Mar.-Apr. 1913	Ohio, statewide	467	$143M	Excessive regional rain.
2	Apr.-May 1927	Mississippi River from Missouri to Louisiana	unknown	$230M	Record discharge downstream from Cairo, Illinois.
3	Mar. 1936	New England	150+	$300M	Excessive rainfall on snow.
4	July 1951	Kansas and Neosho River Basins in Kansas	15	$800M	Excessive regional rain.
5	Dec. 1964 - Jan. 1965	Pacific Northwest	47	$430M	Excessive rainfall on snow.
Flash flood	21	June 14, 1903	Willow Creek in Oregon	225	unknown	City of Heppner, Oregon, destroyed.
22	June 9-10, 1972	Rapid City, South Dakota	237	$160M	15 inches of rain in 5 hours.
23	July 31, 1976	Big Thompson and Cache la Poudre Rivers in Colorado	144	$39M	Flash flood in canyon after excessive rainfall.
Ice-jam flood	25	May 1992	Yukon River Alaska	0	unknown	100-year flood on Yukon River.
Storm-surge flood	26	Sept. 1990	Galveston, Texas	6,000+	unknown	Hurricane.
27	Sept. 1938	Northeast United States	494	$360M	Hurricane.
Dam-failure flood	29	Feb. 2, 1972	Buffalo Creek in West Virginia	125	$60M	Dam failure after excessive rainfall.
30	June 5, 1976	Teton River in Idaho	11	$400M	Earthen dam breached.
Mudflow flood	32	May 18, 1980	Toutle and lower Cowlitz Rivers in Washington	60	unknown	Result of eruption of Mt. St. Helens.

The orientation attribute in the horizontal state indicates that the table should be read across.

The caption includes the title of the table, and a key to abbreviations used in the table for Millions and Billions. This information is needed by all users of the table, and so is in the visible caption.

TH elements with ID attributes are used to associate cells with their related headers. The cell api has access to these headers

The first cell in this table is also a TH, and will be available via the cell API.

The following table has an unusual layout which will not be obvious to many users who can see it. It might benefit from a visible description explaining to the way the table is laid out, something like "Characteristics are given in the second column, with the negative side in the left column and the positive side in the right column". In this case, it is best to describe the table in visible text. The text MUST be marked up in such a way that assistive technologies can determine programmatically that it is a description for the table.

Authors may also use other techniques, or combinations of the above techniques, as appropriate.

The best option, of course, rather than writing a description explaining the way the table is laid out, is to adjust the table such that no explanation is needed.

Characteristics with positive and negative sides
Negative	Characteristic	Positive
Sad	Mood	Happy
Failing	Grade	Passing

The caption IDL attribute must return, on getting, the first caption element child of the table element, if any, or null otherwise. On setting, if the new value is a caption element, the first caption element child of the table element, if any, must be removed, and the new value must be inserted as the first node of the table element. If the new value is not a caption element, then a HIERARCHY_REQUEST_ERR DOM exception must be raised instead.

The createCaption() method must return the first caption element child of the table element, if any; otherwise a new caption element must be created, inserted as the first node of the table element, and then returned.

The deleteCaption() method must remove the first caption element child of the table element, if any.

The tHead IDL attribute must return, on getting, the first thead element child of the table element, if any, or null otherwise. On setting, if the new value is a thead element, the first thead element child of the table element, if any, must be removed, and the new value must be inserted immediately before the first element in the table element that is neither a caption element nor a colgroup element, if any, or at the end of the table if there are no such elements. If the new value is not a thead element, then a HIERARCHY_REQUEST_ERR DOM exception must be raised instead.

The createTHead() method must return the first thead element child of the table element, if any; otherwise a new thead element must be created and inserted immediately before the first element in the table element that is neither a caption element nor a colgroup element, if any, or at the end of the table if there are no such elements, and then that new element must be returned.

The deleteTHead() method must remove the first thead element child of the table element, if any.

The tFoot IDL attribute must return, on getting, the first tfoot element child of the table element, if any, or null otherwise. On setting, if the new value is a tfoot element, the first tfoot element child of the table element, if any, must be removed, and the new value must be inserted immediately before the first element in the table element that is neither a caption element, a colgroup element, nor a thead element, if any, or at the end of the table if there are no such elements. If the new value is not a tfoot element, then a HIERARCHY_REQUEST_ERR DOM exception must be raised instead.

The createTFoot() method must return the first tfoot element child of the table element, if any; otherwise a new tfoot element must be created and inserted immediately before the first element in the table element that is neither a caption element, a colgroup element, nor a thead element, if any, or at the end of the table if there are no such elements, and then that new element must be returned.

The deleteTFoot() method must remove the first tfoot element child of the table element, if any.

The tBodies attribute must return an HTMLCollection rooted at the table node, whose filter matches only tbody elements that are children of the table element.

The createTBody() method must create a new tbody element, insert it immediately after the last tbody element in the table element, if any, or at the end of the table element if the table element has no tbody element children, and then must return the new tbody element.

The rows attribute must return an HTMLCollection rooted at the table node, whose filter matches only tr elements that are either children of the table element, or children of thead, tbody, or tfoot elements that are themselves children of the table element. The elements in the collection must be ordered such that those elements whose parent is a thead are included first, in tree order, followed by those elements whose parent is either a table or tbody element, again in tree order, followed finally by those elements whose parent is a tfoot element, still in tree order.

The behavior of the insertRow(index) method depends on the state of the table. When it is called, the method must act as required by the first item in the following list of conditions that describes the state of the table and the index argument:

If index is less than −1 or greater than the number of elements in rows collection:: The method must raise an INDEX_SIZE_ERR exception.
If the rows collection has zero elements in it, and the table has no tbody elements in it:: The method must create a tbody element, then create a tr element, then append the tr element to the tbody element, then append the tbody element to the table element, and finally return the tr element.
If the rows collection has zero elements in it:: The method must create a tr element, append it to the last tbody element in the table, and return the tr element.
If index is missing, equal to −1, or equal to the number of items in rows collection:: The method must create a tr element, and append it to the parent of the last tr element in the rows collection. Then, the newly created tr element must be returned.
Otherwise:: The method must create a tr element, insert it immediately before the indexth tr element in the rows collection, in the same parent, and finally must return the newly created tr element.

When the deleteRow(index) method is called, the user agent must run the following steps:

If index is equal to −1, then index must be set to the number if items in the rows collection, minus one.
Now, if index is less than zero, or greater than or equal to the number of elements in the rows collection, the method must instead raise an INDEX_SIZE_ERR exception, and these steps must be aborted.
Otherwise, the method must remove the indexth element in the rows collection from its parent.

The orientation IDL attribute must reflect the content attribute of the same name.

The summary IDL attribute must reflect the content attribute of the same name.

4.9.2 The


caption

element

The caption element represents the title of the


table

that is its parent, if it has a parent and that is a table element.

The caption element takes part in the table model.

When a table element is the only content in a figure element's dd, the


caption

element should be omitted in favor of the dt.

A caption can introduce context for a table, making it significantly easier to understand.

	1	2	3	4	5	6
1	2	3	4	5	6	7
2	3	4	5	6	7	8
3	4	5	6	7	8	9
4	5	6	7	8	9	10
5	6	7	8	9	10	11
6	7	8	9	10	11	12

Table 1.

This table shows the total score obtained from rolling two six-sided dice. The first row represents the value of the first die, the first column the value of the second die. The total is given in the cell that corresponds to the values of the two dice.
	1	2	3	4	5	6
1	2	3	4	5	6	7
2	3	4	5	6	7	8
3	4	5	6	7	8	9
4	5	6	7	8	9	10
5	6	7	8	9	10	11
6	7	8	9	10	11	12

4.9.3 The


colgroup

element

If the colgroup element contains no col elements, then the element may have a span content attribute specified, whose value must be a valid non-negative integer greater than zero.

The colgroup element and its span attribute take part in the table model.

The span IDL attribute must reflect the content attribute of the same name. The value must be limited to only non-negative numbers greater than zero.

4.9.4 The col element

The element may have a


span

content attribute specified, whose value must be a valid non-negative integer greater than zero.

The col element and its span attribute take part in the table model.

The span IDL attribute must reflect the content attribute of the same name. The value must be limited to only non-negative numbers greater than zero.

4.9.5 The tbody element

The tbody element represents a block of rows that consist of a body of data for the parent table element, if the tbody element has a parent and it is a table.

The tbody element takes part in the table model.

The rows attribute must return an HTMLCollection rooted at the element, whose filter matches only tr elements that are children of the element.

The insertRow(index) method must, when invoked on an element table section, act as follows:

If index is less than −1 or greater than the number of elements in the rows collection, the method must raise an INDEX_SIZE_ERR exception.

If index is missing, equal to −1, or equal to the number of items in the rows collection, the method must create a tr element, append it to the element table section, and return the newly created tr element.

Otherwise, the method must create a tr element, insert it as a child of the table section element, immediately before the indexth tr element in the rows collection, and finally must return the newly created tr element.

The deleteRow(index) method must remove the indexth element in the rows collection from its parent. If index is less than zero or greater than or equal to the number of elements in the rows collection, the method must instead raise an INDEX_SIZE_ERR exception.

4.9.6 The thead element

The thead element represents the block of rows that consist of the column labels (headers) for the parent table element, if the thead element has a parent and it is a table.

The thead element takes part in the table model.

4.9.7 The tfoot element

The tfoot element represents the block of rows that consist of the column summaries (footers) for the parent table element, if the tfoot element has a parent and it is a table.

The tfoot element takes part in the table model.

4.9.8 The tr element

The tr element takes part in the table model.

The rowIndex attribute must, if the element has a parent table element, or a parent tbody, thead, or tfoot element and a grandparent table element, return the index of the tr element in that table element's rows collection. If there is no such table element, then the attribute must return −1.

The sectionRowIndex attribute must, if the element has a parent table, tbody, thead, or tfoot element, return the index of the tr element in the parent element's rows collection (for tables, that's the rows collection; for table sections, that's the rows collection). If there is no such parent element, then the attribute must return −1.

The cells attribute must return an HTMLCollection rooted at the tr element, whose filter matches only td and th elements that are children of the tr element.

The insertCell(index) method must act as follows:

If index is less than −1 or greater than the number of elements in the cells collection, the method must raise an INDEX_SIZE_ERR exception.

If index is missing, equal to −1, or equal to the number of items in cells collection, the method must create a td element, append it to the tr element, and return the newly created td element.

Otherwise, the method must create a td element, insert it as a child of the tr element, immediately before the indexth td or th element in the cells collection, and finally must return the newly created td element.

The deleteCell(index) method must remove the indexth element in the cells collection from its parent. If index is less than zero or greater than or equal to the number of elements in the cells collection, the method must instead raise an INDEX_SIZE_ERR exception.

4.9.9 The td element

The td element and its colspan, rowspan, and headers attributes take part in the table model.

4.9.10 The th element

The th element may have a scope content attribute specified. The


scope

attribute is an enumerated attribute with five states, four of which have explicit keywords:

The th element and its colspan, rowspan, headers, and scope attributes take part in the table model.

The scope IDL attribute must reflect the content attribute of the same name.

ID	Measurement	Average	Maximum
	Cats
93	Legs	3.5	4
10	Tails	1	1
	English speakers
32	Legs	2.67	4
35	Tails	0.33	1

4.9.11 Attributes common to td and th elements

The td and

th

elements may have a colspan content attribute specified, whose value must be a valid non-negative integer greater than zero.

The td and

th

elements may also have a rowspan content attribute specified, whose value must be a valid non-negative integer.

These attributes give the number of columns and rows respectively that the cell is to span. These attributes must not be used to overlap cells, as described in the description of the table model.

The td and

th

element may have a headers content attribute specified. The


headers

attribute, if specified, must contain a string consisting of an unordered set of unique space-separated tokens, each of which must have the value of an ID of a th element taking part in the same table as the

td

or th element (as defined by the table model).

A th element with ID id is said to be directly targeted by all

td

and th elements in the same table that have headers attributes whose values include as one of their tokens the ID id. A th element A is said to be targeted by a th or td element B if either A is directly targeted by B or if there exists an element C that is itself targeted by the element B and A is directly targeted by C.

The colspan, rowspan, and headers attributes take part in the table model.

The td and

th

elements implement interfaces that inherit from the HTMLTableCellElement interface:

The colSpan IDL attribute must reflect the content attribute of the same name. The value must be limited to only non-negative numbers greater than zero.

The rowSpan IDL attribute must reflect the content attribute of the same name. Its default value, which must be used if parsing the attribute as a non-negative integer returns an error, is 1.

The headers IDL attribute must reflect the content attribute of the same name.

The cellIndex IDL attribute must, if the element has a parent tr element, return the index of the cell's element in the parent element's cells collection. If there is no such parent element, then the attribute must return 0.

4.9.12 Processing model

Status: Last call for comments

The various table elements and their content attributes together define the table model.

A table consists of cells aligned on a two-dimensional grid of slots with coordinates (x, y). The grid is finite, and is either empty or has one or more slots. If the grid has one or more slots, then the x coordinates are always in the range 0 ≤ x < x_width, and the y coordinates are always in the range 0 ≤ y < y_height. If one or both of x_width and y_height are zero, then the table is empty (has no slots). Tables correspond to table elements.

A cell is a set of slots anchored at a slot (cell_x, cell_y), and with a particular width and height such that the cell covers all the slots with coordinates (x, y) where cell_x ≤ x < cell_x+width and cell_y ≤ y < cell_y+height. Cells can either be data cells or header cells. Data cells correspond to td elements, and header cells correspond to th elements. Cells of both types can have zero or more associated header cells.

It is possible, in certain error cases, for two cells to occupy the same slot.

A row is a complete set of slots from x=0 to x=x_width-1, for a particular value of y. Rows correspond to tr elements.

A column is a complete set of slots from y=0 to y=y_height-1, for a particular value of x. Columns can correspond to col elements, but in the absence of col elements are implied.

A row group is a set of rows anchored at a slot (0, group_y) with a particular height such that the row group covers all the slots with coordinates (x, y) where 0 ≤ x < x_width and group_y ≤ y < group_y+height. Row groups correspond to tbody, thead, and tfoot elements. Not every row is necessarily in a row group.

A column group is a set of columns anchored at a slot (group_x, 0) with a particular width such that the column group covers all the slots with coordinates (x, y) where group_x ≤ x < group_x+width and 0 ≤ y < y_height. Column groups correspond to colgroup elements. Not every column is necessarily in a column group.

Row groups cannot overlap each other. Similarly, column groups cannot overlap each other.

A cell cannot cover slots that are from two or more row groups. It is, however, possible for a cell to be in multiple column groups. All the slots that form part of one cell are part of zero or one row groups and zero or more column groups.

In addition to cells, columns, rows, row groups, and column groups, tables can have a caption element associated with them. This gives the table a heading, or legend.

A table model error is an error with the data represented by table elements and their descendants. Documents must not have table model errors.

4.9.12.1 Forming a table

Status: Last call for comments

To determine which elements correspond to which slots in a table associated with a table element, to determine the dimensions of the table (x_width and y_height), and to determine if there are any table model errors, user agents must use the following algorithm:

Let x_width be zero.
Let y_height be zero.
Let pending tfoot elements be a list of tfoot elements, initially empty.
Let the table be the table represented by the table element. The x_width and y_height variables give the table's dimensions. The table is initially empty.
If the table element has no children elements, then return the table (which will be empty), and abort these steps.
Associate the first caption element child of the table element with the table. If there are no such children, then it has no associated caption element.
Let the current element be the first element child of the table element.

If a step in this algorithm ever requires the current element to be advanced to the next child of the table when there is no such next child, then the user agent must jump to the step labeled end, near the end of this algorithm.
While the current element is not one of the following elements, advance the current element to the next child of the table:
- colgroup
- thead
- tbody
- tfoot
- tr
If the current element is a colgroup, follow these substeps:
1. Column groups: Process the current element according to the appropriate case below:
  If the current element has any col element children
  Follow these steps:
  1. Let x_start have the value of x_width.
  2. Let the current column be the first col element child of the colgroup element.
  3. Columns: If the current column col element has a span attribute, then parse its value using the rules for parsing non-negative integers.
    
    If the result of parsing the value is not an error or zero, then let span be that value.
    
    Otherwise, if the col element has no span attribute, or if trying to parse the attribute's value resulted in an error, then let span be 1.
  4. Increase x_width by span.
  5. Let the last span columns in the table correspond to the current column col element.
  6. If current column is not the last col element child of the colgroup element, then let the current column be the next col element child of the colgroup element, and return to the step labeled columns.
  7. Let all the last columns in the table from x=x_start to x=x_width-1 form a new column group, anchored at the slot (x_start, 0), with width x_width-x_start, corresponding to the colgroup element.
  If the current element has no col element children
  1. If the colgroup element has a span attribute, then parse its value using the rules for parsing non-negative integers.
    
    If the result of parsing the value is not an error or zero, then let span be that value.
    
    Otherwise, if the colgroup element has no span attribute, or if trying to parse the attribute's value resulted in an error, then let span be 1.
  2. Increase x_width by span.
  3. Let the last span columns in the table form a new column group, anchored at the slot (x_width-span, 0), with width span, corresponding to the colgroup element.
2. Advance the current element to the next child of the table.
3. While the current element is not one of the following elements, advance the current element to the next child of the table:
  - colgroup
  - thead
  - tbody
  - tfoot
  - tr
4. If the current element is a colgroup element, jump to the step labeled column groups above.
Let y_current be zero.
Let the list of downward-growing cells be an empty list.
Rows: While the current element is not one of the following elements, advance the current element to the next child of the table:
- thead
- tbody
- tfoot
- tr
If the current element is a tr, then run the algorithm for processing rows, advance the current element to the next child of the table, and return to the step labeled rows.
Run the algorithm for ending a row group.
If the current element is a tfoot, then add that element to the list of pending tfoot elements, advance the current element to the next child of the table, and return to the step labeled rows.
The current element is either a thead or a tbody.

Run the algorithm for processing row groups.
Advance the current element to the next child of the table.
Return to the step labeled rows.
End: For each tfoot element in the list of pending tfoot elements, in tree order, run the algorithm for processing row groups.
If there exists a row or column in the table the table containing only slots that do not have a cell anchored to them, then this is a table model error.
Return the table.

The algorithm for processing row groups, which is invoked by the set of steps above for processing thead, tbody, and tfoot elements, is:

Let y_start have the value of y_height.
For each tr element that is a child of the element being processed, in tree order, run the algorithm for processing rows.
If y_height > y_start, then let all the last rows in the table from y=y_start to y=y_height-1 form a new row group, anchored at the slot with coordinate (0, y_start), with height y_height-y_start, corresponding to the element being processed.
Run the algorithm for ending a row group.

The algorithm for ending a row group, which is invoked by the set of steps above when starting and ending a block of rows, is:

While y_current is less than y_height, follow these steps:
1. Run the algorithm for growing downward-growing cells.
2. Increase y_current by 1.
Empty the list of downward-growing cells.

The algorithm for processing rows, which is invoked by the set of steps above for processing tr elements, is:

If y_height is equal to y_current, then increase y_height by 1. (y_current is never greater than y_height.)
Let x_current be 0.
Run the algorithm for growing downward-growing cells.
If the tr element being processed has no td or th element children, then increase y_current by 1, abort this set of steps, and return to the algorithm above.
Let current cell be the first td or th element in the tr element being processed.
Cells: While x_current is less than x_width and the slot with coordinate (x_current, y_current) already has a cell assigned to it, increase x_current by 1.
If x_current is equal to x_width, increase x_width by 1. (x_current is never greater than x_width.)
If the current cell has a colspan attribute, then parse that attribute's value, and let colspan be the result.

If parsing that value failed, or returned zero, or if the attribute is absent, then let colspan be 1, instead.
If the current cell has a rowspan attribute, then parse that attribute's value, and let rowspan be the result.

If parsing that value failed or if the attribute is absent, then let rowspan be 1, instead.
If rowspan is zero, then let cell grows downward be true, and set rowspan to 1. Otherwise, let cell grows downward be false.
If x_width < x_current+colspan, then let x_width be x_current+colspan.
If y_height < y_current+rowspan, then let y_height be y_current+rowspan.
Let the slots with coordinates (x, y) such that x_current ≤ x < x_current+colspan and y_current ≤ y < y_current+rowspan be covered by a new cell c, anchored at (x_current, y_current), which has width colspan and height rowspan, corresponding to the current cell element.

If the current cell element is a th element, let this new cell c be a header cell; otherwise, let it be a data cell.

To establish which header cells apply to the current cell element, use the algorithm for assigning header cells described in the next section.

If any of the slots involved already had a cell covering them, then this is a table model error. Those slots now have two cells overlapping.
If cell grows downward is true, then add the tuple {c, x_current, colspan} to the list of downward-growing cells.
Increase x_current by colspan.
If current cell is the last td or th element in the tr element being processed, then increase y_current by 1, abort this set of steps, and return to the algorithm above.
Let current cell be the next td or th element in the tr element being processed.
Return to the step labelled cells.

When the algorithms above require the user agent to run the algorithm for growing downward-growing cells, the user agent must, for each {cell, cell_x, width} tuple in the list of downward-growing cells, if any, extend the cell cell so that it also covers the slots with coordinates (x, y_current), where cell_x ≤ x < cell_x+width.

4.9.12.2 Forming relationships between data cells and header cells

Status: Last call for comments

Each cell can be assigned zero or more header cells. The algorithm for assigning header cells to a cell principal cell is as follows.

Let header list be an empty list of cells.
Let (principal_x, principal_y) be the coordinate of the slot to which the principal cell is anchored.
If the principal cell has a headers attribute specified
1. Take the value of the principal cell's headers attribute and split it on spaces, letting id list be the list of tokens obtained.
2. For each token in the id list, if the first element in the Document with an ID equal to the token is a cell in the same table, and that cell is not the principal cell, then add that cell to header list.
If principal cell does not have a headers attribute specified
1. Let principal_width be the width of the principal cell.
2. Let principal_height be the height of the principal cell.
3. For each value of y from principal_y to principal_y+principal_height-1, run the internal algorithm for scanning and assigning header cells, with the principal cell, the header list, the initial coordinate (principal_x,y), and the increments Δx=−1 and Δy=0.
4. For each value of x from principal_x to principal_x+principal_width-1, run the internal algorithm for scanning and assigning header cells, with the principal cell, the header list, the initial coordinate (x,principal_y), and the increments Δx=0 and Δy=−1.
5. If the principal cell is anchored in a row group, then add all header cells that are row group headers and are anchored in the same row group with an x-coordinate less than or equal to principal_x+principal_width-1 and a y-coordinate less than or equal to principal_y+principal_height-1 to header list.
6. If the principal cell is anchored in a column group, then add all header cells that are column group headers and are anchored in the same column group with an x-coordinate less than or equal to principal_x+principal_width-1 and a y-coordinate less than or equal to principal_y+principal_height-1 to header list.
Remove all the empty cells from the header list.
Remove any duplicates from the header list.
Assign the headers in the header list to the principal cell.

The internal algorithm for scanning and assigning header cells, given a principal cell, a header list, an initial coordinate (initial_x, initial_y), and Δx and Δy increments, is as follows:

Let x equal initial_x.
Let y equal initial_y.
Let opaque headers be an empty list of cells.
If principal cell is a header cell

Let in header block be true, and let headers from current header block be a list of cells containing just the principal cell.

Otherwise

Let in header block be false and let headers from current header block be an empty list of cells.
Loop: Increment x by Δx; increment y by Δy.

For each invocation of this algorithm, one of Δx and Δy will be −1, and the other will be 0.
If either x or y is less than 0, then abort this internal algorithm.
If there is no cell covering slot (x, y), or if there is more than one cell covering slot (x, y), return to the substep marked loop.
Let current cell be the cell covering slot (x, y).
If current cell is a header cell
1. Set in header block to true.
2. Add current cell to headers from current header block.
3. Let blocked be false.
4. If Δx is 0
  
  If there are any cells in the opaque headers list anchored with the same x-coordinate as the current cell, and with the same width as current cell, then let blocked be true.
  
  If the current cell is not a column header, then let blocked be true.
  
  If Δy is 0
  
  If there is are any cells in the opaque headers list anchored with the same y-coordinate as the current cell, and with the same height as current cell, then let blocked be true.
  
  If the current cell is not a row header, then let blocked be true.
5. If blocked is false, then add the current cell to the headers list.
If current cell is a data cell and in header block is true

Set in header block to false. Add all the cells in headers from current header block to the opaque headers list, and empty the headers from current header block list.
Return to the step marked loop.

A header cell anchored at the slot with coordinate (x, y) with width width and height height is said to be a column header if any of the following conditions are true:

The cell's scope attribute is in the column state, or
The cell's scope attribute is in the auto state, and there are no data cells in any of the cells covering slots with y-coordinates y .. y+height-1.

A header cell anchored at the slot with coordinate (x, y) with width width and height height is said to be a row header if any of the following conditions are true:

The cell's scope attribute is in the row state, or
The cell's scope attribute is in the auto state, the cell is not a column header, and there are no data cells in any of the cells covering slots with x-coordinates x .. x+width-1.

A header cell is said to be a column group header if its scope attribute is in the column group state.

A header cell is said to be a row group header if its scope attribute is in the row group state.

A cell is said to be an empty cell if it contains no elements and its text content, if any, consists only of White_Space characters.

4.9.13 Examples

The following shows how might one mark up the bottom part of table 45 of the Smithsonian physical tables, Volume 71:

The following shows how one might mark up the gross margin table on page 46 of Apple, Inc's 10-K filing for fiscal year 2008:

The following shows how one might mark up the operating expenses table from lower on the same page of that document:

Grade.	Yield Point.	Ultimate tensile strength		Per cent elong. 50.8 mm or 2 in.	Per cent reduct. area.
Grade.	Yield Point.	kg/mm²	lb/in²	Per cent elong. 50.8 mm or 2 in.	Per cent reduct. area.
Hard	0.45 ultimate	56.2	80,000	15	20
Medium	0.45 ultimate	49.2	70,000	18	25
Soft	0.45 ultimate	42.2	60,000	22	30

	2008	2007	2006
Net sales	$ 32,479	$ 24,006	$ 19,315
Cost of sales	21,334	15,852	13,717
Gross margin	$ 11,145	$ 8,154	$ 5,598
Gross margin percentage	34.3%	34.0%	29.0%

	2008	2007	2006
Research and development	$ 1,109	$ 782	$ 712
Percentage of net sales	3.4%	3.3%	3.7%
Selling, general, and administrative	$ 3,761	$ 2,963	$ 2,433
Percentage of net sales	11.6%	12.3%	12.6%

4.9.1 The `table` element

Examples:

4.9.2 The `caption` element

4.9.3 The `colgroup` element

4.9.4 The `col` element

4.9.5 The `tbody` element

4.9.6 The `thead` element

4.9.7 The `tfoot` element

4.9.8 The `tr` element

4.9.9 The `td` element

4.9.10 The `th` element

4.9.11 Attributes common to `td` and `th` elements

4.9.12 Processing model

4.9.12.1 Forming a table

4.9.12.2 Forming relationships between data cells and header cells

4.9.13 Examples

4.9.14 Guidance for conformance checkers

4.9.1 The table element

Examples:

4.9.2 The caption element

4.9.3 The colgroup element

4.9.4 The col element

4.9.5 The tbody element

4.9.6 The thead element

4.9.7 The tfoot element

4.9.8 The tr element

4.9.9 The td element

4.9.10 The th element

4.9.11 Attributes common to td and th elements

4.9.12 Processing model

4.9.12.1 Forming a table

4.9.12.2 Forming relationships between data cells and header cells

4.9.13 Examples

4.9.14 Guidance for conformance checkers

4.9.1 The `table` element

4.9.2 The `caption` element

4.9.3 The `colgroup` element

4.9.4 The `col` element

4.9.5 The `tbody` element

4.9.6 The `thead` element

4.9.7 The `tfoot` element

4.9.8 The `tr` element

4.9.9 The `td` element

4.9.10 The `th` element

4.9.11 Attributes common to `td` and `th` elements