• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Create a table

Let some cells be empty.

Try both with and without leaving a space.

The result of saving varies. Normally FF causes spaces in cells to be deleted and the cells to merge. When you edit again it is all a mess.

You can also create the table in normal edit mode. Again leave many cells empty but with a space.

Open and close in WYWIWYG and see cells getting merged because spaces are removed.

Internet Explorer leaves the space behind to the cells do not merged unwantedly. And if you remove the spaces the cells merge. When you enter WYSIWYG again you see the empty cells and can put spaces in them. It seems to work in IE.

But FF does not look good. I have just upgraded to FF 1.5


This is a browser problem; not sure I can do anything about it.


The problem here is that HTML rightly treats whitespace in a cell as "no content", wherease TWiki treats it very differently. There is no way to solve this for all cases, because the browser will often inject whitespace knowing that it has no effect on the layout; except, because this is TWiki, it does. Item1186 is a good example of this.

The only solution I can think of is to treat cells for merging specially in the editor. For example, if the cell contains nothing but "XXXX" in the editor, then the cell gets treated as a merged cell when HTML is converted to TML. Otherwise cells have fore-and-aft whitespace removed, and whitespace is forced into empty cells). An editor can manually enter ''XXXX" in the cell to make it disappear in TWiki. Does that sound like a better solution?


I am not sure I understand the proposal. Is your idea to let "XXXX" be the syntax for merging? Could work I guess. Someone else may propose a more intuitive syntax. Maybe some %MERGE% variable or some other symbol.

I do not understand the connection to bug 1186 confused


The connection to Item1186 and Item1073 is the treatment of spaces in cells. Ths topic is proposing a general solution to cells only containing space, or with spaces at the start or end, that addressess all three problems.

An intuitive syntax would be great; but I hat %MERGE%. I can't think of anything better.....


I like the idea of solving the problem this way, default whitespacing.

I wondered - %MERGE% would that mean merging to the left or to the right?

If it makes no sense trying to seperate the two, perhaps we can use a simple %SPAN% - or if it actually does matter, perhaps a longer, more descriptive form like %SPANWITHNEXT% / %SPANWITHPREVIOS%, or even %SPANLEFT% / %SPANRIGHT% ?

(This suggestion as HTML already talks about "spans").

-- SP

I think I am confusing two usecases above

  1. TWiki displaying an already produced TML table containing whitespace (%SPANLEFT% is adequate)
  2. user wants to span cells when editing a table - if the user shouldn't be forced to move content left before spanning, %SPANRIGHT% will be handy. Of course it might confuse the user, that once he wysiwyg edits the table again, he will see cell content is moved left, and there's a %SPANLEFT% on the right.

I guess just using one tag will do, leaving the part on (pre-)arranging the content properly as an excersise for the user. I prefer %SPAN% to %MERGE%.

-- SP

%SPAN% it is. SVN 8300


Summary WYSIWYG Tables. Firefox can not handle empty table cells very well
ReportedBy KennethLavrsen

SVN Range Thu, 22 Dec 2005 build 7896
AppliesTo Extension
Component WysiwygPlugin
Priority Normal
CurrentState Closed

Checkins 8300
Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r10 - 2006-01-15 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback