Item1391: < div > disappears in Rich-Text-Editor

If you are using < div > for advanced formatting, it is erased by the WYSIWYG-editor in Foswiki.

Example: http://foswiki.org/Extensions/WebHome

The only way to protect the < div > - Blocks ist to use "sticky". The editor should protect "divs" right away when first editing them.

See this Screencast for more info.

Sample code

---+ Test
<div class="foswikiRight">
   <img src="titi69.canalblog.com/burro_do_sherk.jpg">
</div>
dlökdölkdölkdölkdölkdökldölkdöldködklöldkd dklölkklj salkg fkldj gfdjks gjkhsdgkh ghksd fjkhgkjhfgkjsdh gkjsdhgk jhsjkdgh ksjfdh gkshdfjkghsdjkfgh jksh gksfg hskfdhghk sgkjshfdkgjh sfdkghsfdkh ksdhgksdhf khsfdkghfkdjgh fdgkhfdkgh fdk ghkjfdhgj khdfskjgh kdsfhgkjfdhgkj hgkh jksfdhgkjdfhghdkfj hdksfjhg kjdfhgkjh kfdjkghfdjkhg kjdhgkjfdhg kjfdhgkjfdhg jkdfgkhfdskj hgfdjksghkfdsj hkdfgh kfdjsgh kjsdfh gkjfdhgjk fdhjkgh jkfdh gjkhdfjkgh skjldh gkljsh skjfd kjgh jksjkfhgjksfdh kjghkjfdhgjkfdhjkfdh sjkdfghjkfdhjkhjksdh jksfdhgjh

Information about the tested instances and browser

Testing environments:

Browser:

---

This is a documented limitation of Foswiki. Since TML has no concept of a "div", then it has to be removed to avoid conflicting strongly with TML.

Confirmed, but don't expect a fix any time soon.

-- CrawfordCurrie - 31 Mar 2009

I was just (at long last) able to view the video, and see that the report relates to images added by the image inserter. That should be fixable.

-- CrawfordCurrie - 04 Apr 2009

I think it's more about an incorrect handling of div tags, since it's also affecting html parts without images. Are there any solutions for that problem?

-- SvenHess - 16 Jul 2009

WysiwygPlugin can be made to protect divs automatically, by adding this line to any plugin's initPlugin handler (including WysiwygPlugin's):

addXMLTag('div', sub{1});

However, this is not a good fix because the content of the div is shown as raw HTML, which is not WYSIWYG at all!

-- MichaelTempest - 31 Jul 2009

This one should be "easy" (he says naively), but I really do need some sort of element or class that will be guaranteed to be either flattened or removed in transition from html2tml so I can make a tinymce work-around for Item9198.

Michael, added you in case you have some ideas (or such class/feature already exists and I just didn't see it!)

-- PaulHarvey - 25 Jun 2010

Currently, WysiwygPlugin's HTML2TML is very (overly!) vigorous at removing classes, and it flattens p, div and span tags without attributes, after removing classes (this is a huge over-simplification). I used this behaviour to my advantage in addressing Item1417, where I added a p tag with the foswikiDeleteMe class. There are unit tests to ensure that HTML2TML removes empty p tags with that class. The unit tests could be improved, but the existing test is some kind of guarantee that this behaviour will continue to work in the future. (Removing my name from WaitingFor)

-- MichaelTempest - 25 Jun 2010

I can protect HTML tags in the TML by applying a class to raw HTML tags found in the topic text. This means that HTML2TML would clean up HTML entered via TMCE and cut'n'paste from Word, but it would leave alone HTML that came from the topic text. That means that upgrading WysiwygPlugin would not provide "better cleanup" for topics with existing HTML. I think that is a fair trade-off.

I could limit this to a specific set of tags (e.g. div, span, table, td, th). I could use a preference (e.g. WYSIWYGPLUGIN_PRESERVE_EXISTING) to define the set of tags, defaulting to no tags if the preference is not set, and set the preference to div,span in DefaultPreferences.

I have that nagging feeling that I missed something. Comments welcome

-- MichaelTempest - 30 Aug 2010

Actually, that sounds very reasonable. I might say that WYSIWYGPLUGIN_PRESERVE_EXISTING_TAGS although more verbose, might be less like to conflict with some other _EXISTING feature later? I don't really mind either way

-- PaulHarvey - 31 Aug 2010

Yes, that name is better. I also think it would be more useful for upgraders if the default value for this preference was only in the plugin and not in DefaultPreferences.

I would like to revise the proposed mechanism as follows:

• When converting from TML to HTML, WysiwygPlugin will mark tags that come from the TML with a specific class, so that it is possible to differentiate between tags that were originally in the TML and other tags of the same type that were inserted during editing or were produced by the TML2HTML conversion.
• When converting from HTML to TML, WysiwygPlugin will not remove tags the listed in the WYSIWYGPLUGIN_PRESERVE_EXISTING_TAGS preference, that were originally in the TML.
  • That preference will not be given a value in DefaultPreferences.
  • The default value of that preference will be div, span.
• HTML tags that were originally in the TML which are not listed in that preference, will not be given special treatment; they will be handled just like all other tags of the same type. For example, <table> tags might be converted to | table | markup, and spans might be flattened, depending on the attributes and the WYSIWYGPLUGIN_STICKYBITS setting.
• The user may set the preference to blank (empty string) in which case no HTML tags originally in the TML will be given special treatment.

-- MichaelTempest - 01 Sep 2010

Yes, that sounds very sensible. Go for it.

-- CrawfordCurrie - 04 Sep 2010

Okay - it is implemented and documented, but I have not yet updated the release notes. The TinyMCEPlugin topic must also be updated, as it mentions this item, too.

-- MichaelTempest - 05 Sep 2010

This fix went into 1.1, but it didn't make it into the 1.1 release notes because I still had to update the plugin release notes. That is now done. I have set the released-in version to 1.1.2 so that this goes into the 1.1.2 release notes.

-- MichaelTempest - 06 Nov 2010