[ . t . Â . b . l . è . s . . ]
  [ . . . . . . . . . . . . . . ]
  [ t h e . . . . . . n É x t . ]
  [ . . . . . m u t a t Ï o n . ]

Attack of the 20 ft. COLS.
(Ominous changes in Navigator 4.0).

In our recent attempts to use the newest Netscape Navigator 4.0 (which comes under Communicator guise now) we have noticed some subtle change in table rendering behaviour, not mentioned in beta 5 release notes (as well as betas 4, 3, 2 and 1 ), so we took it upon ourselves to document it.

The change involves COLS parameter in the TABLE tag.

Versions of Navigator prior to 4.0, seem to ignore COLS parameter, while Navigator 4.0 (which is still in beta), lays out table differently dependent whether the TABLE tag has COLS parameter or not. Originally, Navigator used complex heuristics in order to determine widths of the table columns. Now, if COLS parameters is specified and widths of table cells are not specified explicitly, Navigator will simply split table on as many columns as declared by the COLS argument, all of them being of equal width. Take, for example this table: 

<TABLE BORDER>
  <TR><TD>a word <TD>many ... many words
</TABLE>

Which would be rendered somewhat like this in all versions of Navigator (including 4.0): 

/-----------------------------------------------\
|      |many many many many many many many many |
|a word|many many many many many many many many | 
|      |many many many many many many many words|
\-----------------------------------------------/

Now, if one adds COLS=2 parameter to the TABLE tag, then both colums will be of equal width (half of the total table width): 

<TABLE BORDER COLS=2>
  <TR><TD>a word <TD>many ... many words
</TABLE>

/------------------------------------------------\
|                      |many many many many many |
|                      |many many many many many |
|a word                |many many many many many | 
|                      |many many many many many |
|                      |many many many many words|
\------------------------------------------------/

We found that it always works, whether total table widht is unspecified or specified in percents or pixels -- as long as table cell widths are not defined, leaving the task of determination of column widths up to the browser.

It is still possible to manipulate separate column widths, by specifying the width of the first table cell explicitly in pixels, or total table width and width of each individual cell -- in percents.
For example, to make first column of our sample table 100 pixel wide: 

<TABLE BORDER COLS=2>
  <TR><TD WIDTH=100>a word <TD>many ... many words
</TABLE>

/-----------------------------------------------\
|       |many many many many many many many many|
|a word |many many many many many many many many| 
|       |many many many many many many words    |
\-----------------------------------------------/

We still do not know whether discovered behaviour is a bug, feature or a bug that will be declared as a feature later. Strangely, even with new COLS parameter awareness, Navigator 4.0 seems to be still unable to incrementally load the table.

We gathered all sample tables on a separate page, so everybody with Navigator 4.0 can go and check for itself.

. . . . . . . . . . . .

[base][ground]