CDR Tickets

Column widths for tables in the CDR are specified as relative widths. A column width unit is described as * while the width of every other column is based on this. A column specified with a width of 2* is twice as big as the smallest column of that table. By default the column width for every column within a table is * or 1* in XMetaL making each column equally wide.

Using this relative definition for column widths was never well supported by browsers, especially not by IE. So around 3 years ago we decided to make live easier for IE and specify the column width in a unit it understands and we converted in our vendor filters the relative widths to a percentage. Therefore, a table with two columns of width 1* and 2* became a table with widths of 33.3% and 66.6% when displayed in HTML.

As it turns out, these percentages are causing headaches for IE, too (or at least the designers having to deal with IE are getting those headaches). :-)
Problems occur because a smallish table is now being stretched to fill out the entire width of the display area when the content does not need to be as wide. For instance, a table that could look like this:

---------
| a | b |
---------

might look like this in IE

-------------------
|   a    |   b    |
-------------------

Mark would like the column width to be decided by the browser rather then setting it specifically in XMetaL or the vendor filter. He argues that browsers are typically very good at figuring out how wide a column needs to be.

A caveat is that for existing tables for which we're adding an additional column, XMetaL automatically adds a column width that's larger than then default unit. Instead of adding a table with the width of * , XMetaL adds a column of the width 1.5*, for instance. Therefore, if we were to decide not to specify the column widths for tables containing only columns of default column width all tables would need to be inspected to identify the correct settings.
Also, we may have tables for which we do want all columns to be of equal width.

Which ever we decide, it's not going to be fun but I promised Mark I would bring up the question for discussion.

Linking to related issue.

This summary contains two tables that would be affected by a change in providing the column widths:
http://www.cancer.gov/types/leukemia/hp/adult-all-treatment-pdq#section/all

(see Table 1 and Table 2)

We will experiment with individual tables as our next step. We will also investigate whether tables can be created without specifying a width, and whether the width can be removed after the table is created.

In XMetal a column width by default is set to ( * ) with a multiplier that can be set to zero. However, the filter is converting a 0* width as well as the width ( * ) to 1*. Therefore, it's currently not possible without a filter change to send a table to Cancer.gov without a specified column width.

it's currently not possible without a filter change to send a table to Cancer.gov without a specified column width.

Wrong again!
Bob showed me an option I didn't notice before and it is possible to selectively define a table without a specific table width. However, currently each table column would need to be setup manually.

Volker will experiment with using a template to control what goes into the colspec element. If we can't solve the problem that way, the next step will be to create our own table-creation macro.

Here is a discussion that is a little bit older (from 2012) but is asking XMetaL the same question we're facing:
http://forums.xmetal.com/index.php?topic=2018.0
XMetaL has recommended the poster to remove the ColSpec attribute from the XML but that would not work for us because we don't want to remove the attribute globally. Configuring templates such that the attribute doesn't get created doesn't appear to be a solution.

We determined there's nothing to be done at this time for this issue, so I'm moving this out of the Darwin release.

Will be addressed in CDR 2.0.