How awful is that, after an hour of hunting and pecking, I figured I might as well contribute to the world the awful truth that the only reason your javascript failed to work in IE is because you thought you could pull a fast one on it and use your fancy xHTML shortcut.
I've read the dtd and I can't really find any basis for IE being so persnickity.
You're not using xhtml, you're using html, and html does not support the self closing tag syntax of xml -- in html using the self closing tag syntax will result in an attribute '/' being place on the element, not in closing the tag.
Now depending on the context of the <script> tag the browsers will typically correct this, so you're in effect relying on the browsers autocorrection to make everything work properly.
Is IE the only web browser that requires <script></script> and hates <script/>?
No, all current browsers behave the same when being served XHTML as text/html. There is only a difference between browsers unless you are sniffing for IE and sending it a different Content-Type to other browsers. (Top tip: don't do that. There is nothing to gain and plenty of weirdness to get bitten by.)
The empty element syntax is not understood as anything special by HTML browsers, it is only there to paper the cracks between HTML's unclosed elements and XHTML's empty elements. So you can't ever use one as a ‘shortcut’; empty elements can-only-and-must be used for empty elements, as specified in the XHTML Appendix C guidelines.
You can verify this as simply as:
<p style="color: red" />html
All browsers I have tested colour ‘html’ in red.
XHTML 1 specification says:
С.3. Element Minimization and Empty Element Content
Given an empty instance of an element whose content model is not EMPTY (for example, an empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).
XHTML DTD specifies script tags as:
<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
Hope it helps,
This is from : Why don't self-closing script tags work?
While the answer marked "correct" in Andrew Clark's linked question is technically correct, the other browsers (which support XHTML sent as application/xhtml+xml) treat anything that's sent as text/html (even with an XHTML doctype) as HTML. In the case of tags that are unclosed in HTML (eg <img>), the parser (correctly) treats self-closed tags (eg <img />) as a syntax error, and ignore the slash. In the case of <script> tags, which are meant to be closed in HTML (text/html), the parser simply does not find the close tag, and treats the following content as part of the script.
See: http://webkit.org/blog/68/understanding-html-xml-and-xhtml/
(Or if the server is flaky for you like it is for me, here's the Google cache: http://209.85.173.132/search?q=cache:WFDCo2hoRnAJ:webkit.org/blog/68/understanding-html-xml-and-xhtml/+script+tag+surfin-safari&hl=en&client=safari&gl=us&strip=1)
You do not want to be constantly testing these waters, because you are depending on the browser coders to imagine your creativity in advance.
You are depending too much on the target browser to auto-translate. I see similar code in View Source all the time, where extra "/" are red-lined by Firefox, but they happen to be in places where the HTML parser allowed it.
Having worked for a browser vendor, I can tell you that many of the weird-little-things-that-happen-to-work were (reluctantly) added because a situation required the support of something weird and incorrect. Each of these funny cases adds bloat, increases the testing requirements, and is avoided by developers whenever possible.
