Skip to content

Rhaptos Software Development

Personal tools
You are here: Home » Developer Blog » Max's Blog » Tables (CALS to XHTML fixes)

Tables (CALS to XHTML fixes) Tables (CALS to XHTML fixes)

Document Actions
Submitted by maxwell. on 2005-08-01 15:26. Style
I've been working on new and improved XSL for CALS table -> XHTML table transformations.

It's been in the back of my mind for a long time that the XSLT we use for converting CALS tables to XHTML is incomplete. Specifically it ignores many attributes, such as colsep and rowsep, for example, which determine whether or not there are separators between the table cells and rows. It also completely ignores the spanspec tag.

As I was working on the Help pages for the new EIP and needing to refer occasionally to the CALS table spec, it also occurred to me that the way we are outputting tables in some stylesheets as having cellspacing seems to be incorrect as well, considering that table cells ( tags, more specifically) should only have borders on their right and bottom sides, unless they are the last cells in a column or row, in which case borders are ignored and the table's frame attribute will determine whether there any border appears to enclose the cell to the right or on the bottom. Cellspacing (which currently appears in all our stylesheets) negates this by creating full borders for each cell, as well as an outer border for the entire table.

So I decided that during the last two weeks, while things were sometimes slow or I was waiting on others, I would work on fixing some of the current deficiencies in table.xsl. I started off, however, making little tables with examples of each of CALS's attributes and tags, and putting them in m10221 (revisions yet unpublished). I've also started work on table.xsl, trying to different things to see how they will work.

I'm not sure that my idea is the best solution, but I've been thinking that the most cost-free way of outputting these new table features might be to write inline CSS declarations right into the tags themselves. For example, a table cell might now be output as such:

<td style="border-right-width: 1px; border-bottom-width: 1px;" />

The benefit of this would of course be not to have to write something like

<td class="border-right-on border-bottom-on" />

and then write CSS everytime I write a stylesheet that then reflects this:

.border-right-on{border-right-width: 1px;} .border-bottom-width{border-bottom-width: 1px;}

It would also work better with browsers that have difficulties with multiple classes. The drawback, however, is that, let's say I want the borders of tables in Playland (i.e. where they're actually called for, by frame, rowsep, and colsep attributes (or lack thereof)) to be 3px thick. If I then right some CSS like:

table.table{border-width: 3px;} table.table td{border-width: 3px;}

the borders are then redrawn everywhere, including where they aren't supposed to be. This problem would require that all stylesheets use the same table border thickness. I'll keep on looking for ways to avoid this, and it may be that I have to just invent a bunch of classes instead of writing inline style, but I was hoping to avoid a bunch of table CSS. Maybe there wouldn't be as many classes to invent and CSS to write as I am imagining. Either way, the XSL I'm currently writing will lay the groundwork for either writing in CSS classes or inline styles.

Re: Tables (CALS to XHTML fixes)

Posted by brentmh at 2005-08-08 20:38
Instead of trying to only output right and bottom borders, shouldn't we use CSS's border collapsing: http://www.w3.org/TR/REC-CSS2/tables.html#collapsing-borders ? Or did I misunderstand your comment?

Re: Re: Tables (CALS to XHTML fixes)

Posted by maxwell at 2005-08-09 17:13
Actually, I was planning on using border-collapse anyway. The problem with using only border-collapse and letting individual cells have borders all around is that on convergent edges where one element wants a border and the other doesn't, the bordered element wins. So let's say you have a <table frame="none">. If I give the individual cells borders on the top and left as well as right and bottom, it will appear to give the left and top sides of the table a border, even though it has called for none to appear.

I suppose I could do what I was already going to have to do with the elements which are last in their columns and in the last row, which is not put a border-right or border-bottom on them, respectively. But I think it would be easier to find these "corner" cases just once, and if I understand the CALS spec correctly, putting a border to the right and bottom (assuming they're not in the last column/row, or turned off by colsep or rowsep attributes) is what is supposed to happen anyway (see the "COLSEP" and "ROWSEP" descriptions under the <entry> tag here: http://www.oasis-open.org/specs/a502.htm)
Developer Blog
« July 2008 »
Su Mo Tu We Th Fr Sa
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
2008-07-02
12:53-12:53 Performance tests of module PDF generation
Categories:
Content (55)
Copyright (0)
Deep Code (3)
Development (198)
Markup (22)
Metadata (1)
Printing (7)
Style (9)
Testing (2)
Usability (6)