Thanks, that's what I thought. My filter converts back and forth between tables and lists of lists. Currently I have column widths default to 1 divided by the number of columns, or if some column widths are specified (through an attribute on an enclosing div) the last specified width is repeated as needed. I'll stick to that since cells sometimes do have block content; in fact that and making it easier to (re)move and inserting columns is the main rationale for editing tables as lists of lists.
I actually convert between percentages and floats, so the width attribute the user sees is actually a "list" of integers which I divide by 100 when generating the table. When going in the opposite direction I multiply the floats by 100 and floor the result. When looking at the table widths in the serialized AST the floats often have very many decimals. Do the writers actually care about all those decimals? I guess not but I wouldn't want columns to get significantly narrower for each conversion, as they might do if the `original_width * 100` is floored many times. Perhaps I should take the trouble to round to the nearest integer (i.e. add 0.5 before flooring)?