Copyright © 2014 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
CSS (Cascading Style Sheets) is a language for specifying the rendering of a structured document (in HTML or XML). See the CSS3 introduction [CSS3INTRO] for more on CSS. The CSS3 table module is one of the modules of level 3 of CSS and defines the properties that specify how tables are to be displayed visually or spoken by a speech synthesizer.
This is a very rough draft. It consists of the text of the CSS2 chapter on tables, with almost no changes yet., except for the addition of the first section, "Tabs & leaders."
This is a public copy of the editors' draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don't cite this document other than as work in progress.
The (archived) public mailing list www-style@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “css3-tables” in the subject, preferably like this: “[css3-tables] …summary of comment…”
This document was produced by the CSS Working Group (part of the Style Activity).
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
The text hasn't yet been synchronized with the latest version of CSS 2.1.
tab’ properties: tabs and
leaders
table-column-span’ and ‘table-row-span’ properties
table-baseline’ property
This CSS3 module depends on the following other CSS3 modules:
tab’ properties: tabs
and leaders[Does it belong here, or in the line box model?]
[This material is new. (Well, actually, it dates from 1996, but it is new in this draft.) Not reviewed yet in any way.]
[The name "tab" maybe reminds people too much of the tab character, which plays no role here at all. Maybe a different name is better. "Anchor"?]
[Could this be merged with the margin-left/margin-right
properties to save some properties? ‘margin-left: 25%
fixed’ instead of ‘tab: 25% left’?]
Håkon will write a proposal for a ‘leader(<string>)’ notation that can be put in the
‘content’ property, inside ‘::after’ and ‘::before’,
independent of any tab properties. It will push everything after it (up to
the end of the block or the explicit next line break, whichever comes
first) forward, so that it ends at the end of a line. Often, that may make
tabs unnecessary. [12 Jan 2005] That proposal is now in [CSS3GCPM].
| Name: | tab-position |
| Value: | <length> | <percentage> |
| Initial: | 0 |
| Applies to: | inline-level elements |
| Inherited: | no |
| Percentages: | width* of containing block |
| Media: | visual |
| Computed value: | <length> |
*) if the containing block is ‘horizontal’, otherwise height
| |
| Name: | tab-align |
| Value: | left | top | center | right | bottom | <string> | none |
| Initial: | none |
| Applies to: | inline-level elements |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
| Name: | tab-leaders |
| Value: | <string> |
| Initial: | "" (empty string) |
| Applies to: | inline-level elements |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
| Name: | tab-leaders-alignment |
| Value: | aligned | centered | distributed |
| Initial: | aligned |
| Applies to: | inline-level elements |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
| Name: | tab |
| Value: | [ <‘tab-position’> || <‘tab-align’> ] [
/ [ <‘tab-leaders’> || <‘tab-leaders-alignment’> ] ]?
|
| Initial: | see individual properties |
| Applies to: | inline-level elements |
| Inherited: | no |
| Percentages: | see individual properties |
| Media: | visual |
| Computed value: | see individual properties |
An inline element can be put at a specific position in the line by
setting the element's ‘tab’ property. The space that creates before
the element can be filled with leaders or left
blank.
Here are some examples:
signature { tab: 100% right } /* right-aligned at end of line */
amount { tab: -1em "." } /* aligned on dot, 1em from end of line */
desc { tab: 0 left } /* left-aligned to start of line */
pageno { tab: 100% right / " . " } /* right-aligned, with dot leaders */
col2 { tab: 50% center / " · " } /* centered in the line */
With a document fragment like the following:
<expenses> <desc>Hotel</desc> <amount>374.55</amount> <desc>Travel</desc> <amount>1460.10</amount> <desc>Miscellaneous, including presents and tips</desc> <amount>84.00</amount> <desc>Total</desc> <amount>1918.65</amount> <signature>Ph. Fogg</signature> </expenses>
The rendering might be as follows:
Possible rendering of a text with tabs and leaders
The ‘tab-position’ and ‘tab-align’
determine the position of the element in the line. The element is
positioned by inserting extra whitespace or leaders before it. Setting a
tab will never cause the element to overlap any other element on the line
(unless it would already overlap without the tab, because of negative
margins). It may be necessary for the UA to insert so much
whitespace/leaders, that the alignment point of the tab occurs on one of
the following lines. (The example above shows one such case.)
The ‘tab-position’ gives the position of a point on
the line to which the element will be aligned. A negative
<length> is measured from the end of the line, a
nonnegative one from the beginning. Ditto for percentages, where
percentages are relative to the width of the containing block
(or height, if the containing block's orientation is
vertical). It depends on the writing mode of the containing block which
edge is the start of the line. [Or is it more intuitive
to always count positive lengths from the left or top and negative ones
from the right or bottom?]
The position is measured from the content edge of the containing block and is independent of any floats that may make the line box narrower than the content box. As usual for inline elements in the presence of floats, the alignment point and the element to which it belongs will be moved to a following line, if it would otherwise overlap the float.
Note that a value of ‘0’ means the
start of the line. Use 100% to refer to the end of the line.
‘Tab-align’ specifies how the element is
aligned to the alignment point:
none’
left’, ‘top’
If the element consists of multiple boxes (because of bidi processing
or line breaks), which of the boxes is aligned depends on the ‘direction’ of the containing block: the
first box in the case of ‘ltr’, the last box in the case of ‘rtl’.
right’, ‘bottom’
direction’ of the containing block is ‘ltr’, the element's
last box is aligned, otherwise the first box.
center’
[Do we need ‘start’ and
‘end’ keywords that dynamically resolve to
‘left’ or ‘right’ depending on the writing direction?
Probably not very useful. Ltr and rtl are not symmetrical: even in rtl
text, numbers are right aligned.]
The ‘tab-leaders’ property determines what is
inserted before the element to make it align. If the value is the empty
string, only whitespace is inserted, otherwise multiple copies of the
string are inserted, as many as needed. If there is not room for a whole
number of copies, the remaining part is filled with whitespace. The style
(color, font, etc.) of the leaders is that of the element's parent (i.e.,
not necessarily the same as the element's own style).
The values of ‘tab-leaders-alignment’ have the following
meaning:
centered’
tab-leaders’ string, half of the extra
whitespace is inserted before the first string, and half after the last
string. (If there is a line break the middle of the leaders, it may not
be possible to have exactly half the space on both sides.)
distributed’
centered’, but the extra whitespace is
inserted in equal amounts before the first, after the last and between
the strings.
aligned’
tab-leaders’ strings are positioned such that
there is room for exactly a whole number of copies between the string and
the left content edge of the containing block. Note that
this has the effect that all ‘aligned’
leaders on different lines are aligned with each other, as if they were
attached to a common grid. The dot leaders in the previous example form
such a grid.
The ‘tab’ property is a shorthand to set all four
properties together. Omitted values default to their initial values.
Note the slash (/) in the value of ‘tab’: if leaders are
specified, they must be separated from the position & alignment with a
slash.
Note that ‘tab: 2em /
"."’ is a valid, and occasionally useful declaration, but
by itself does not cause any leaders to appear, because it implicitly sets
‘tab-align’ to ‘none’.
Justification and line breaking algorithms may change the size of an element, but leave it aligned at the alignment point. (Although different algorithms and different settings of the relevant properties may cause the alignment point to fall on different lines.)
[Do we need keywords such as ‘arrow-leader
(for a stretchy arrow) or ’double-arrow-leader', or can they be
made from existing characters? Or should ‘tab-leaders’ accept up to 3 strings, e.g.,
"\2190" "\2500" "\2192" ("←" "─" "→"), for start, middle and end of
the leaders?]
What happens with tables in vertical text (‘writing-mode: tb-rl’ etc.)? Are tables rotated or not?
Currently, the specification says rows are horizontal and the only
influence is from ‘direction’, which may cause the next column to
be on the left of the current one instead of the right.
Table mark-up in a source document typically represents a particular
relationship between three or more dimensions of data, e.g., dates,
products and the number of units sold. Table properties in CSS are meant
to style the representation of such data as a table. But the properties
can occasionally also be used to align elements in rows and columns for
purely visual reasons, rather than semantics. Unlike, e.g., the table element in HTML, the ‘table’
keyword doesn't imply any particular semantic relation between elements in
the document.
Here is a simple three-row, three-column table described in HTML 4:
<TABLE> <CAPTION>This is a simple 3x3 table</CAPTION> <TR id="row1"> <TH>Header 1 <TD>Cell 1 <TD>Cell 2 <TR id="row2"> <TH>Header 2 <TD>Cell 3 <TD>Cell 4 <TR id="row3"> <TH>Header 3 <TD>Cell 5 <TD>Cell 6 </TABLE>
This code creates one table (the TABLE element), three rows (the TR elements), three header cells (the TH elements), and six data cells (the TD elements). Note that the three columns of this
example are specified implicitly: there are as many columns in the table
as required by header and data cells.
The following CSS rule centers the text horizontally in the header cells and presents the text in the header cells with a bold font weight:
th { text-align: center; font-weight: bold }
The next rules align the text of the header cells on their baseline and vertically center the text in each data cell:
th { vertical-align: baseline }
td { vertical-align: middle }
The next rules specify that the top row will be surrounded by a 3px solid blue border and each of the other rows will be surrounded by a 1px solid black border:
table { border-collapse: collapse }
tr#row1 { border: 3px solid blue }
tr#row2 { border: 1px solid black }
tr#row3 { border: 1px solid black }
Note, however, that the borders around the rows overlap where the rows meet. What color (black or blue) and thickness (1px or 3px) will the border between row1 and row2 be? We discuss this in the section on border conflict resolution.
The following rule puts the table caption above the table:
caption { caption-side: top }
The preceding example shows how CSS works with HTML 4 elements; in HTML
4, the semantics of the various table elements (TABLE, CAPTION, THEAD,
TBODY, TFOOT, COL, COLGROUP, TH, and TD) are well-defined. In other
document languages (such as XML applications), there may not be
pre-defined table elements. Therefore, CSS 2.1 allows authors to "map" document language
elements to table elements via the ‘display’ property.
For example, the following rule makes the FOO element act like an HTML
TABLE element and the BAR element act like a CAPTION element:
FOO { display : table }
BAR { display : table-caption }
We discuss the various table elements in the following section. In this specification, the term table element refers to any element involved in the creation of a table. An “internal” table element is one that produces a row, row group, column, column group, or cell.
The CSS table model is based on the HTML 4.0 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. 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 each row belongs to the first column, the second to the second column, etc.). Rows and columns may be grouped structurally and this grouping reflected in presentation (e.g., a border may be drawn around a group of rows).
Thus, the table model consists of tables, captions, rows, row groups, columns, column groups, and cells.
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. The following ‘display’ values assign
table formatting rules to an arbitrary element:
table-row-group’, but for visual formatting,
the row group is always displayed before all other rows and row groups
and after any top captions. Print user agents may repeat header rows on
each page spanned by a table. If a table contains multiple elements with
‘display: table-header-group’, only the first
is rendered as a header; the others are treated as if they had ‘display: table-row-group’.
table-row-group’, but for visual formatting,
the row group is always displayed after all other rows and row groups and
before any bottom captions. Print user agents may repeat footer rows on
each page spanned by a table. If a table contains multiple elements with
‘display: table-footer-group’, only the first
is rendered as a footer; the others are treated as if they had ‘display: table-row-group’.
display: table-caption’ must be rendered, as described
in section [??].
Replaced elements with these ‘display’ values are treated as their given
display types during layout. For example, an image that is set to ‘display: table-cell’ will fill the available cell
space, and its dimensions might contribute towards the table sizing
algorithms, as with an ordinary cell.
Elements with ‘display’ set to ‘table-column’ or
‘table-column-group’ are not rendered (exactly
as if they had ‘display: none’), but they are
useful, because they may have attributes which induce a certain style for
the columns they represent.
The above, rewritten for ‘display-model’ and ‘display-role’:
The values of ‘display-model’ that apply to tables have
the following meaning. (For the purposes of the definitions in this
section, any child elements with a ‘display-role’ of ‘none’ are considered to
have been removed from the document tree.)
The child elements are laid out as a stack of row-groups. In detail:
Any uninterrupted sequence of child elements, including anonymous
ones, with a role other than ‘table-{row,header,footer}-group’ or ‘table-caption’ is wrapped in an anonymous
element with role and model both set to ‘table-row-group’.
The resulting set of children is laid out as a stack of rows from top
to bottom, with at the top any ‘table-header-group’ child, then the ‘table-row-group’ children, in the order of
the document, and finally any ‘table-footer-group’ child. (Note also the
difference between these three types for paged media, described below.)
The children are laid out as a stack of rows. In detail:
Any uninterrupted sequence of child elements with a role other than
‘table-row’ is wrapped in an anonymous
element with role set to ‘table-row’ and model set to ‘block-inside’.
The resulting children are laid out as a stack of rows from top to bottom in the order of the document.
The children are laid out as a row of table cells. In detail:
Any uninterrupted sequence of children with a role other than ‘table-cell’ is wrapped in an anonymous
element with role set to ‘table-cell’ and model set to ‘block’.
The resulting children are laid out from left to right in the order of the document.
Any children with a role other than ‘table-column’
are ignored. The other children aren't rendered either, but some of
their properties influence the style of the table. See the section Columns below.
All children are ignored (as if their ‘display-role’ was ‘none’) See the
section Columns below for the function of
properties on this element.
See Table width algorithms and Table height algorithms for the size of the various elements.
Where it says “top to bottom” or “left to right” in the
definitions above, this should be replaced by the appropriate direction
based on the value of ‘writing-mode’ of the enclosing ‘table’
element, as follows. (Note that the writing mode of other elements in the
table may influence the direction of the context of the table cells, but
only the writing mode of the table element itself determines the
direction of the rows and columns.)
Note that there are theoretically 8 ways that rows and columns can be ordered, but only the above 4 are supported.
The values of ‘table-role’ have the following meaning
The element is a cell in a table row. If the parent, anonymous or
not, doesn't have the model ‘table-row’, an anonymous element is wrapped
around this element and all its sister elements with the same role that
form an uninterupted sequence. The anonymous element has a role and a
model of ‘table-row’.
The element is the caption of a table. If the parent, anonymous or
not, has a model other than ‘table’, an anonymous element is wrapped
around this element and any sisters with a role of ‘table-{row,header,footer}-group’, ‘table-row’, ‘table-column-group’ or ‘table-column’
that form an uninterrupted sequence. The anonymous element has a role
of ‘block’ and a
model of ‘table’.
If the ‘table’ element that is this element's
parent has another child with role ‘table-caption’ earlier in the document,
this element is treated as if it had a role of ‘block’ instead. [In
CSS 2.1 we said this situation was undefined and authors should not
use it...]
The element is a group of rows. If the parent, anonymous or not, has
a model other than ‘table’, an anonymous element is wrapped
around this element and all its sister elements with a role of table-{row,header,footer}-group' that form an
uninterupted sequence. The anonymous element has a role of ‘block’ and a model of
‘table’.
The element is a group of rows that is displayed at the top of the table, after any top caption. In paged media, if a page break occurs in the table, the header group is repeated at the top of the table after every page break.
If the parent, anonymous or not, has a model other than ‘table’, an anonymous
element is wrapped around this element and all its sister elements with
a role of table-{row,header,footer}-group' that
form an uninterupted sequence. The anonymous element has a role of
‘block’ and a
model of ‘table’.
The element is a group of rows that is displayed at the bottom of the table, before any bottom caption. In paged media, if a page break occurs in the table, the footer group is repeated at the bottom of the table before every page break.
If the parent, anonymous or not, has a model other than ‘table’, an anonymous
element is wrapped around this element and all its sister elements with
a role of table-{row,header,footer}-group' that
form an uninterupted sequence. The anonymous element has a role of
‘block’ and a
model of ‘table’.
The element creates a column. It's contents are ignored.
If the parent, anonymous or not, has neither the model ‘table’ nor ‘table-column-group’, an anonymous element
is wrapped around this element and any sisters with a role of
An idea by Dorothea Salo of Open eBook Forum: some way to scroll a table and keep the headers and footers on screen, plus a a vertical analogue. Such "header columns" would stay on the screen during horizontal scrolling.
The default style sheet for HTML 4.0 in the appendix illustrates the use of these values for HTML 4.0:
table { display: table }
tr { display: table-row }
thead { display: table-header-group }
tbody { display: table-row-group }
tfoot { display: table-footer-group }
col { display: table-column }
colgroup { display: table-column-group }
td, th { display: table-cell }
caption { display: table-caption }
User agents may ignore these ‘display’ property values for HTML table
elements, since HTML tables may be rendered using other algorithms
intended for backwards compatible rendering. However, this is not meant to
discourage the use of ‘display: table’ on
other, non-table elements in HTML.
Remove the above paragraph?
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. Any table element will
automatically generate necessary anonymous table objects around itself,
consisting of at least three nested objects corresponding to a ‘table’/‘inline-table’
element, a ‘table-row’ element, and a ‘table-cell’ element.
Missing elements generate anonymous objects (e.g., anonymous
boxes in visual table layout) according to the following rules:
table-cell’ box T is not a ‘table-row’, a box
corresponding to a ‘table-row’ will be generated between P and T. This
box will span all consecutive ‘table-cell’ sibling boxes of T.
table-row’ box T is not a ‘table’, ‘inline-table’, ‘table-header-group’, ‘table-footer-group’ or ‘table-row-group’
box, a box corresponding to a ‘table’ element will be generated between P and T.
If P is an ‘inline’ box, then the generated
box must be an ‘inline-table’ box instead of a ‘table’ box. This box will span
all consecutive sibling boxes of T that require a ‘table’ parent: ‘table-row’, ‘table-row-group’,
‘table-header-group’, ‘table-footer-group’, ‘table-column’, ‘table-column-group’, and ‘table-caption’. T and
T's siblings may also be anonymous ‘table-row’ boxes generated by rule 1.
table-column’ box T is not a ‘table’, ‘inline-table’, or ‘table-column-group’ box, a box corresponding to a
‘table’ element will be
generated between P and T. If P is an ‘inline’
box, then the generated box must be an ‘inline-table’ box instead of a ‘table’ box. This box will span
all consecutive sibling boxes of T that require a ‘table’ parent: ‘table-row’, ‘table-row-group’,
‘table-header-group’, ‘table-footer-group’, ‘table-column’, ‘table-column-group’, and ‘table-caption’,
including any anonymous ‘table-row’ boxes generated by rule 1.
table-row-group’ (or ‘table-header-group’, ‘table-footer-group’, or ‘table-column-group’ or ‘table-caption’) box T
is not a ‘table’ or ‘inline-table’, a box
corresponding to a ‘table’ element will be generated between P and T.
If P is an ‘inline’ box, then the generated
box must be an ‘inline-table’ box instead of a ‘table’ box. This box will span
all consecutive sibling boxess of T that require a ‘table’ parent: ‘table-row’, ‘table-row-group’,
‘table-header-group’, ‘table-footer-group’, ‘table-column’, ‘table-column-group’, and ‘table-caption’,
including any anonymous ‘table-row’ boxes generated by rule 1.
table’ box (or ‘inline-table’) P is not a ‘table-row-group’,
‘table-header-group’, ‘table-footer-group’, ‘table-caption’, ‘table-column’, ‘table-column-group’ or ‘table-row’ box, a box
corresponding to a ‘table-row’ element will be generated between P and
T. This box spans all consecutive siblings of T that are not ‘table-row-group’,
‘table-header-group’, ‘table-footer-group’, ‘table-caption’, ‘table-column’, ‘table-column-group’ or ‘table-row’ boxes.
table-row-group’ box (or ‘table-header-group’ or ‘table-footer-group’) P is not a ‘table-row’ box, a box
corresponding to a ‘table-row’ element will be generated between P and
T. This box spans all consecutive siblings of T that are not ‘table-row’ boxes.
table-row’ box P is not a ‘table-cell’ box, a box
corresponding to a ‘table-cell’ element will be generated between P
and T. This box spans all consecutive siblings of T that are not ‘table-cell’ boxes.
In this XML example, a ‘table’ element is assumed to contain the HBOX
element:
<HBOX> <VBOX>George</VBOX> <VBOX>4287</VBOX> <VBOX>1998</VBOX> </HBOX>
because the associated style sheet is:
HBOX { display: table-row }
VBOX { display: table-cell }
In this example, three ‘table-cell’ elements are assumed to contain the
text in the ROWs. Note that the text is further encapsulated in anonymous
inline boxes, as explained in [where?]:
<STACK> <ROW>This is the <D>top</D> row.</ROW> <ROW>This is the <D>middle</D> row.</ROW> <ROW>This is the <D>bottom</D> row.</ROW> </STACK>
The style sheet is:
STACK { display: inline-table }
ROW { display: table-row }
D { display: inline; font-weight: bolder }
Table cells may belong to two contexts: rows and columns. However, in the source document cells are descendants of rows, never of columns. Nevertheless, some aspects of cells can be influenced by setting properties on columns.
The following properties apply to column and column-group elements:
border’
border-collapse’ is set to ‘collapse’ on the table element. In that case, borders
set on columns and column groups are input to the conflict resolution algorithm that
selects the border styles at every cell edge.
background’
width’
width’
property gives the minimum width for the column.
visibility’
visibility’ of a column is set to ‘collapse’, none of the cells in the column are
rendered, and cells that span into other columns are clipped. In
addition, the width of the table is diminished by the width the column
would have taken up. See “Dynamic
effects” below. Other values for ‘visibility’ have no effect.
Here are some examples of style rules that set properties on columns. The first two rules together implement the "rules" attribute of HTML 4 with a value of "cols". The third rule makes the "totals" column blue, the final two rules shows how to make a column a fixed size, by using the fixed layout algorithm.
col { border-style: none solid }
table { border-style: hidden }
col.totals { background: blue }
table { table-layout: fixed }
col.totals { width: 5em }
In terms of the visual formatting model ([CSS3BOX]), a table can behave like
a block-level (for ‘display: table’)
or inline-level (for ‘display:
inline-table’) element.
In both cases, the table box generates an anonymous box that contains
the table box itself and any caption boxes (in document order), except
those with ‘caption-side’ set to ‘top-outside’ or ‘bottom-outside’. The caption boxes are block-level
boxes that retain their own content, padding, margin, and border areas,
and are rendered as normal blocks inside the anonymous box. Whether the
caption boxes are placed before or after the table box is decided by the
‘caption-side’
property, as described below.
The anonymous box is a ‘block’ box if the
table is block-level, and an ‘inline-block’ box
if the table is inline-level, except that this block is never considered
as a block for ‘run-in’ interaction, and that
the table box (not the anonymous box) is used when doing baseline vertical
alignment for an ‘inline-table’. The width of the anonymous box is
the border-edge width of the table box inside it, as described by section [??]. Percentages on ‘width’ on the table are
relative to the anonymous box's containing block, not the anonymous box
itself.
The computed values of properties ‘position’, ‘float’, ‘margin-*’,
‘top’, ‘right’, ‘bottom’, and ‘left’ on the table box are used on the anonymous
box instead of the table box. The table box uses the initial values for
those properties.
Diagram of a table with a caption above it; the top margin of the caption is collapsed with the top margin of the table.
| Name: | caption-side |
| Value: | [ top | bottom | left | right | before | after ] && outside? |
| Initial: | top |
| Applies to: | ‘table-caption’ elements
|
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
This property specifies the position of the caption box with respect to the table box. Values have the following meanings:
writing-mode’:
Value of ‘writing-mode’
| Meaning of ‘before’
|
|---|---|
‘horizontal-tb’
| ‘top’
|
‘vertical-rl’
| ‘right’
|
‘vertical-lr’
| ‘left’
|
writing-mode’:
Value of ‘writing-mode’
| Meaning of ‘after’
|
|---|---|
‘horizontal-tb’
| ‘bottom’
|
‘vertical-rl’
| ‘left’
|
‘vertical-lr’
| ‘right’
|
Captions with the extra keyword ‘outside’ are
formatted very much as if they were a block element before or after the
table, except that (1) they inherit inheritable properties from the table,
and (2) they are not considered to be a block box for the purposes of any
‘compact’ or ‘run-in’ element that may precede the table.
Such a caption also behaves like a block box for width and height calculations; the width and height are calculated with respect to the table box's containing block.
For a caption that is on the left or right side of a table box, on the
other hand, a value other than ‘auto’ for ‘width’ sets the width
explicitly, but ‘auto’ tells the user agent to
chose a “reasonable width.” This may vary between “the narrowest
possible box” to “a single line,” so we recommend that users do not
specify ‘auto’ for left and right caption
widths.
To align caption content horizontally within the caption box, use the
‘text-align’
property.
For vertical alignment of a left or right caption box with respect to
the table box, use the ‘vertical-align’ property. The only meaningful
values in this case are ‘top’, ‘middle’, and ‘bottom’. All other values are treated the same as
‘top’.
All left captions are displayed side by side (left margin edge of the first against right margin edge of the next, etc.).
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.
caption { caption-side: bottom;
width: auto;
text-align: left }
The following example shows how to put a caption in the left margin.
The table itself is centered, by setting its left and right margins to
‘auto’, and the whole box with table and
caption is shifted into the left margin by the same amount as the width
of the caption.
body {
margin-left: 8em }
table {
margin-left: auto;
margin-right: auto }
caption {
caption-side: left;
margin-left: -8em;
width: 8em;
text-align: right;
vertical-align: bottom }
Assuming the width of the table is less than the available width, the formatting will be similar to this:
Diagram showing a centered table with the caption
extending into the left margin, as a result of a negative ‘margin-left’ property.
Internal table elements generate rectangular boxes with content and borders. Cells have padding as well. Internal table elements do not have margins.
The visual layout of these boxes is governed by a rectangular, irregular grid of rows and columns. Each box occupies a whole number of grid cells, determined according to the following rules. These rules do not apply to HTML 4 or earlier HTML versions; HTML imposes its own limitations on row and column spans.
direction’
property of the table.
row-span’.) Each cell is thus a rectangular box,
one or more grid cells wide and high. The top row of this rectangle is in
the row specified by the cell's parent. The rectangle must be as far to
the left as possible, but it may not overlap with any other cell box, and
must be to the right of all cells in the same row that are earlier in the
source document. (This constraint holds if the ‘direction’ property
of the table is ‘ltr’; if the ‘direction’ is
‘rtl’, interchange“left” and
“right” in the previous sentence.)
The edges of the rows, columns, row groups and column groups in the collapsing borders model coincide with the
hypothetical grid lines on which the borders of the cells are centered.
(And thus, in this model, the rows together exactly cover the table,
leaving no gaps; ditto for the columns.) In the separated borders model, the edges coincide
with the border edges of cells. (And thus, in
this model, there may be gaps between the rows, columns, row groups or
column groups, corresponding to the ‘border-spacing’ property.)
Note. Positioning and floating of table cells can
cause them not to be table cells anymore, according to the rules in [Relationships between ‘display’, ‘position’, and ‘float’]. When floating is used, the rules on
anonymous table objects may cause an
anonymous cell object to be created as well.
Here are two examples. The first is assumed to occur in an HTML document, the second an XHTML document:
<TABLE> <TR><TD>1 <TD rowspan="2">2 <TD>3 <TD>4 <TR><TD colspan="2">5 </TABLE>
<table> <tr><td>1 </td><td rowspan="2">2 </td><td>3 </td><td>4 </td></tr> <tr><td colspan="2">5 </td></tr> </table>
The second is formatted as in the figure on the right. However, the HTML table's rendering is explicitly undefined by HTML, and CSS doesn't try to define it. User agents are free to render it, e.g., as in the figure on the left.
On the left, one possible rendering of an erroneous HTML 4 table; on the right, the only possible formatting of a similar XHTML table.
For the purposes of finding the background of each table cell, the different table elements 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.
Schema of table layers.
empty-cells’
property is ‘hide’ these “empty”
cells are transparent through the cell, row, row group, column and column
group backgrounds, letting the table background show through.
In the following example, the first row contains four cells, but the second row contains no cells, and thus the table background shines through, except where a cell from the first row spans into this row. The following HTML code and style rules.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HTML>
<HEAD>
<TITLE>Table example</TITLE>
<STYLE type="text/css">
TABLE { background: #ff0; border-collapse: collapse;
empty-cells: hide }
TD { background: red; border: double black }
</STYLE>
</HEAD>
<BODY>
<TABLE>
<TR>
<TD> 1
<TD rowspan="2"> 2
<TD> 3
<TD> 4
</TR>
<TR><TD></TD></TR>
</TABLE>
</BODY>
</HTML>
might be formatted as follows:
Table with three empty cells in the bottom row.
Note that if the table has ‘border-collapse:
separate’, the background of the area given by the ‘border-spacing’
property is always the background of the table element. See the separated borders model.
table-layout’ propertyCSS does not define an “optimal” layout for tables since, in many cases, what is optimal is a matter of taste. CSS does define constraints that user agents must respect when laying out a table. User agents may use any algorithm they wish to do so, and are free to prefer rendering speed over precision, except when the “fixed layout algorithm” is selected.
Note that this section overrides the rules that apply to calculating
widths as described in [CSS3BOX]. In particular, if the
margins of a table are set to ‘0’ and the width
to ‘auto’, the table will not automatically
size to fill its containing block. However, once the calculated value of
‘width’ for the table
is found (using the algorithms given below or, when appropriate, some
other UA dependent algorithm) then the other parts of the algorithm do
apply. Therefore a table can be centered using left and right
‘auto’ margins, for instance.
Future updates of CSS may introduce ways of making tables automatically fit their containing blocks.
| Name: | table-layout |
| Value: | auto | fixed |
| Initial: | auto |
| Applies to: | ‘table’ and
‘inline-table’ elements
|
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
The ‘table-layout’ property controls the algorithm
used to lay out the table cells, rows, and columns. Values have the
following meaning:
The two algorithms are described below.
With this (fast) algorithm, the horizontal layout of the table does not depend on the contents of the cells; it only depends on the table's width, the width of the columns, and borders or cell spacing.
The table's width may be specified explicitly with the ‘width’ property. A value
of ‘auto’ (for both ‘display:
table’ and ‘display: inline-table’)
means use the automatic table layout
algorithm. However, if the table is a block-level table (‘display: table’) in normal flow, a UA may (but does not
have to) use the algorithm of 10.3.3 [Re-link this
to the Box Model] to compute a width and apply fixed table layout even if
the specified width is ‘auto’.
If a UA supports fixed table layout when ‘width’ is ‘auto’, the following will create a table that is
4em narrower than its containing block:
table { table-layout: fixed;
margin-left: 2em;
margin-right: 2em }
In the fixed table layout algorithm, the width of each column is determined as follows:
auto’ for the ‘width’ property sets the width for that
column.
auto’ for the ‘width’ property determines the width for that
column. If the cell spans more than one column, the width is divided over
the columns.
The width of the table is then the greater of the value of the ‘width’ property for the
table element and the sum of the column widths (plus cell spacing or
borders). If the table is wider than the columns, the extra space should
be distributed over the columns.
If a subsequent row has more columns than the first, then additional
columns must not be rendered. When using ‘table-layout:
fixed’, authors should not omit columns from the first row.
In this manner, the user agent can begin to lay out the table once the
entire first row has been received. Cells in subsequent rows do not affect
column widths. Any cell that has content that overflows uses the ‘overflow’ property to
determine whether to clip the overflow content.
In this algorithm (which generally requires no more than two passes),
the table's width is given by the width of its columns (and intervening borders). This algorithm reflects the behavior of
several popular HTML user agents at the writing of this specification. UAs
are not required to implement this algorithm to determine the table layout
in the case that ‘table-layout’ is
‘auto’; they can use any other algorithm
even if it results in different behavior.
Input to the automatic table layout must only include the width of the containing block and the content of, and any CSS properties set on, the table and any of its descendants.
This should be defined in more detail.
The remainder of this section is non-normative.
This algorithm may be inefficient since it requires the user agent to have access to all the content in the table before determining the final layout and may demand more than one pass.
Column widths are determined as follows:
Calculate the minimum content width (MCW) of each cell: the formatted
content may span any number of lines but may not overflow the cell box.
If the specified ‘width’ (W) of the cell is greater than MCW,
W is the minimum cell width. A value of ‘auto’ means that MCW is the minimum cell width.
Also, calculate the "maximum" cell width of each cell: formatting the content without breaking lines other than where explicit line breaks occur.
For each column, determine a maximum and minimum column width from the
cells that span only that column. The minimum is that required by the
cell with the largest minimum cell width (or the column ‘width’, whichever is
larger). The maximum is that required by the cell with the largest
maximum cell width (or the column ‘width’, whichever is larger).
For each cell that spans more than one column, increase the minimum widths of the columns it spans so that together, they are at least as wide as the cell. Do the same for the maximum widths. If possible, widen all spanned columns by approximately the same amount.
For each column group element with a ‘width’ other than ‘auto’, increase the minimum widths of the columns it
spans, so that together they are at least as wide as the column group's
‘width’.
This gives a maximum and minimum width for each column. Column widths influence the final table width as follows:
table’ or
‘inline-table’ element's ‘width’ property has a
computed value (W) other than ‘auto’, the
property's value as used for layout is the greater of W and the minimum
width required by all the columns plus cell spacing or borders (MIN). If
W is greater than MIN, the extra width should be distributed over the
columns.
table’ or
‘inline-table’
element has ‘width: auto’, the table width
used for layout is the greater of the table's containing block width and
MIN. However, if the maximum width required by the columns plus cell
spacing or borders (MAX) is less than that of the containing block, use
MAX.
A percentage value for a column width is relative to the table width. If
the table has ‘width: auto’, a percentage
represents a constraint on the column's width, which a UA should try to
satisfy. (Obviously, this is not always possible: if the column's width is
‘110%’, the constraint cannot be satisfied.)
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 may indirectly influence the height of a row, and vice versa.
The height of a table is given by the ‘height’ property for the ‘table’ or ‘inline-table’
element. A value of ‘auto’ means that the
height is the sum of the row heights plus any cell spacing or borders. Any
other value specifies the height explicitly; the table may thus be taller
or shorter than the height of its rows. The ‘height’ property on ‘table’ boxes is treated as a minimum height. CSS3
does not define how extra space is distributed when the ‘height’ property causes
the table to be taller than it otherwise would be. Specify this?
The height of a ‘table-row’ element's box is calculated once the
user agent has all the cells in the row available: it is the maximum of
the row's specified ‘height’ and the minimum height (MIN) required
by the cells. A ‘height’ value of ‘auto’ for a ‘table-row’ means the row height used for layout is
MIN. MIN depends on cell box heights and cell box alignment (much like the
calculation of a line box height). Percentage heights on table
cells, table rows, and table row groups compute to ‘auto’.
In CSS3, the height of a cell box is the maximum of the table cell's
‘height’ property
and the minimum height required by the content (MIN). A value of ‘auto’ for ‘height’ implies that the value MIN will be
used for layout. CSS3 does not define what percentage values of ‘height’ refer to when
specified for table cells.
CSS3 does not specify how cells that span more than one row affect row height calculations except that the sum of the row heights involved must be great enough to encompass the cell spanning the rows.
The ‘vertical-align’ property of each table cell
determines its alignment within the row. Each cell's content has a
baseline, a top, a middle, and a bottom, as does the row itself. In the
context of tables, values for ‘vertical-align’ have the following meanings:
The baseline of a cell is 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. 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. Note
that the baseline of a cell may end up below its bottom border, see the example below.
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. Here is an example:
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.
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.
To avoid ambiguous situations, the alignment of cells proceeds in the following order:
vertical-align: top’ are positioned.
Cell boxes that are smaller than the height of the row receive extra top or bottom padding.
The cell in this example has a baseline below its bottom border:
div { height: 0; overflow: hidden; }
<table>
<tr>
<td>
<div> Test </div>
</td>
</tr>
</table>
The horizontal alignment of a cell's content within a cell box is
specified with the ‘text-align’ property.
When the ‘text-align’ property for more than one cell in
a column is set to a <string> value, the content of those cells is
aligned along a vertical axis. The beginning of the string touches this
axis. Character directionality determines whether the string lies to the
left or right of the axis.
Aligning text in this way is only useful if the text fits on one line. The result is undefined if the cell content spans more than one line.
If value of ‘text-align’ for a table cell is a string but
the string doesn't occur in the cell content, the end of the cell's
content touches the vertical axis of alignment.
Note that the strings do not have to be the same for each cell, although they usually are.
CSS does not provide a way specify the offset of the vertical alignment axis with respect to the edge of a column box.
The following style sheet:
TD { text-align: "." }
TD:before { content: "$" }
will cause the column of dollar figures in the following HTML table:
<TABLE> <COL width="40"> <TR> <TH>Long distance calls <TR> <TD> 1.30 <TR> <TD> 2.50 <TR> <TD> 10.80 <TR> <TD> 111.01 <TR> <TD> 85. <TR> <TD> 90 <TR> <TD> .05 <TR> <TD> .06 </TABLE>
to align along the decimal point. For fun, we have used the :before pseudo-element to insert a dollar sign before each figure. The table might be rendered as follows:
Long distance calls
$1.30
$2.50
$10.80
$111.01
$85.
$90
$.05
$.06
The ‘visibility’ property takes the value ‘collapse’ for row, row group, column, and column group
elements. This value causes the entire row or column to be removed from
the display, and the space normally taken up by the row or column to be
made available for other content. Contents of spanned rows and columns
that intersect the collapsed column or row are clipped. The suppression of
the row or column, however, does not otherwise affect the layout of the
table. This allows dynamic effects to remove table rows or columns without
forcing a re-layout of the table in order to account for the potential
change in column constraints.
There are two distinct models for setting borders on table cells in CSS. One is most suitable for so-called separated borders around individual cells, the other is suitable for borders that are continuous from one end of the table to the other. Many border styles can be achieved with either model, so it is often a matter of taste which one is used.
| Name: | border-collapse |
| Value: | collapse | separate |
| Initial: | collapse |
| Applies to: | ‘table’ and
‘inline-table’ elements
|
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
This property selects a table's border model. The value ‘separate’ selects the separated borders border
model. The value ‘collapse’ selects the
collapsing borders model. The models are described below.
| Name: | border-spacing |
| Value: | <length> <length>? |
| Initial: | 0 |
| Applies to: | ‘table’ and
‘inline-table’ elements*
|
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
*) Note: user agents may also apply the border-spacing'
property to frameset elements. Which elements are frameset elements is not
defined by this specification and is up to the document language. For
example, HTML4 defines a <FRAMESET> element, and XHTML 1.0 defines a
<frameset> element. The ‘border-spacing’ property on a frameset element
can be thus used as a valid substitute for the nonstandard framespacing
attribute.
[During the 20 Aug 2001 ftf, we decided to add a property to let the designer choose what background is drawn in border-spacing: the table's background (as in CSS2), half of the cells' background on either side, half of the rows' background on either side, some completely different background...]
The lengths specify the distance that separates adjoining cell borders. 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. Lengths may not be negative.
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. For example, on the right hand side, the distance is padding-right + horizontal border-spacing.
The width of the table is the distance from the left inner padding edge to the right inner padding edge (including the border spacing but excluding padding and border).
However, in HTML and XHTML1, the width of the <table> element is the distance from the left border edge to the right border edge.
Remove the previous paragraph and instead add ‘box-sizing’ to the sample style for HTML.
In this model, each cell has an individual border. The ‘border-spacing’
property specifies the distance between the borders of adjoining cells. In
this space, the row, column, row group, and column group backgrounds are
invisible, allowing the table background to show through. Rows, columns,
row groups, and column groups cannot have borders (i.e., user agents must
ignore the border properties for those elements).
The table in the figure below could be the result of a style sheet like this:
table { border: outset 10pt;
border-collapse: separate;
border-spacing: 15pt }
td { border: inset 5pt }
td.special { border: inset 10pt } /* The top-left cell */
A table with ‘border-spacing’ set to a length value. Note
that each cell has its own border, and the table has a separate border
as well.
empty-cells’ property| Name: | empty-cells |
| Value: | show | hide |
| Initial: | show |
| Applies to: | ‘table-cell’ elements
|
| Inherited: | yes |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | as specified |
In the separated borders model, this property controls the rendering of
borders and backgrounds around cells that have no visible content. Empty
cells and cells with the ‘visibility’ property set to ‘hidden’ are considered to
have no visible content. Cells are empty unless they contain one or more
of the following:
white-space’ property handling.
When this property has the value ‘show’,
borders and backgrounds are drawn around/behind empty cells (like normal
cells).
A value of ‘hide’ means that no borders
or backgrounds are drawn around/behind empty cells (see point 6 in “Table layers and transparency”).
Furthermore, if all the cells in a row have a value of ‘hide’ and have no visible content, the entire row
behaves as if it had ‘display: none’.
The following rule causes borders and backgrounds to be drawn around all cells:
table { empty-cells: show }
In the collapsing border model, it is possible to specify borders that surround all or part of a cell, row, row group, column, and column group. Borders for HTML's "rule" attribute can be specified this way.
Borders are centered on the grid lines between the cells. User agents must find a consistent rule for rounding off in the case of an odd number of discrete units (screen pixels, printer dots).
The diagram below shows how the width of the table, the widths of the borders, the padding, and the cell width interact. Their relation is given by the following equation, which holds for every row of the table:
row-width = (0.5 * border-width0) + padding-left1 + width1 + padding-right1 + border-width1 + padding-left2 +...+ padding-rightn + (0.5 * border-widthn)
Here n is the number of cells in the row, padding-lefti and padding-righti refer to the left (resp., right) padding of cell i, and border-widthi refers to the border between cells i and i + 1.
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.
The top border width of the table is computed by examining all cells who collapse their top borders with the top border of the table. The top border width of the table is equal to half of the maximum collapsed top border. The bottom border width is computed by examining all cells whose bottom borders collapse with the bottom of the table. The bottom border width is equal to half of the maximum collapsed bottom border.
Any borders that spill into the margin are taken into account when
determining if the table overflows some ancestor (see ‘overflow’).
Schema showing the widths of cells and borders and the padding of cells.
Note that in this model, the width of the table includes half the table border. Also, in this model, a table doesn't have padding (but does have margins).
CSS3 does not define where the edge of a background on a table element lies.
In the collapsing border model, borders at every edge of every cell may
be specified by border properties on a variety of elements that meet at
that edge (cells, rows, row groups, columns, column groups, and the table
itself), and these borders may vary in width, style, and color. The rule
of thumb is that at each edge the most "eye catching" border style is
chosen, except that any occurrence of the style ‘hidden’ unconditionally turns the border off.
The following rules determine which border style “wins”in case of a conflict:
border-style’ of ‘hidden’ take precedence over all other conflicting
borders. Any border with this value suppresses all borders at this
location.
none’ have the lowest priority. Only if the border
properties of all the elements meeting at this edge are ‘none’ will the border be
omitted (but note that ‘none’ is the default value for the border style.)
hidden’ and at least one of them is not ‘none’, then narrow borders are
discarded in favor of wider ones. If several have the same ‘border-width’ then
styles are preferred in this order: ‘double’, ‘solid’, ‘dashed’, ‘dotted’, ‘ridge’, ‘outset’, ‘groove’, and the lowest: ‘inset’.
direction’ is ‘ltr’; right, if it is ‘rtl’) and further to the top wins.
The following example illustrates the application of these precedence rules. This style sheet:
table { border-collapse: collapse;
border: 5px solid yellow; }
*#col1 { border: 3px solid black; }
td { border: 1px solid red; padding: 1em; }
td.cell5 { border: 5px dashed blue; }
td.cell6 { border: 5px solid green; }
with this HTML source:
<TABLE>
<COL id="col1"><COL id="col2"><COL id="col3">
<TR id="row1">
<TD> 1
<TD> 2
<TD> 3
</TR>
<TR id="row2">
<TD> 4
<TD class="cell5"> 5
<TD class="cell6"> 6
</TR>
<TR id="row3">
<TD> 7
<TD> 8
<TD> 9
</TR>
<TR id="row4">
<TD> 10
<TD> 11
<TD> 12
</TR>
<TR id="row5">
<TD> 13
<TD> 14
<TD> 15
</TR>
</TABLE>
would produce something like this:
An example of a table with collapsed borders.
Here is an example of hidden collapsing borders:
Table with two omitted internal borders.
HTML source:
<TABLE style="border-collapse: collapse; border: solid;">
<TR><TD style="border-right: hidden; border-bottom: hidden">foo</TD>
<TD style="border: solid">bar</TD></TR>
<TR><TD style="border: none">foo</TD>
<TD style="border: solid">bar</TD></TR>
</TABLE>
Backgrounds of cells, rows, columns, etc., are drawn inside the grid lines that enclose that cell, row, etc. I.e., if there is a border, the background starts in the middle of the border. The adjoining cell draws the background of the other half of the border.
The exception are the outer edges of the table. Here the background doesn't start in the middle of the border, but starts a little further outside. How far outside is determined by the border-width property of the table element: the background starts half the value of border-width outside the grid.
Note that this means that, if the cells, rows, etc., don't specify any borders that collapse with the table's border, the background will be drawn under the whole border, from border edge to border edge, exactly as for non-table elements.
Here is a table with three rows and a yellow background. The table element has a 0.5em border, but the first cell has a 1em border, which will therefore not be fully covered by the table's background:
<table style="background: yellow; border: 0.5em dotted">
<tr>
<td style="border: 1em dotted">... </td>
</tr>
<tr>
<td>... </td>
</tr>
<tr>
<td>... </td>
</tr>
</table>
The background extends to the width given by the border-width property of the table element. The border-width of the first row is larger and thus the border extends outside the background.
Some of the values of the ‘border-style’ have different meanings in
tables than for other elements. In the list below they are marked with an
asterisk.
none’,
but in the collapsing border model,
also inhibits any other border (see the section on border conflicts).
border-width’.
groove’: the border looks as though it were coming
out of the canvas.
ridge’.
groove’.
table-column-span’ and ‘table-row-span’
properties| Name: | table-column-span, table-row-span |
| Value: | auto | attr(...) |
| Initial: | auto |
| Applies to: | table cells |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
The properties ‘table-column-span’ and ‘table-row-span’
specify which attributes in the source document contain the number of
columns, resp. rows that the element spans. See “visual layout of table contents.” It only affects
elements that are rendered as table cells (‘display: table-cell’).
A value of ‘attr(X)’ means that
the attribute X of the current element must be parsed as a
number. If there is no attribute X or it does not contain a
number, the effect is as if the number were a "1".
The UA must ignore leading and trailing whitespace in the attribute X and accept only (or at least?) decimal integers. Numbers less than 1 are interpreted as "1". [Specify what we mean by "decimal integer"? Leading zeros? Ignore trailing garbage, as in "2rows" -> "2"? Special rules for "0" or "*" to span as many rows/columns as possible?]
A value of ‘auto’ means that the UA should
apply its built-in knowledge of the document format to determine the
number of rows/columns to span, or assume "1" if it has no such knowledge.
[Relaxed conformance requirements for HTML?]
The following rules might be found in a UA style sheet for HTML or XHTML:
td, th {
table-column-span: attr(colspan);
table-row-span: attr(rowspan) }
The specified value is the computed value, i.e., ‘attr(X)’ is not replaced by the
value of X.
In this proposal, ‘col-span’
and ‘row-span’ do not accept explicit
numbers (<integer>), on the grounds that a table in the
source is (at least in the ideal case) a structural element and the spans
in it make structural sense. Therefore the spans can be used by CSS, but
not changed. On the other hand, if you use CSS to display something as a
table for visual purposes (e.g., to display a DL element as a 2-column
table), it makes sense to allow certain elements to span columns or rows
(e.g., a title across the top of the DL list).
table-baseline’ propertyThis property was decided during the CSS meeting of 9–11 October 2006 in Mountain View on the request of George Chavchanidze. It can help align matrices and other table-like constructs in mathematics to the surrounding text.
| Name: | table-baseline |
| Value: | <integer> |
| Initial: | 1 |
| Applies to: | tables and inline-tables |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | specified value |
The property sets the baselines of the table for use by ‘vertical-align’:
If the value is N, the baselines of the table are the baselines of
the Nth row. If N is less than 1, use the
first row; if N is greater than the number of rows, use the
last row.
However, if ‘vertical-align’ is ‘top’ or ‘bottom’, the alignment is with respect to the top
or bottom border edge of the table, not the row.
Note that both inline (‘inline-table’) and displayed (‘table’) tables have a baseline.
The latter is used, e.g., when a table is nested in another table's cell
and has to be aligned to other cells in the same row.
The following example shows a 3×3 table that is aligned on the baseline of the middle row:
<p
Move this section to Speech module?
When a table is spoken by a speech generator, the relation between the data cells and the header cells must be expressed in a different way than by horizontal and vertical alignment. Some speech browsers may allow a user to move around in the 2-dimensional space, thus giving them the opportunity to map out the spatially represented relations. When that is not possible, the style sheet must specify at which points the headers are spoken.
speak-header’
property| Name: | speak-header |
| Value: | once | always |
| Initial: | once |
| Applies to: | elements that have table header information |
| Inherited: | yes |
| Percentages: | N/A |
| Media: | aural |
| Computed value: | specified value |
This property specifies whether table headers are spoken before every cell, or only before a cell when that cell is associated with a different header than the previous cell. Values have the following meanings:
Each document language may have different mechanisms that allow authors to specify headers. For example, in HTML 4 ([HTML40]), it is possible to specify header information with three different attributes ("headers", "scope", and "axis"), and the specification gives an algorithm for determining header information when these attributes have not been specified.
Image of a table with header cells ("San Jose" and "Seattle") that are not in the same column or row as the data they apply to.
This HTML example presents the money spent on meals, hotels and transport in two locations (San Jose and Seattle) for successive days. Conceptually, you can think of the table in terms of an n-dimensional space. The headers of this space are: location, day, category and sub-total. Some cells define marks along an axis while others give money spent at points within this space. The mark-up for this table is:
<TABLE> <CAPTION>Travel Expense Report</CAPTION> <TR> <TH></TH> <TH>Meals</TH> <TH>Hotels</TH> <TH>Transport</TH> <TH>sub-total</TH> </TR> <TR> <TH id="san-jose" axis="san-jose">San Jose</TH> </TR> <TR> <TH headers="san-jose">25-Aug-97</TH> <TD>37.74</TD> <TD>112.00</TD> <TD>45.00</TD> <TD></TD> </TR> <TR> <TH headers="san-jose">26-Aug-97</TH> <TD>27.28</TD> <TD>112.00</TD> <TD>45.00</TD> <TD></TD> </TR> <TR> <TH headers="san-jose">sub-total</TH> <TD>65.02</TD> <TD>224.00</TD> <TD>90.00</TD> <TD>379.02</TD> </TR> <TR> <TH id="seattle" axis="seattle">Seattle</TH> </TR> <TR> <TH headers="seattle">27-Aug-97</TH> <TD>96.25</TD> <TD>109.00</TD> <TD>36.00</TD> <TD></TD> </TR> <TR> <TH headers="seattle">28-Aug-97</TH> <TD>35.00</TD> <TD>109.00</TD> <TD>36.00</TD> <TD></TD> </TR> <TR> <TH headers="seattle">sub-total</TH> <TD>131.25</TD> <TD>218.00</TD> <TD>72.00</TD> <TD>421.25</TD> </TR> <TR> <TH>Totals</TH> <TD>196.27</TD> <TD>442.00</TD> <TD>162.00</TD> <TD>800.27</TD> </TR> </TABLE>
By providing the data model in this way, authors make it possible for speech enabled-browsers to explore the table in rich ways, e.g., each cell could be spoken as a list, repeating the applicable headers before each data cell:
San Jose, 25-Aug-97, Meals: 37.74 San Jose, 25-Aug-97, Hotels: 112.00 San Jose, 25-Aug-97, Transport: 45.00 ...
The browser could also speak the headers only when they change:
San Jose, 25-Aug-97, Meals: 37.74
Hotels: 112.00
Transport: 45.00
26-Aug-97, Meals: 27.28
Hotels: 112.00
...
[acknowledgments]
background’, ??
border’, ??
border-style’, ??
border-width’, ??
direction’, ??
display, ??
overflow’, ??
text-align’, ??
vertical-align’, ??
visibility’, ??
width’, ??
| Property | Values | Initial | Applies to | Inh. | Percentages | Media |
|---|---|---|---|---|---|---|
| border-collapse | collapse | separate | collapse | ‘table’ and ‘inline-table’ elements | yes | N/A | visual |
| border-spacing | <length> <length>? | 0 | ‘table’ and ‘inline-table’ elements* | yes | N/A | visual |
| caption-side | [ top | bottom | left | right | before | after ] && outside? | top | ‘table-caption’ elements | yes | N/A | visual |
| empty-cells | show | hide | show | ‘table-cell’ elements | yes | N/A | visual |
| speak-header | once | always | once | elements that have table header information | yes | N/A | aural |
| tab | [ <‘tab-position’> || <‘tab-align’> ] [ / [ <‘tab-leaders’> || <‘tab-leaders-alignment’> ] ]? | see individual properties | inline-level elements | no | see individual properties | visual |
| tab-align | left | top | center | right | bottom | <string> | none | none | inline-level elements | no | N/A | visual |
| tab-leaders | <string> | "" (empty string) | inline-level elements | no | N/A | visual |
| tab-leaders-alignment | aligned | centered | distributed | aligned | inline-level elements | no | N/A | visual |
| table-baseline | <integer> | 1 | tables and inline-tables | no | N/A | visual |
| table-column-span | auto | attr(...) | auto | table cells | no | N/A | visual |
| table-layout | auto | fixed | auto | ‘table’ and ‘inline-table’ elements | no | N/A | visual |
| table-row-span | auto | attr(...) | auto | table cells | no | N/A | visual |
| tab-position | <length> | <percentage> | 0 | inline-level elements | no | width* of containing block | visual |
The following properties are defined in other modules: [Update when border and background are merged.]
background’
[CSS3BG]
border’, ‘border-style’,
‘border-width’
[CSS3BORDER]
direction’,
‘text-align’ [CSS3TEXT]
display, ’height', ‘overflow’, ‘width’ [CSS3BOX]
vertical-align’ [CSS3LINE]
visibility’
[?]