<xml> in html make IE truncate paragraphs (solution included)

[Guillaume Outters]

Example: IE6 or IE7, go to http://www.fckeditor.net/demo, Source, insert "<xml>toto</xml>" before "You", Source, Source.

Result: Everything has disappeared after the newly-introduced "<xml>" (well, it was transformed to an "<!-- Element not supported - Type: 9 Name: #document-->").

Analysis: While generating the DOM for something like "<p><span>s</span><xml>x</xml><span>s</span></p>", IE creates a document node in which it incorrectly includes, not only "<xml>", but its nextsiblings too. Thus FCK receives it as "<p><span>s</span><!-- Element […] --></p>".

Solution: Filter out those. On line 299 of internals/fck.js (revision 203), add "|XML" to sTags.

Why, oh why: Because we had a Word-generated HTML that included some "<xml><o:OLEObject>[…]</o:OLEObject></xml>", sometimes embracing the OLE into IE-specific conditional comments.

[fredck]

Confirmed with IE6. Ok with FF2.

[alfonsoml]

Alternative solution

[alfonsoml]

I've attached a patch with an alternative solution that tries to take care of the serialization of the DOM instead of changing the namespace of the tag.

The differences from my point of view are as follow with very little testing:
With the first patch the contents of the xml tag are visible while editing, and those contents are parsed (so special elements are converted to entities).

With the second patch the contents aren't visible and the output is the same string that it was there at the start.

So if we want to show the contents in the editor we should go for the first patch. On the other hand, if it is better to not show or change them, then the second patch would be a better solution.

[fredck]

Alfonso, wouldn't the following be a much simpler and efficient solution, resulting the same exact behavior in IE and FF?

editor/_source/internals/fck.js

@@ -297 +297 @@
 
                 // IE doesn't support <abbr> and it breaks it. Let's protect it.
                 if ( FCKBrowserInfo.IsIE )
-                        sTags += sTags.length > 0 ? '|ABBR' : 'ABBR' ;
+                        sTags += sTags.length > 0 ? '|ABBR|XML' : 'ABBR|XML' ;
 
                 var oRegex ;
                 if ( sTags.length > 0 )

[alfonsoml]

wow, it still surprises me the nice integration between trak and SVN :-)

The nicely shown patch is what Guillaume proposed in the original report, and I wanted to take a look at other options to fix the problem, the results are as explained some minor differences, and I think that Guillaume should say if one solution is better than the other for the real code that he's facing.

If it doesn't matter then it's clear that just protecting the <xml> tag is quite simpler.

[fredck]

For now, I'll go with the simpler way. I don't really care about interpreting the contents of <xml> tags. Let's just see them as normal <span> tags.

Fixed with [351].

Click here for more info about our SVN system.