Suggestion Box

> (Of course, in your simple example, you did lose a before the table close, thus opening the can of troubleshooting and support needs that tables will end up creating. *chuckle*)

Aha! I beg to differ.

This was based on my 2nd suggestion - the one with no {/cell} command, only a {cell} - so as to prevent users from breaking tables.

The clever bit with this is that everything the user puts between his {table} and {/table} is necessarily nested down between a <TD> and a </TD>.

So if your writingML parser found a {table}, you'd search for the next {/table} (error out if there's no next {/table}) and replace all {cell} and {row} items as noted above. (Just ignore an improperly nested {table}, the same way as something like {quote}, I believe, works). Then you've safely "isolated" anything the user has typed from interfering with <TABLE> tags elsewhere in the HTML you produce.


As for rowspan and colspan:

As far as colspan goes, I think you could just do it by width, set by the user, that's set to a 0-100 percent value. Let the user who wants to get fancy do the work.
         {cell:width} = </TD><TD WIDTH="width%">


rowspan is trickier. Particularly since it affects the "geometry" of a table outside the given <TD> element. Could get very messy to try to create an "insulated" writingML way to do it.

One way you could set it up instead - starting w/o it but leaving the door open to expansion - would be to allow for, in the future, nested {tables}. (You could do this at the same time that you implement nested {quote} blocks, which would be a great boon!)


Though nesting is less efficient than the colspan/rowspan solution, it is, lexically, simpler (provided you have recursion in place) and the users who want to get that fancy (probably a significant minority - heck, lots of people just have trouble making the simple writingML work ) can take on the challenge of proper nesting.

 A   B     C 
     d       
 E   f     G 
     h       

would be done by (I've added spaces for clarity):

this would give:
<TABLE><TR><TD WIDTH=0></TD><TD WIDTH="25%">A</TD><TD WIDTH="50%">B</TD><TD WIDTH="25%">C</TD></TR><TR><TD WIDTH=0>
</TD><TD>E</TD><TD>
         <TABLE><TR><TD WIDTH=0></TD><TD>d</TD></TR><TR><TD WIDTH=0></TD><TD>f</TD></TR><TR><TD WIDTH=0></TD><TD>h</TD></TR></TABLE>
</TD><TD>G</TD></TR></TABLE>

The browser would automatically size the 2nd row of the outer table to fit the inner table (d,f,h) and thus size the cells with E and G to match. This would be the equivalent of giving those two cells a rowspan of 3.


At least, that's my theory. Hang on...

... yup, just tried it and it worked.

Of course, you'd have to mess around with things like padding, and you'd probably want to default to centering each cell (which the user could override with {left} and {right}) but between width% and nesting, I think you could "mimic" both colspan and rowspan without having to risk letting the user run amok and break the pages.



LP


Addendum - Only the width percentages in the first row are needed - not sure if different browsers handle conflicting % information differently. But, of course, that would be the user's fault, not writingML's.

Further "multi column" cells would be done by nesting tables, the same way "multi row" cells is done in the example above. Granted, this produces some inelegant HTML code. But so what? As long as it works, right? Though the resulting HTML may be ugly (since it 'fakes' rowspan and colspan), it does make the parsing problem much easier, and it keeps the user "buffered" so he doesn't mess up the rest of the page.

Besides, that small minority of users that do want to get that fancy, with all sorts of variably-sized cells, will be the kind of users who enjoy the challenge of figuring out how to nest their tables properly, right?