since IE won't render XHTML as XHTML, but treat it as HTML instead, when can this actually cause problems for IE?
+2
A:
i know of one case, where
<div style="clear:both" />
in browsers that support XHTML, the div is closed. But IE will treat the div as still open, so the layout can have unexpected result later.
動靜能量
2009-05-29 04:42:20
All browsers should do this when in rendering XHTML in HTML mode—self-closing tags are a feature of XML, not XHTML. This is why the HTML compatibility guidelines recommend that you do not use that form for elements that do not normally close themselves in HTML (like <img> and <br>): http://www.w3.org/TR/xhtml1/#C_3
Miles
2009-05-29 04:48:22
@Miles True. IIRC, in xHTML self-closing tags should be closed properly like this "<img />" - the space is optional but a failsafe for browsers that do not support the slash
Hannson
2009-05-29 04:53:57
+1
A:
Internet Explorer will have trouble distinguishing XHTML documents from XML documents if the MIME-type is not specified as text/html. However, because it fully supports HTML 4.01 the majority of problems arise from inconsistent and non-standards implementations of positioning, layout, and CSS properties. To avoid any problems it is best to write valid XHTML and specify a DOCTYPE.
Writing HTML avoids event more problems, since you don't get caught out with <foo /> issues.
David Dorward
2009-05-29 08:20:36
A:
These all apply to any browser treating XHTML as text/html rather than specifically IE, but you should read Appendix C of the XHTML 1.0 spec here: http://www.w3.org/TR/xhtml1/#guidelines
Alohci
2009-05-29 20:56:24
+1
A:
Self-closing syntax won't work (it will appear to work only on elements that are always empty in HTML). XML serializers might generate
<textarea/>,<script/>and similar, which break pages in various ways (triggering complicated error recovery, sometimes involving re-parsing of remainder of the page).Explicitly closed HTML "empty" elements might behave oddly (
</br>inserts break in IE).<![CDATA[outside HTML's hardcodedCDATAelements will be recognized as a tag. It won't affect escaping and might make some content disappear.In HTML's
CDATAelements (namely<script>) entities won't be recognized. XHTML requires<script> if (1 < 2) …which is going to be syntax error in IE.Background of
<body>will be applied differently in IE.There will be no cross-browser syntax for namespace-aware selectors in CSS.
You'll get all implied HTML elements (e.g.
<tbody>in all tables) and implictly closed elements (it's usually not a problem when document is valid, but other browsers won't warn you as long as markup is well-formed).Elements and attributes with prefixes won't be namespaced and will get different
tagNamein IE (which is also illegal in XML). They won't get appropriate default styling and behaviour either (<xhtml:a>can't be a link).You won't be able to use namespace-aware methods like
createElementNS(they don't exist in IE),.tagNamewill be uppercase in IE, but not in all cases.Elements and attributes with prefixes won't be namespaced and will get different local name in IE (which is also illegal in XML).
These are only problems concerning switching from working XML document to HTML. There are as many surprises when you're going from HTML (i.e. what everyone expects and takes as normal behavior) to real XML, e.g. document.write doesn't work rendering most of Google's scripts useless.
porneL
2010-01-03 23:32:07