Item5391: Dragging corners of table removes TML markup

If you edit an existing table and adjust the outer dimensions of the table, TinyMCE converts the table to inline HTML markup, removing all TML formatting. This removes the ability to sort on column headings, etc.

I don't see any way to easily restore the original TML format table so that the table can again be sorted.

View the raw source - the first of the below tables had a corner dragged a small distance.

Heading 1	Heading 2	Heading 3
d1	d2	d3

Heading 1	Heading 2	Heading 3
d1	d2	d3

-- TWiki:Main/GeorgeClark - 25 Feb 2008

needs to be fixed or at least improved for 4.2.1

-- TWiki:Main.KennethLavrsen - 25 Feb 2008

Note that to restore the table to TWiki markup,

• edit the topic with the raw editor and remove all of the arguments from the "table" tag.
• Save the topic,
• edit it again with the WYSIWYG editor
• save it again - no changes necessary.

This will restore the TWiki markup.

-- TWiki:Main.GeorgeClark - 29 Feb 2008

Playing around a bit, it appears that the TinyMCE generates some incorrect HTML as well. Dragging the borders on a small table gives me:

table width="51" cellspacing="1" cellpadding="0" height="54" border="1" 

From what I could find, height is not a legal HTML attribute for the table element. I believe that these would map to the TWiki TABLE atttributs as:

TABLE{tablewidth="67" cellspacing="1" cellpadding="0" tableborder="1"}% 

omitting the height, which twiki doesn't implement. Would this be a possible solution - when converting from html back to TML, map the html table attributes to the %TABLE parameters?

-- TWiki:Main.GeorgeClark - 29 Feb 2008

This is a limitation of the way tables are done in TWiki. i think the only solution would be to generate a %TABLE tag before the generated table, which of course assumes the TablePlugin is installed - and is fraught with the potential to create other problems. An alternative would be to find a way to disable resizing of tables in tinymce, but I suspect that is impossible (table editing is handled by the browser, not tinymce).

Sorry, but I just can't see this as Urgent; it's not stopping use of the editor. The obvious workaround is to avoid resizing table. Regarded to 'Normal'.

-- CrawfordCurrie - 07 Mar 2008

Maybe we should ask upstream? Are they usually responsive in the TMCE community?

-- TWiki:Main.KennethLavrsen - 07 Mar 2008

Would it be possible to check if TablePlugin is installed? If not, insert a "comment" of some sort in the TML->HTML process, so that during the reverse you can either generate the %TABLE (if plugin was installed), or ignore the <table parameters and convert back to TML anyway.

A couple of sites I work with have many very novice users. It really doesn't take much to accidentally drag a table edge, and once the damage is done, it may be beyond the casual user to recover. Which will drive up support issues. It was confusing to me the first time it happened and I'm an experienced user.

I agree with the Normal priority, but this really ought to be fixed. The support load from novice users on TWiki can be significant.

-- TWiki:Main.GeorgeClark - 08 Mar 2008

Agreed, and I think a %TABLE tag is the answer, but I'm cautious of the can of worms it opens. The rules for placement of TABLE tags are.... baroque.... and I don't want to get caught in support issues because the editor generates them in the wrong place, or moves them, or misses existing tags. Working out the revese mapping - from HTML parameters to TABLE parameters - is non-trivial too, I suspect.

What would be incredibly helpful would be a reasonably comprehensive set of test cases; HTML tables and the corresponding TABLE tags, that can be used to test the correctness of the transform.

-- TWiki:Main.CrawfordCurrie - 08 Mar 2008

I cannot reproduce this problem on trunk (at revision 3794). If I edit a topic with a table, resize a table and then save, the table is unchanged i.e. TML markup is maintained. I think this task could be closed.

-- MichaelTempest - 02 May 2009

Agreed - this is fixed on trunk. Still fails on 1.0.5. I've changed to waiting for release.