Suggestion Box

You know, that might do the trick - just pass it to HTML.

If users want to mess with colspan and rowspan, they have to expect them to behave as the analogous HTML would. Then they don't have to learn something new, and when they mess it up, you can blame it on HTML, not writingML.


Colspan and rowspan both (I think) work as tags on an individual cell (TD), with subsequent cells moving "around" them as needed.

The one trick is that you'd have to have a {} with multiple parameters - {cell cols:X rows:Y} = <TD colspan="X" rowspan="Y">


'Width' would be the other trick, since users would want to control the relative position of the columns. But you wouldn't want to support 'width' with each {cell}, especially not with cols and rows as parameters.

One option would be to have a dummy header row defined along with {table} to set up dimensions.

{table:10,40,20,20,10} could produce:

<TABLE WIDTH="100%"><TBODY><TR><TD WIDTH="10%"></TD><TD WIDTH="40%"></TD><TD WIDTH="20%"></TD><TD WIDTH="10%"></TD></TR>

As long as there's no padding etc, I think this 'setup' row would be invisible, but it would establish the relative positions of subsequent columns in the table.

I'm not sure, offhand, what would happen if the user, subsequently, added too many {cell}s in a row - would it stay within the region defined by <TABLE>?


With both opening and closing tags, you'd have to address the problems of users putting stuff between them. E.g. ...{/cell} I'm not in a proper TD field nyah nyah {cell}...

I don't know if this fits in with the order and flow of your parsing algorhithms, but you could use {hide} to deal with that.

E.G.
         {cell:cols=2,rows=3} = {/hide}<TD colspan="2" rowspan="3">
         {/cell} = </TD>{hide}

(i.e. use "hide" to remove anything between a table command {/...} and the next table command {...} so that while users could put stuff 'outside' of the cells in the table, it'd never be parsed...)

Though then, I suppose, a sneaky user would go ...{/cell}{/hide}nyah nyah{cell}... But if your parser just skips the text between a {/...} table command and the next {...} table command, it'd have the same effect w/o that loophole.



LP