Problem
What is the cause of browsers’ failure to recognize:
<script src="foobar.js" /> <!-- self-closing script element -->
Only this is acknowledged:
<script src="foobar.js"></script>
Is this a violation of the XHTML support concept?
Note: This statement is true for all Internet Explorer versions (6-8 beta 2).
Asked by dimarzionist
Solution #1
According to the XHTML 1 specification:
C.3: Element Minimization and the Content of Empty Elements
The XHTML DTD defines script elements as follows:
<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
Answered by squadette
Solution #2
To add to what Brad and squadette have mentioned, the self-closing XML syntax script /> is correct XML, but it won’t work until your web server sends your documents as properly formed XML with an XML mimetype like application/xhtml+xml in the HTTP Content-Type header (rather than text/html).
Sending an XML mimetype, on the other hand, will prevent your sites from being parsed by IE7, which only accepts text/html.
From w3:
I was stumped a few months back, and the only approach that worked (and was compatible with FF3+ and IE7) was to utilize the old Script>/Script> syntax with text/html (HTML syntax + HTML mimetype).
Even with otherwise properly structured XHTML documents, if your server delivers the text/html type in its HTTP headers, FF3+ will utilize its HTML rendering mode, which implies that script /> will not work (this is a change, Firefox was previously less strict).
Regardless of whether you fiddle with http-equiv meta elements, the XML prolog, or the doctype inside your page, Firefox branches once it receives the text/html header, which decides whether the HTML or XML parser searches inside the content, and the HTML parser does not understand script />.
Answered by joelhardi
Solution #3
Others have responded with “how” and speculative examples. After many hours of digging through bug reports and email lists, this is the true explanation of “why no script/>.”
HTML 4
SGML is the foundation of HTML 4.
Some SGML shorttags include BR/, B>text/>, B/text/, and OLLI>item/LI/OL>. XML takes the first form and replaces the ending with “>” (SGML is flexible), resulting in BR/>.
However, because HTML did not redfine, SCRIPT/> should be interpreted as SCRIPT>>. (Yes, the tag is still open, and the ‘>’ should be part of the text.)
Obviously, this is incompatible with XHTML and will ruin many sites (by the time browsers were mature enough to care), thus no one used shorttags, and the specification discourages them.
Effectively, all ‘functioning’ self-ended tags on technically non-conformant parsers are tags with a forbidden end tag and are thus invalid. The W3C devised this hack to aid in the transition to XHTML by making it HTML-compatible.
The end tag of a script is also not disallowed.
The “self-ending” tag in HTML 4 is a hack that has no meaning.
HTML 5
Only the ‘void’ and ‘foreign’ tags are allowed to be self-closing in HTML5, and only the ‘void’ and ‘foreign’ tags are allowed to be self-closing.
Script> cannot be self-closed, regardless of how you use it, because it is not void (it may include content) and is not foreign (like MathML or SVG).
But why is that? Isn’t it possible for them to treat it as alien, to make an exception, or to do something else?
HTML 5 seeks to be backwards compatible with HTML 4 and XHTML 1 implementations. Its syntax is primarily focused with documenting and uniting implementations, and it is not based on SGML or XML. (This is why br/>, hr/>, and other HTML 5 elements are legal despite being invalid HTML 4.)
Self-closing