More advice for the full screen mode.
I list below all topic groups, which I have done according to subjects, which they handle. You can return to this topic group by using this menu and the link Table of topic groups on the top of the each page.
To the normal page

10. How to set CSS for table elements


I have divided this page into sections, which handle following topics:

The content as a one big page


Tables have been used creating basic structures of Web-pages, which they are not originally intended. CSS works better, if the basic structure is base not on tables. It is much easier to crate basic structure using frames, which works well with relative old browsers (for example Netscape 2.x and MS IE 3.02).

Floating elements or tables?

If you want to create frame free pages and you keep the percentage of old browsers is relative small, there is an alternative solution. It is easier to create the basic structure using the common block element DIV, which presentation is defined with CSS. I handle them in the page 11. What is the visual formatting model of CSS2[S][Pw]. Applying CSS for tables browsers have some generic problems.

Browser-specific notes:

  1. In order to format the text inside tables is problematic, because horizontal alignment using CSS-properties cause also with certain browsers the horizontal alignment of the whole table. For example the CSS-property text-align:justify affect in MS IE 4.0 for Windows incorrect to the place of the table. Table {text-align:justify;} and table {text-align:left;} move the table to the left even if it has set into center using element CENTER or corresponding attribute inside the element TABLE. If you define text-align to child-elements (for example table.right td {text-align:right}), the behavior is ok.

  2. Netscape 4.x can't inherit CSS text-related properties definitions onto tables. Even MS IE 5.x and at least some versions of Opera 5.x have partially the same problem. It is easy to solve this problem with IE and Netscape 4.x by defining element TD. Because Opera 3.6x doesn't support properties to element TD, there is a need to define the element TABLE, when properties are different compared to the element BODY.

  1. To solve easy way these problems, I recommend to work to this way:

    body, table,th, td, p, ol, ul, blockquote /* define here common text-style properties and you can avoid all inheritance problems with Netscape 4.x and MS IE 4.0/5.0; There might be also other elements, which you must add into this list, because I don't have used all possible elements in my documents */
    {font-size: small;
    font-family: Verdana, Arial, Helvetica; }

    body {background: #dcd2d3 url(background_image.gif);}/* these properties concerns only the element body */
    text-align:justify; /* Opera inherit this property to tables; Define another time some descendant elements, if you need different properties */

HTML 4.01 table elements

It is possible to apply all properties, which I have explained in previous pages like borders, background, text types (look at an example[S][Pw]). In principle for all HTML 4.0 table elements (TABLE, CAPTION, THEAD, TBODY, TFOOT, COL, COLGROUP, TH, TR and TD). I recommend however to define CSS only for TABLE, TH and TD elements because all browsers support only partially the HTML 4.0 table model.

Indeed you can use more layered background properties if you define more table element ([M][S][Pw] - there is small examples in in the bottom left of the next model).

W3C: CSS2: 17 Tables, 17.5.1 Table layers and transparency[Pw].

Most of the properties work in the element CAPTION. CSS2 offers to change the place of the caption with the caption-side property ([M][S][Pw]).

In tables cells are descendants of rows, never of columns. Nevertheless, some aspects of cells can be influenced by setting properties on columns by using so-called column What are selectors, classes and id-attributes. They are related to the element COL just after the element TABLE. Below is an example of usage of them ([M][S][Pw] - the model on the bottom right concerns column selectors):

*#col1 { border: 3px solid black;}
*#col2 { border: 3px solid red;}
*#col3 { border: 3px solid olive;}...
<COL id="col1"><COL id="col2"><COL id="col3">...

There is also row What are selectors, classes and id-attributes. These can have also the first-child pseudo-class. Here is an example, which should give background and border properties for table rows ([M][S][Pw]):

tr:first-child {background-color: white; border-top: solid black 3px;}
tr {background-color: aqua; color:black; border:yellow 3px solid;}
*#row1 {border: 3px green solid; background-color:aqua;}
*#row2 {border: 3px solid green; background-color:white;}
*#row3 {border: 3px solid blue; background-color:lime;}
*#row4 {border: 3px solid blue; background-color:yellow;}
*#row5 {border: 3px solid blue; background-color:green;}

Browser-specific notes:

  1. Opera 3.x and Netscape 4.x support limited basic table elements (TABLE, TH and TD). For example CSS-borders don't work with these browsers.

  2. The element CAPTION works according to the HTML 4.0 specification only in Opera and Netscape browsers. MS IE handles it as if a special table cell. Different implementation makes the usage of this element problematic.

  3. the change of the place of the CAPTION element with CSS works only in Opera 4.x+ and Mozilla Gecko browsers ([M][S][Pw]). If the TFOOT element has been used Opera 4.x-6.x don't work correctly and implementations are messy (fixed in Opera 7.x).

  1. Supporting of COL seems to be quite limited. The model page ([M][S][Pw]), where on the bottom right concerns column selectors works correctly in Opera 4.x+ and Mozilla Gecko browsers but not in the MS IE versions, which I have tested.

  2. Opera didn't support in my tests padding for the COL element, but MS IE supported.

  3. The element COLGROUP has the most limited support. In my tests MS IE 5.x+ can center the text in a model document ([M][S][Pw]) and Mozilla 1.1 support border properties for it.

  4. Opera 4.x+ renders border colors of Model25a.html[S][Pw] as they have been defined. MS IE renders only background colors correctly except in the first row.

  5. Only Mozilla Gecko and Opera 7.x+ browsers render the :first-child pseudo-class in the previous model page.


Border models and empty cells

CSS2 offer two models, how to render table cell borders, which are inherited to sub parts of table elements. Here are two examples ([M][S][Pw]):

table {border-collapse: separate; border-spacing: 15pt} /* borders can't collapse each others; border-spacing (correspond the HTML-attribute cellspacing) */
table {border-collapse: collapse;} /* borders can collapse each others; CSS2 have priority rules in conflict situations */
W3C: CSS2: 17 Tables, 17.6 Borders[Pw].

In the separated borders model (border-collapse:separate) it is also possible to control the behavior of empty cells by using the property empty-cells (possible special values are show (according to CSS2 this should be the initial value) and hide). If to the element TABLE is used table-collapse:separate, border properties to the element TR should be ignored. The separate table model works only with elements TABLE and TD.

The element TR and some other elements work only with table-collapse:collapse. The initial value in browsers, which support border models should be according to the CSS2 specification border-collapse:collapse.

Browser-specific notes:

  1. The separate borders model works at least in Opera 4.x+ and Mozilla Gecko browsers. Opera hides as default empty cells. Mozilla Gecko browsers are in this matter DTD-dependent[S].

  2. MS IE 5.x+ doesn't support border-spacing and empty-cells properties. In MS IE border-collapse:separate works only as opposite to the border-collapse:collapse but the whole separate borders model is not supported. Border spacing values must define in MS IE by using the cellspacing HTML-attribute.

  3. The collapsing borders model works at least in MS IE 5.x+, Opera 4.x+ and according to an e-mail Mozilla 0.9.9+ browsers. Netscape 7.0 is the first Netscape browsers, which support this border rendering model. New Mozilla Gecko browsers don't render all defined borders at least in situations, where for all sides of table cells have not defined borders. Also MS IE and Opera have these problems. Opera 4.x-6.x has also as a problem that it can't center cell borders ([M][S][Pw]). MS IE and Opera 7.x+ give the nicest result in complex situations.

  4. Mozilla Gecko browsers define the default value as border-collapse:separate; border-spacing:2px. It is the same default value, which is commonly used in all browsers, when CSS is not used. It corresponds the default value cellspacing="2". Any browser doesn't use as the initial value border-collapse:collapse because browsers, which don't understand CSS2 table border models behave like tables, which have border-collapse:separate.

  1. Opera 3.x and Netscape 4.x don't support CSS-borders for tables.

  2. Border models don't work in MS IE 4.0 for Windows but it accepts CSS-borders for table elements.

  3. Browsers handle the border attribute of the TABLE element as if a set of predefined CSS-properties. This is following consistent the generic principles[S], how borders should be handled. For example following CSS corresponds the <TABLE border="10"> -definition:

    table {border-collapse:separate} /* not necessary because browsers use this value as the default value */
    table {border:10px solid; border-color: #bbb #7e7e7e #7e7e7e #bbb} /* The colors of the border attribute are browser-dependent. These values corresponds colors, which MS IE has with the HTML attribute. By experimentation can find colors, which correspond colors of the border attribute in other browsers. Look out more about border style from the page 8[S]. */
    th, td {border:1px solid; border-color: #7e7e7e #bbb #bbb #7e7e7e}
    /* The border attribute of the element TABLE defines to the table cells always only one pixel wide borders and only the border of the table itself can be thick */
  1. If you want one pixel borders or no borders to table cells, some browsers need border="0" and cellspacing="0" attributes. Try to define borders systematic so, that any cell don't have double borders and borders are defined to the correct sides.

    th, td {border: solid black;} /* common properties */
    td.left,th.left {border-width: 1px 1px 0px 1px;} /* cells on the left */
    td.right, th.right {border-width: 1px 1px 0px 0px;} /* other */
    .leftLast {border-width: 1px 1px 1px 1px;} /* the last cell on the left */
    .rightLast{border-width: 1px 1px 1px 0px;} /* other cells on the last row */
    <table cellspacing="0"...>
    <td class="left">...</td><td class="right">...</td>...
    <td class="leftLast">...</td>...<td class="rightLast"></td>

    At this way you can get better layout for Netscape 4.x browsers, when you use background colors and concerning borders equal result to MS IE 4.0+ Windows browsers. Newest browsers (like Opera 6.x) don't need any HTML-attribute to assist defining the presentation of tables, but it is not today reasonable to define tables according them.


Basic rendering methods

In addition CSS2 offers the possibility to change with table-layout:fixed the basic method, how the browser handle tables (The default value is auto. If you use grouping, you can cancel the change with this value by creating a new rule to tables, which you don't want to use it. The property isn't automatic inherited to child-tables.)

The browser doesn't read beforehand the whole table, but it needs the width value of the whole table, which it can get by setting width-values for the element TABLE or individual cells. To ensure proper functionality, you might need to define the width property both of the table and TH and TD elements. The browser counts as soon as possible how many columns the table has and then define column dimensions. 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. Below is an example of a simple definition:

table.someClass {width:600px; table-layout:fixed;}
table.someClass th, table.someClass td {width:150px}
/* if the width value for the table is smaller than the sum of total width values of individual cells, the browser increase the width of the table */

This method decrease drastic in modem connections the delay time before anything is rendered on the screen. Indeed the total time to download the page is quite the same, but the page is readable without waiting that the browser read first the whole page. The browser tries as soon as possible to render the viewport (window) area. This method is very useful in large tables, which have much text (an example table[S]).

If you want a wide cell above other cells, you need to define a hidden row:

.hiddenA {width:200px; font-size:0px; line-height:0}
.hiddenB {width:250px; font-size:0px; line-height:0}
.hiddenC {width:100px; font-size:0px; line-height:0}

<td class="hiddenA"> </td>
<td class="hiddenB"> </td>
<td class="hiddenC"> </td>
<td colspan="3">
A wide cell.</td>


The fast table layout method has also some disadvantages. If a long table has in the end more columns and then some extra cells, the browser ignores them. If table cells have wide images, they don't fit into cells.

Because table-layout:fixed affects in the basic level to the whole layout, if layout base on tables, before every project must think, if it is used or not. I recommend also to avoid nested tables and use instead DIV elements to delimit blocks inside tables.

The functionality of the fast table layout is however reasonable to test in many browsers. The main principle is that exact definitions gives the best results. The alternative solution is to use only DIV elements to build the basic structure of web documents. I handle this model in the next page.

Browser-specific notes:

  1. Table-layout:fixed works in MS IE 5.5+, Opera 4.x+ and Mozilla Gecko browsers. The overall functionality is best in Opera 4.x+ because Opera allows also to scroll partial read tables. By using MS IE 5.5 the reader must wait that the browser read first the whole table before he can scroll it.

  2. Opera 4.x has a minor bug. Even if in principle it is unnecessary to define the widths of first cells (elements TH or TD), Opera needs sometimes the width property to them, even if to the element TABLE has been defined the width value.

  3. Opera 4.x-6.x crop additional cell off if after the first row the table has more columns as in the first row. MS IE does that in long tables. Mozilla Gecko and Opera 7.x browsers show always all table cells.

  1. MS IE crops too wide images. Opera 4.x+ and Mozilla Gecko browsers render rest of images on nearby cells, but they don't increase the width of any cell according the space, which some image might need. By setting overflow:hidden also Opera and Mozilla behave at the same way as MS IE.

  2. In MS IE and, Mozilla Gecko and Opera 7.x+ browsers this situation can be helped by adding a DIV element and defining to it for example overflow:auto; width:150px. If the width value is smaller than the width of the image, it is possible to scroll the image but at least one scroll bar is always visible.

  3. Mozilla Gecko browsers need for low table rows the line-height property (for Opera only the font-size property is necessary).


Problems with content dimensions properties

CSS2 has left open, how the property height should be interpreted in tables, when browsers can interpret it as they wish. In my mind it defines also in tables the content height (this is also the interpretation of Opera Software).

In principle the width property means also in tables the content width. Because the element TABLE doesn't have direct actual content (between the actual content is at least one TR element), in ordinary cases only borders increase the total width of the block box of the table.

The problems is however the fact that in the HTML 4.01 specification calculating the width property of the TABLE element is used another formula as calculating the width property in CSS. In the HTML 4.01 specification has been said about the attribute width following:

This attribute specifies the desired width of the entire table...

According that definition borders are counted to the total width of the table and it is not the content width like in CSS.

When the browser calculates table dimensions it must take account following matters:

  1. Because both the (HTML) border-attribute and the (CSS) border-property affect to the total width value of the table, browsers which understand CSS must take account both border definition ways in order to calculate the width-attribute correct. The fact how in CSS the border-property is related with width-property is nothing to do in this connection. If the width-property would affect to the calculation formula of the width-attribute <TABLE width="100%"> would not be possible to calculate correct.
  2. In order to calculate the CSS-property width correctly, the border attribute of the element TABLE table must take account (the width property is the width, which must reserve for the concrete content, for example for an image, which has an exact width value). This matter should not be any problem for modern browsers, which can handle the border-attribute like a predefined set of CSS-properties.
  3. Because CSS should be able to define elsewhere for CSS-properties and CSS calculation formulas must have the priority. If both the width-attribute and the width-property has been set, the browser must follow the value and the calculation formula of the width property.

Browser-specific notes:

  1. Opera and MS IE for Windows interpret border table elements almost always differently - even by using HTML-attributes:

    • border="2" width="600" or border="2" style="width:600px" or style="border:2px solid black; width:600px;" = 604 pixel in Opera.
    • border="2" width="600" or border="2" style="width:600px" or style="border:2px solid black; width:600px;" = 600 pixel in MS IE 5.x for Windows.

    In this example Opera works incorrect in HTML and MS IE in CSS.

  2. Mozilla Gecko and MS IE 6.0 for Windows browsers follow in the standard-compliant mode[S] always MS IE 5.x for Windows rendering the width of the TABLE element even if they normally interpret the width property like Opera.

  3. Also the behavior of MS IE 5.0 is DTD-dependent[S]. The modes have bigger meaning for the width values of table elements than in MS IE 6.0 for Windows.

  1. I made a pair of test pages, which have two different DTD (HTML 4.0 Transitional[S] and HTML 4.01 Strict[S]) in order to show differences in Mozilla Gecko browsers. In new Mozilla Gecko browsers the DTD-dependence affect a little bit to one rendered width value but more how the background colors are rendered. The page pair gives following result in Mozilla Gecko browsers (links refer into screen captures):

    • No a DTD tag, HTML 4.0 Transitional[S]: cellspacing creates in Mozilla 0.9 areas, which have the same background color as with the BODY-element. Compare with Opera 5.12[S]. Note. The total width of the TABLE C is according to the HTML 4.01 specification different as it is with Opera. TABLE G is exactly correct. If the table doesn't fit to the box of the DIV element, it should go over it and the width of the table should not increase the width of the DIV element (only concerning the element TABLE the content should increase the total width of the element).
    • HTML 4.01 Transitional, HTML 4.0/ 4.01 Strict[S] + newer specifications: background-color is in Mozilla 0.9 for the whole table like in Opera and MS IE. The width of the tables behave like in an edited screencapture from MS IE 6.0[S].
    • Netscape 4.x doesn't support the width property in tables. If the cellspacing attribute has bigger value than 0 (the default value is 2), it is possible to get a nice result only by using outside the table a DIV or CENTER element, which borders have the same color as the parent element and the same background color as the table. TABLE F demonstrates this situation.

I made about this subject and a test case[S], which have been used the HTML 4.01 Strict DTD. I got some e-mail about the implementations of Mac-versions of some browsers. In order to show differences in the text case I made a table, where [OK!] means correct implementation and [NOT OK!] means incorrect implementation, when implementations have been judged according to HTML 4.01 and CSS2 specifications:

Tests Windows Mac
MicrosoftNetscapeOpera MicrosoftNetscapeOpera, 6.x7.0 Beta15.06.05.0 Beta 4
Test 0a[S][OK!] [OK!] [OK!] [OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 0b[S][OK!] [OK!] [OK!] [NOT OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 0c[S][OK!][OK!][OK!][OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 0d[S][OK!][OK!][OK!] [NOT OK!] [NOT OK!] [NOT OK!] [OK!] [NOT OK!]
Test 1[S][NOT OK!][NOT OK!][NOT OK!][NOT OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 1
[NOT OK!][OK!][OK!][OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 2[S][NOT OK!][NOT OK!][NOT OK!][NOT OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 3[S][NOT OK!][NOT OK!][NOT OK!][OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 4[S][NOT OK!][NOT OK!][NOT OK!][OK!] [OK!] [OK!] [NOT OK!] [OK!]
Test 4
[OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!]

Browser-specific notes:

  1. The implementation of MS IE 6.0 for Windows should be DTD-depending, when used DTD it should render Test 1-4 at the same way as MS IE 5.0 for Mac.

  2. In MS IE 5.0 for Mac given [OK!] / [EI OK!] are reversed excluding the last test, if the DTD is taken off. If this browser would render Test 0-0d DTD independent It would behave very consistent.

  3. According to some conversations with a worker of the Mozilla org. with the used DTD Mozilla Gecko browsers should behave as I have explained. Future versions of Mozilla might have a different behaviour. In principle Mozilla should handle with the used DTD Test 1-4 at the same way as MS IE 5.0 for Mac.

  1. The Mac-version of Opera 5.x works more consistent than 5.x-6.x Windows versions. It works at the same way as MS IE 5.0 for Mac with the DTD, which is used in my test case. If th HTML width attribute would work according to the HTML 4.01 specification, the behavior of this browser would not be anything to complain. The behavior of Opera is not DTD-depending. In my mind Opera for Mac and Opera 7.x for Windows work the most consistent.

  2. Windows versions of Opera 5.x-6.x work the most inconsistent, because the behavior is depending on the value of the width-attribute/ property. Opera has a weird width-switch, which is depending on the relation between calculated and the real content, when the calculation is done according to the formula of the width-attribute. The HTML calculation formula switch is on, when the real content is larger than the calculated content. The CSS calculation formula is on, when the calculated content is larger or equal as the real content. The result conforms either or HTML 4.01 or CSS2.

  3. CSS3 offers more reasonable way to change the calculation formula of the width value of the TABLE element as the "DTD-switch". I handle this matter in the problems of the CSS2 specification[S].

  4. When dimensions are set to table cells can create easier result, which look the same in all browsers (Test 4 Fixed[S]).

In principle it would be easier not to build the basic structure upon tables. I handle alternative ways in the next page. Tables are however necessary for all data, which need table presentation. That's why it is necessary to know possible problems.

Authors can define CSS so that it cause conflict situations, which browsers handle differently. The author might have created by accident conflict between the width of the table elements and the total width of individual cells.

He can also set properties, which don't fit into tables, for example table {padding:...} and tr {margin:...; padding:...}.

Browsers have also minor bugs, which cause problems. It is reasonable to list some of these problematic situations.

Browser-specific notes:

  1. Opera 5.x+ and MS IE solves the conflict situation between the width value of the whole table and individual cells in some cases differently. Opera calculates always the total width of the table according to width property of the cells, but MS IE in normal cases (table-layout:auto) according to the width property of the TABLE element. For example following CSS might cause a serious problem:

    td {width:200px; border:2p solid black}
    table {width:400px; border:1px solid black}

    In some tables in the Internet, which has three table columns. Opera rendered it a little bit wider than 600 pixel and MS IE about 400 pixel wide. In my mind Opera works correctly, because the total width should increase according to the width of individual cells. Properties width and height create a content box, which is one kind of fictional block or rather a reservation box. Even if a table has a special priority (for example table#special {width:400px}) the total width of individual cells should not be decreased. Indeed the CSS2 specification lets the browser the right to show the whole content and build the table using an algorithm, which the browser regards as best, when the normal table layout model is selected, but in in my mind MS IE takes "extra freedoms". MS IE works however with the fixed table algorithm (table-layout:fixed) normally at the same way as Opera.

  1. If the author sets the value of the width property for the fixed layout using TABLE elements greater than the sum, which can be get calculating together all properties in the first table row, which affect to the total width of the entire table MS IE for Windows calculates the width values for the entire table and individual cells best. Errors, which Opera 6.04 and Mozilla 1.1a can do can be seen from a test page[S] when the result has been compared with the behavior of MS IE 6.0 for Windows. Because browsers interpret the width property differently, authors should be very carefully defining width values in tables and they should avoid creating conflicts.

  2. Browsers accept at various ways table {padding:...} etc. weird definitions, but some interpretations are very quirky and they cause problems to the border models. When authors define groups, they should be careful and avoid defining previous mentioned rules (this concerns also thead, tfoot, tbody {margin:...; padding:...}).

  1. Counting the total width values of table cells it is necessary to take account generic problems which relates to the dimensions, which I handle in the page 8[S]. In order to decrease dimension related problems, it is reasonable to follow an advice[S], which I gave, when I handled common block dimension problems.

  2. I found that I doesn't work for table cells always work in Opera browsers (concerns at least until version 6.01). That's why I have used in some cases spacer images and for them linked width values (Netscape 4.x browsers behave quirky if images have certain CSS-properties). Setting width for any element, which are inside cells could do the same task.