Bug #34786
closed
Custom tags get malformed in IE
Added by Bart Dubelaar about 12 years ago. Updated over 11 years ago.
100%
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.
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.
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.
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.
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
Updated by Oliver Hader about 12 years ago
- Status changed from New to Needs Feedback
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.
Updated by Gerrit Code Review about 12 years ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9743
Updated by Stanislas Rolland about 12 years ago
Oliver Hader wrote:
Hey Bart,
since you were referring to versions this worked well - could you tell, since what TYPO3 version you experienced that misbehaviour? Thanks
I have never seen unprotected custom tags working in IE.
Updated by Gerrit Code Review about 12 years ago
Patch set 2 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9743
Updated by Gerrit Code Review about 12 years ago
Patch set 3 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9743
Updated by Gerrit Code Review almost 12 years ago
Patch set 4 for branch master has been pushed to the review server.
It is available at http://review.typo3.org/9743
Updated by Gerrit Code Review almost 12 years ago
Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/10913
Updated by Bart Dubelaar almost 12 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 3c8089c42cd2aa3754016f15479c4a102144b523.
Updated by Gerrit Code Review almost 12 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/12512
Updated by Gerrit Code Review almost 12 years ago
Patch set 1 for branch TYPO3_4-5 has been pushed to the review server.
It is available at http://review.typo3.org/12513
Updated by Bart Dubelaar almost 12 years ago
- Status changed from Under Review to Resolved
Applied in changeset 8d1d267d57eb170a6a1c982ddf25e6503ad672bd.
Updated by Gerrit Code Review over 11 years ago
- Status changed from Resolved to Under Review
Patch set 1 for branch TYPO3_4-7 has been pushed to the review server.
It is available at http://review.typo3.org/13174
Updated by Gerrit Code Review over 11 years ago
Patch set 1 for branch TYPO3_4-6 has been pushed to the review server.
It is available at http://review.typo3.org/13285
Updated by Wouter Wolters over 11 years ago
Please close this issue. All affected branches are up to date.
Updated by Stefan Galinski over 11 years ago
- Status changed from Under Review to Closed