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
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by