TYPO3 Core

Mantis seens to have "stolen" sme of your input (tags?). The description as it is, is incomprehensible.

[ ah, great. Mantis hides entered BR tags and if i use less/than-html-entity it escapes it :-( ]

[ Please note: read < instead of # in the following text! ]

Suppose there is a XML import file which contains BR tags like #br/>. Those could probably use a whitespace before the '/' and should read #br /> instead - I am not shure of what the xhtml specification says.

Hoewever I feel it would be nice to have the whitespace automatically added to make it a valid BR tag instead of putting it through htmlspecialchars().

The problem may only apply for third-party-generated Typo3-Import-XML since htmlArea 1.4.1 already does the conversion so Typo3 can't produce such XML files itself.

You don't need any whitespace before / for xml validity. I see no point in adding them. Having such an option just makes things more complicated.

And I don't get it what this whitespace has to do with htmlspecialchars(). The function does not alter any whitespace.

And where does the XML "import" take place? You talk about "import" (where, when, what), the RTE and FE output.

Now I don't get at all what you want. If your problem is RTE related, please post your problem there. Other problems prost in English list or perhaps the dev list.

After and get back to this bug with a proper description of the issue.

I still don't get it. The T3D of RTE fields (for whatever reasons) in your example has a space before the final / of all single tags (br, img).

The fact that all angle brackets are saved as entities is correct and is independent of the spaces issue (which is IMHO none at all - the space is optional but should not bother the reading code). The T3D is a container XML, so any data inside its elements must be encoded with entities.

ah, my fault. Wrong file. This one is the right one (see second attachted file).

sorry if I am going on your nerves. I also don't like spending too much time on single issues.

Like Masi I don't understand this bugreport.

Also since the reporter states that he does not want to spend more time on such issues, that there was no further response for four years and that noone else seems to have this problem, I think we should close this one.