[Top]
More advice for the full screen mode.
   
Sivut toimivat riittävän hyvin MS IE 4.0+, Opera 5.x+, Netscape 6.0+/ vast. Mozilla ja Konqueror 3.x selaimilla. Yleisesti ottaen sivut toimivat parhaiten uusimmilla Opera selaimilla. Sivujen toimivuus vanhemmissa selaimissa on heikko, erityisesti Netscape 4.x kohdalla.

All topic groups:
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.
 
 
Search:
[Help]
Table of topic groups > Front page of CSS-guide > Guide pages > 10.  How to set CSS for table elements > Problems with content dimensions properties (section 4/4)

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
5.56.06.25.12, 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
Fixed[S]		[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
Fixed[S]		[OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!] [OK!]
Correct5/106/105/106/106/106/105/106/10
 

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.

[Top]

   
Copyright Tapio Markula 1999-2003, Salo, Finland
(table of topic groups, E-mail - add Tapio.Markula)( tapio.markula@nic.fi)
Not into the public use without my permission. If you want to use my pages at some way read the copyrights.
Get Expression!

An editor for creating standard-compliant HTML and XML documents. Documents of this site have in most cases checked with HTML Tidy by Dave Ragget (W3C) and randomly with the official MarkUp Validation Service of W3C. The syntax of most pages in this site should conform with the XHTML 1.0 specification of W3C. Test this page!
Information about browsers, which render or print this site best.
[Get Opera!] [Get Mozilla!]
CSS-guide has been last edited 07.08.2004
  ç¿»è¯‘：