Bug #34786: Custom tags get malformed in IE - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Bug #34786

closed

Custom tags get malformed in IE

Added by Bart Dubelaar about 12 years ago. Updated over 11 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

RTE (rtehtmlarea + ckeditor)

Target version:

Start date:

2012-03-13

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.5

PHP Version:

Tags:

Complexity:

Is Regression:

Sprint Focus:

Description

Any custom html tag that is not in the HTML 4 spec will get malformed in IE.
A line like this "My text <tag>hi</tag>" is being rewritten to "My text <tag></tag>hi</tag>" when the content is loaded into the RTE.
And then of course things get really messy if you save this again or switch back and forth between wysiwyg and text.

I suppose that at some point of time custom tags were working, because there is huge amount of tutorials on the web on how to implement it in the RTE.
Forcing the rendering engine of the backend to IE9 fixes this, but it breaks other parts of the RTE. And of course this should be working for older IE versions too.

Actions

Copy link

Updated by Bart Dubelaar about 12 years ago

"My text <tag>hi</tag>" is being rewritten to "My text <tag></tag>hi</tag><'doubleslash'tag>" have to do it like this or the doubleslashed tag disappears.

Actions

Copy link

Updated by Bart Dubelaar about 12 years ago

So what happens is that the IE DOM cannot see children of a custom node, so the 'walk' iteration of htmlarea does not descend into the node. As a result, the closing tag is also seen as a separate entity. Officially one should extend the xml namespace (xmlns) to support custom tags in IE, then they will be parsed correctly in the dom. However this means that the <html> tag of the RTE needs that additional xmlns and that only tags in this fashion "namespace:tag" are allowed. Such a colon is incompatible with typoscript, so not the way to go.

Actions

Copy link

Updated by Bart Dubelaar about 12 years ago

After too many hours of debugging I have come up with a working fix based upon the HTML5 Shiv (http://en.wikipedia.org/wiki/HTML5_Shiv). I will push a patch on 15-3.

Actions

Copy link

Updated by Oliver Hader about 12 years ago

Hey Bart,
since you were referring to versions this worked well - could you tell, since what TYPO3 version you experienced that misbehaviour? Thanks

Actions

Copy link

Updated by Oliver Hader about 12 years ago

Status changed from New to Needs Feedback

Actions

Copy link

Updated by Bart Dubelaar about 12 years ago

Hi,
Just by looking at the code I can see that versions 4.5 and up share the same codebase. They all have the same DOM walker that is causing this issue. Previous versions, 4.4, 4.3, 4.2 have a different codebase in which I cannot directly find the affected code. I don't have a setup with any of these versions so I cannot test it quickly.

I only assume that it must have worked in version < 4.5, as extensions like 'de_custom_tags' exist that won't work with 4.5+.
On the other hand, maybe I am one of the few that is trying to work with custom tags 'unprotected'. In other words, I do not want them to show up in the RTE as 'htmlspecialcharred' tags. Many examples on the web show how to use cutom tags with the 'protect' flag.

In any case I am sure that this issue exists for any of the current stable TYPO3 versions. It is a well known issue that the DOM of IE does not parse any custom tags other than the basic set of HTML 4.0. So this means that JS DOM functions will not inlcude these tags and same goes for CSS which cannot be applied to such tags.

When showing text in an RTE, the htmlarea extension will traverse all contents from the DB with JS DOM functions and build the contents for the RTE from that. It is in this conversion that the custom tags get malformed, because they are not recognized as tags.

The HTML5 Shiv trick will add the custom elements to the DOM, this will trick the DOM to recognize them later on. This also enables the possibility to apply CSS to these custom tags.

Actions

Copy link