TYPO3 Core

Could you please State the Operational System and te IE Version?
Win2k SP3 IE6 makes no trouble
WinXP SP2 IE6 makes no trouble.

I didn't experience the problem, I was just filing this as a spin off of #14137, which is mainly about problems with the page tree.

It seems that some version of IE on some versions of Windows have problems with an XML declararion. Don't know which.

Anyway, it's not a big deal to use HTML. Of course it would be nice to have real infos on the problem, but the "fix" is cheap.

BTW, why did you make this bug a "feedback"?

because I wanted some feedback on this bug because I could not reproduce it on:

WinXP IE6
Win2k IE5.5
Win2k IE6
Win98 IE5
WInME IE 6
WInME IE5.5

Do we have anybody who can give detailed feedback?
Because this sounds more like a setup error than as a real bug to me.
Of course, we could easily change it to plain HTML if you wish ;-)

I don't know much about IE's troubles with typo3/border.html but I was getting a PHP parse error because I had Short Tags on AND I've opted to parse .html files as PHP. Because of the Short Tags option on in PHP it didn't like typo3/border.html misreading the nothing to do with the issues the reporter experienced with IE but I thought it's worth noting.

I wonder what the harm is in modifying the source to either a: be plain html as the reporter suggested (regardless of the problems this seems like a painless solution to several potential environmental problems) or b: support the echo method I suggested. I think my solution is actually weaker than the reporters so I would 'vote' for the plain-html downgrade of typo3/border.html. I'd like to see the source changed in some way to more closely reflect the environments out there. But maybe my short tags, parsing .html as php, and the reporters IE issues are in the minority.

I think the issue with IE might be a problem with the DOCTYPE and the before the and <!DOCTYPE...> will be reversed. This is needed for MSIE to be standards compliant with XHTML." (page 54). Perhaps the problem the reporter is seeing is related to this.

See http://www.w3.org/TR/xhtml1/#strict for more on the ordering and requirements of the not required to maintain XHTML status, btw, only if you need to declare a character encoding besides UTF-8 or UTF-16. Since the border.html file is declaring itself as UTF-8 the

I tried it in my browser of choice and it renders in Standards Compliance Mode and the W3C agrees (http://validator.w3.org/check?verbose=1&uri=http%3A//www-d.wwc.edu/typo3/border.html)

Not sure if I've been helpful, but perhaps that is the feedback you were loking for mathias.

Best wishes

edited on: 15.08.04 10:24

I second dodgly's comments on the cause of the problem, but the fact is: border.html does validate whereas /typo3 does not. With the xml prologue we can only either validate or support IE's crappy implementation.
One common way to solve this is to completely remove the xml prologue which was suggested by Wolfgang Klinger here: http://lists.netfielders.de/pipermail/typo3-dev/2004-March/002250.html
So, this here is not a bug, but the rest of the BE is not valid XHTML which we should do something about. My suggestion: Close this, and create a new bug: Make BE XHTML compliant. Any objections?

Just seen this issue with Typo 4.1 on IE 7 on XP SP2.
Removed the XML declaration and it was ok.

we want XHTML, IE sucks - we know that