为什么不能自动closures脚本标签？
浏览器不能正确识别的原因是什么？
<script src="foobar.js" /> <!-- self-closing script tag --> 只有这一点被认可：
<script src="foobar.js"></script>
这是否打破了XHTML支持的概念？
注意：至less对于所有的IE（6-8 beta 2）这个说法是正确的。
XHTML 1规范说：
С.3。 元素最小化和空元素内容
给定一个元素的内容模型不是
EMPTY的空实例（例如，一个空的标题或段落）不要使用最小化的forms（例如使用<p> </p>而不是<p />）。
XHTML DTD将脚本标记指定为：
<!-- script statements, which may include CDATA sections --> <!ELEMENT script (#PCDATA)>
为了增加Brad和Squadette所说的，自动closures的XML语法<script />实际上是正确的XML，但是为了在实践中正常工作，Web服务器还需要将文档作为正确形成的XML与XML mimetype像HTTP Content-Type头中的application/xhtml+xml （而不是 text/html ）。
但是，发送XML MIMEtypes将导致您的网页不被IE7parsing，IE7只喜欢text/html 。
从w3 ：
总之，'application / xhtml + xml'应该被用于XHTML系列文档，'text / html'的使用应该被限制在与HTML兼容的XHTML 1.0文档中。 'application / xml'和'text / xml'也可以使用，但是在适当的时候，应该使用'application / xhtml + xml'而不是那些通用的XML媒体types。
几个月前，我对此感到困惑，唯一可行的（与FF3 +和IE7兼容）解决scheme是使用text/html （HTML语法+ HTML mimetype）的旧的<script></script>语法。
如果你的服务器在它的HTTP头文件中发送了text/htmltypes，即使有其他格式正确的XHTML文档，FF3 +也将使用它的HTML呈现模式，这意味着<script />不能工作（这是一个变化，Firefox以前不那么严格）。
无论是否使用http-equiv元标记，文档中的XML prolog或doctype，都会发生这种情况 – 一旦获取到text/html标题，Firefox分支会确定HTML或XML分析器是否在文档中查找，而HTML分析器不理解<script /> 。
如果有人好奇，最终的原因是HTML最初是SGML的一种方言，这是XML的古怪的哥哥。 在SGML-land中，标签可以在DTD中指定为自闭（例如BR，HR，INPUT），隐式可closures（例如P，LI，TD）或显式可closures（例如TABLE，DIV，SCRIPT）。 XML当然没有这个概念。
现代浏览器使用的标签汤分析器是从这个传统中演化而来的，尽pipe他们的分析模型不再是单纯的SGML。 当然你的精心制作的XHTML被认为是写得不好的标签汤/ SGML，除非你用XML MIMEtypes发送它。 这也是为什么…
<p><div>hello</div></p>
…被浏览器解释为：
<p></p><div>hello</div><p></p>
…这是一个可爱的晦涩的错误的食谱，可以扔你适合，当你尝试对DOM的代码。
其他人回答“如何”和引用规范。 这是真正的故事“为什么没有<script/> ”，经过数小时挖掘错误报告和邮件列表。
HTML 4
HTML 4基于SGML 。
SGML有一些标签 ，例如<B>text</> ， <B/text/或<OL<LI>item</LI</OL> 。 XML采用第一种forms，将结尾重新定义为“>”（SGML是灵活的），以便它变成<BR/> 。
但是，HTML不会重定义，所以<SCRIPT/> 应该表示 <SCRIPT>> 。
（是的，“>”应该是内容的一部分，标签仍然没有closures。）
很明显，这与XHTML不兼容， 会打破许多网站（到浏览器足够成熟的时候关注 这个 ），所以没有人实施短标签和规范build议他们 。
实际上，所有“工作”自我结束的标签都是在技术上不符合标准的parsing器上带有可选结束标签的标签，实际上是无效的。 这是W3C 提出的这个黑客来帮助过渡到XHTML的HTML兼容 。
而<script>的结束标记不是可选的 。
“自我结束”标签是HTML 4中的一个黑客，并且毫无意义。
HTML 5
HTML5有五种types的标签 ，只允许“无效”和“外来”标签自动closures 。
因为<script>不是void（它可能有内容）而且不是外来的（像MathML或SVG），所以无论你如何使用它， <script>都不能自行closures。
但为什么？ 他们不能把它看作是外来的，做特例还是什么的？
HTML 5旨在向后兼容 HTML 4和XHTML 1的实现 。它不基于SGML或XML; 它的语法主要是关于logging和联合实现。 （这就是为什么<br/>虽然是无效的HTML4，但是<hr/>等是有效的HTML 5 ）。
自closures<script>是实现用于区别的标记之一。 它曾经在Chrome，Safari 和Opera中工作 ; 据我所知，它从来没有在Internet Explorer或Firefox的工作。
这是在HTML 5草案被讨论的时候被讨论过的 ，因为它破坏了 浏览器的 兼容性而被拒绝了。 自封闭脚本标记可能无法在旧浏览器中正确呈现（如果有的话）的网页。 还有其他的build议 ，但是也不能解决兼容性问题。
草稿发布后，WebKit更新了parsing器以符合要求。
由于与HTML 4和XHTML 1向后兼容，自闭<script>不会在HTML 5中发生。
XHTML 1 / XHTML 5
当真正用作XHTML时， <script/>真的是封闭的，正如其他答案所述。
除了规范说，它应该已经工作时，作为HTML：
XHTML文档…可以用Internet媒体types“text / html”[RFC2854]标记，因为它们与大多数HTML浏览器兼容。
所以发生了什么事？
人们要求Mozilla不pipe指定的内容头（称为内容嗅探 ）而让Firefox将符合的文档parsing为XHTML 。 这将允许自动closures脚本，并且无论如何，内容嗅探是必需的 ，因为networking托pipe人不够成熟，无法提供正确的标题; IE很擅长 。
如果第一个浏览器战争没有以IE 6结束，那么XHTML也可能已经在列表中。 但它确实结束了。 而IE 6 在 XHTML 方面有问题 。 实际上，IE 根本不支持正确的MIMEtypes，强制每个人都使用text/html作为XHTML，因为IE 在整个十年中占有重要的市场份额 。
内容嗅探可能 非常糟糕 ，人们说应该停止 。
最后，事实certificateW3C 并不意味着XHTML是可嗅探的 ：文档是HTML和XHTML，以及Content-Type规则。 可以说，他们坚持“遵循我们的规范”，而忽视了实际 。 一个延续到后来的XHTML版本的错误。
无论如何，这个决定为Firefox 解决了这个问题 。 Chrome 出生 7年前， 没有其他重要的浏览器。 因此决定。
由于以下规范，单独指定doctype不会触发XMLparsing。
Internet Explorer 8和更早版本不支持XHTMLparsing。 即使您使用XML声明和/或XHTML文档types，旧的IE仍然将文档parsing为纯HTML。 而在纯HTML中，不支持自闭合语法。 尾部斜线只是被忽略，你必须使用一个明确的结束标签。
即使支持XHTMLparsing的浏览器（如IE 9及更高版本 ）仍然会将该文档parsing为HTML，除非您使用XML内容types来提供文档。 但在这种情况下，旧的IE浏览器将不会显示文件！
上面的人已经解释了这个问题，但有一点可以弄清楚的是，尽pipe人们在HTML文档中一直使用“一”等，但是任何在这个位置上的“/”基本上都是忽略，只有在试图将可parsing为XML和HTML的东西时才使用。 例如，尝试'<p /> foo </ p>'，你会得到一个正常的段落。
自闭脚本标记将不起作用，因为脚本标记可以包含内联代码，并且HTML不够聪明，可以根据属性的存在打开或closures该function。
另一方面，HTML对包含对外部资源的引用有很好的标记：
<link>标记，它可以是自闭的。 它已经被用来包括样式表，RSS和Atom提要，规范的URI，以及各种其他的好东西。 为什么不是JavaScript？
如果你想脚本标记是自我封闭的，你不能像我说的那样做，但有一个select，但不是一个聪明的。 您可以使用自闭链接标记并链接到您的JavaScript，通过给它一个types的文本/ JavaScript和rel作为脚本，如下所示：
<link type="text/javascript" rel ="script" href="/path/tp/javascript" />
与XML和XHTML不同，HTML不知道自闭句法。 将XHTML解释为HTML的浏览器不知道/字符表示标签应该是自闭的; 而是将其解释为一个空属性，parsing器仍然认为该标签是“打开”的。
正如<script defer>被视为<script defer="defer"> ， <script />被视为<script /="/"> 。
Internet Explorer 8及更高版本不支持适用于XHTML的application/xhtml+xml MIMEtypes。 如果您将XHTML作为text/html ，您必须为这些旧版本的Internet Explorer执行任何操作，它将被解释为HTML 4.01。 您只能使用简短的语法与任何允许结束标记被省略的元素。 请参阅HTML 4.01规范 。
XML'short form'被解释为一个名为/的属性（因为没有等号）被解释为具有隐含的值“/”。 这在HTML 4.01中是严格错误的 – 不允许使用未声明的属性，但浏览器将忽略它。
IE9和更高版本支持XHTML 5与application/xhtml+xml 。
那是因为SCRIPT TAG不是一个VOIP元素。
在HTML文档中 – 无效元素根本不需要“结束标记”！
在xhtml中 ，一切都是通用的，因此它们都需要终止，例如“结束标签”。 包括br，一个简单的换行符，如<br />或者其简写 <br /> 。
但是，脚本元素永远不会是无效的或参数化的元素，因为脚本标签之前的标签是浏览器指令，而不是数据描述声明。
原则上，语义终止指令（例如，“结束标记”）仅用于处理指令，其语义不能被后续标记终止。 例如：
<H1>语义不能被后面的<P>终止，因为它没有足够的自己的语义来覆盖，因此终止了以前的H1指令集。 虽然它可以将stream分解成新的段落，但是它不足以覆盖现有的字体大小和样式行高度，即从H1泄漏（因为P没有它）。
这就是为什么“/”（终止）信号发明的原因。
像< />这样的通用的无描述终止标签，对于任何单一的脱离级联，例如： <H1>Title< />都是足够的，但事实并非总是如此，因为我们也希望能够“嵌套“，stream的多个中间标记：在包装/分解到另一个级联之前被分成多个stream。 因此，像< />这样的通用终止符将无法确定终止的属性的目标。 例如： <b> 粗体 <i> 粗体 <i> 斜体 < /> 斜体 </>正常。 毫无疑问，我们的意图是没有把握的，而且很可能会把它理解为一个大胆的大胆的正常的。
这就是包装的概念 ，即容器的诞生。 （这些概念是如此相似以至于不可能辨别，有时候相同的元素可能同时具有这两者。 <H1>既是包装又是容器，而<B>只是一个语义包装。 我们需要一个普通的，没有语义的容器。 当然，DIV元素的发明也来了。
DIV元素实际上是一个2BR容器。 当然，CSS的到来使得整个情况比其他情况更为怪异，并且间接地造成了很多重大后果的混乱。
因为用CSS你可以很容易地覆盖新发明的DIV的本地前后BR行为，它通常被称为“无所事事的容器”。 这是自然错误！ DIV是块元素，将在结束信号之前和之后在本地中断stream的行。 WEB不久就开始受到页面DIV-itis的困扰。 他们大多仍然是。
CSS的全面覆盖和彻底重新定义任何HTML标签的原生行为的能力，以某种方式设法混淆和模糊HTML存在的整体意义…
突然之间，所有的HTML标签都显得过时了，它们被污损，被剥夺了所有的原始意义，身份和目的。 不知怎的，你会得到他们不再需要的印象。 说：一个容器包装标签就足够了所有的数据表示。 只需添加所需的属性。 为什么不用有意义的标签呢？ 随时随地创build标签名称，并让其他CSS受到干扰。
这就是xhtml诞生的原因，当然也是很直接的，新来者付出如此高昂的代价，对于什么是什么都有扭曲的看法，这一切的目的是什么。 W3C从万维网去了哪里错了，同志们？
HTML的目的是将有意义的数据传输给人类接收者。
提供信息。
正式的部分只是帮助信息传递的清晰。 xhtml并没有丝毫考虑这些信息。 – 对此，信息是绝对不相干的。
在这件事上最重要的是知道并能够理解xhtml不只是一些扩展的HTML的版本 ，xhtml是一个完全不同的野兽; 地面 因此把它们分开是明智的做法。
