Wwwtable

Unless you have a diagram and a clear idea of what goes where, tables can be hard to get right. Even then, they're hard to typeset in HTML, and hard-to-find problems arise all the time. Well, they do if you edit in the cavalier cut & paste style that I prefer. Fortunately, you wont have to debug cryptic dense HTML to find these problems anymore. Wwwtable does a reasonable job of making sure you don't try to do something bogus with you table. For example, if I had made a mistake and specified some data for cell (1,4), having already said that cell (1,1) has a colspan of 4, I would have received a warning message like this: wwwtable: Line 25: Cell (1,4) has already been specified, implicitly, in the rowspan/colspan specification of cell 1,1 (see line 3). Cool. Wwwtable will also detect other attempts to put multiple things in one cell, and chastise you accordingly. For example, you might see messages that look like these: wwwtable: Line 25: Cell (2,2) has already been specified (see line 7). wwwtable: Cell (3,3)'s rowspan and colspan information (rowspan=1, colspan=1, conflicts with a previous definition of that cell's contents (line 21). wwwtable: The intersection of the specifications of cell (1,3) on line 3 and cell (2,1) on line 5 is non-empty. Both include cell (2,3). These cover some of the most obvious ways you can botch up a table, and the messages should be understandable.

What's going on here? First of all, it's easy to see why the table is 4x4: only one cell was specified (and it was left empty), so wwwtable fills in the missing cells. It's the first two cell specifications that are new. The first one (*, *) width=140 align=center uses a perl-style regular expression to indicate the applicable row and column numbers. Wwwtable allows the use of * by itself to mean the regular expression .*. So that line means that all cells whose row number matches the regular expression .* and whose column number matches the regular expression .* should have width=140 align=center appended to their or information. This explains the width of the table cells and why the words All yellow are centered. The next line, (2|3, 2|3) bgcolor=yellow, also uses a regular expression to indicate that some cells (those whose row numbers and cell numbers match 2|3) should have a yellow background color (apologies to those who cannot see this!). The following line gives some text that should be placed in the cells that match the regular expressions. The cells and rows that match those simple regular expressions are of course those numbered 2 or 3 (the | means OR in a regular expression). So the middle two columns and the middle two rows contain the words All yellow and (if you have the right browser) have a yellow background. This is a very simple example of what you can do with regular expressions for row and column numbers. In fact, the numbers we saw before were also regular expressions - just ones that only match a single string.

If you can be bothered reading all this, you'll see the table within a table in cells (1,1) and (1,3). Cell (1,2) is just an empty cell with width=50 to give a little separation between the outer cells. But wait, what's all that ( crud doing there? It's there because I wanted to include lines in a table that looked like directives to wwwtable. If I had simply written (1|3|5|7|9, *) bgcolor=yellow in cell (3,3), wwwtable would have interpreted that as an attempt to define a new cell. Instead, I wanted to show some input to wwwtable, without having it interpreted along the way. So I used the HTML character code for ( which I happen to know is (. You can always prevent wwwtable from recognizing an input line as a cell definition by changing the leading parenthesis in this way. It's one of life's little annoyances, I agree. I could get around it by making the cell definition lines syntactically more obscure so the problem would arise less frequently, but you'd still run into the problem when you tried to put wwwtable input into a wwwtable cell. At some point I may add something to tell wwwtable to stop interpreting lines temporarily, but for now you'll have to live with it. In any case, if I add that speciality, what happens when you want to include IT in a table? And on and on. Even more depresssing is that every time I add another layer of special case input processing, I have to document it here and go even one layer further so you can see it. Try view source on the above wwwtable text and you'll see what I mean. Phew. Enough of that.

Which should give you an idea of where your text will wind up. Notice that you cannot (yet) use (( CELL_REGEXP, CELL_REGEXP )) (this thread can come in handy) to make a regular expression worth of cells be header cells. You have to give a specific cell (e.g., ((4,5))). I will fix this at some point, when I decide how to deal with conflicts (like the ones I am about to describe). In the special case where you use the regular expression * (or, more correctly, .*) to indicate a set of columns and give an exact row number, wwwtable will put the CELL_OPTIONS (if any) into the appropriate tag. For example, if you give (4, *) align=left then when wwwtable generates the 4th row, it will do so using rather than by putting align=left into each cell specification in the row. This is an attempt to be nice to the browser that will end up displaying your table. Unfortunately, this can lead to slight problems because the row specification can then be overridden by specifications given to individual cells within the row. All of which leads me to say that there are some issues with precedence that I have not yet resolved. The problem is that information about what to put in a cell and what properties the cell should have can come from many places. For example, the alignment of text within cell (4,5) might come from a tag for the 4th row, from the individual cell's (4,5) specification, or from any number of regular expressions that might match this cell. It is hard to know what to do about this. Should I take the most specific information only (but then how to decide which regexp of several is the most specific)? Should I not allow information to come from two places at once (and thereby rule out convenient things like (*,*) width=100)? Should I set up some inflexible default ordering of what specifications (and text) will be applied to each cell? Should I look at the content of the specifications and disallow conflicts? And there's more. More than I can handle cleanly right now. I've already spent more time wondering about this than it's probably going to be worth.