浏览器无法正确识别的原因是什么:
<script src="foobar.js" /> <!-- self-closing script element -->
只有这一点是公认的:
<script src="foobar.js"></script>
这是否打破了XHTML支持的概念?
注意:此声明至少对所有IE(6-8 beta 2)都是正确的。
浏览器无法正确识别的原因是什么:
<script src="foobar.js" /> <!-- self-closing script element -->
只有这一点是公认的:
<script src="foobar.js"></script>
这是否打破了XHTML支持的概念?
注意:此声明至少对所有IE(6-8 beta 2)都是正确的。
当前回答
如果有人好奇的话,最终的原因是HTML最初是SGML的一种方言,而SGML是XML奇怪的哥哥。在SGML land中,元素可以在DTD中指定为自关闭(例如BR、HR、INPUT)、隐式可关闭(例如P、LI、TD)或显式可关闭的(例如TABLE、DIV、SCRIPT)。当然,XML对此没有概念。
现代浏览器使用的标签汤解析器是从这一传统演变而来的,尽管它们的解析模型不再是纯SGML。当然,除非您使用XML mime类型发送,否则精心制作的XHTML会被视为编写糟糕的SGML标签汤。这也是为什么。。。
<p><div>hello</div></p>
…被浏览器解释为:
<p></p><div>hello</div><p></p>
……这是一个可爱的、晦涩难懂的bug的配方,当您尝试对DOM进行编码时,它会让您陷入困境。
其他回答
XHTML 1规范的非规范性附录“HTML兼容性指南”指出:
С.3元素最小化和空元素含量
给定内容模型不是空的元素的空实例(例如,空标题或段落),不要使用最小化形式(例如,使用<p></p>而不是<p>)。
XHTML DTD将脚本元素指定为:
<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>
其他人回答了“如何”,并引用了规范。经过几个小时的研究,这里是“为什么不<script/>”的真实故事。
HTML 4
HTML4基于SGML。
SGML有一些短标记,例如<BR//、<B>text</>、<B/text/或<OL<LI>item</LI</OL>。XML采用第一种形式,将结尾重新定义为“>”(SGML是灵活的),因此它变成<BR/>。
然而,HTML并不是红色的,所以<SCRIPT/>应该意味着<SCRIPT>>。(是的,“>”应该是内容的一部分,标记仍然未关闭。)
显然,这与XHTML不兼容,并且会破坏许多网站(到浏览器成熟到可以考虑这一点时),因此没有人实现短标签,规范建议不要使用短标签。
实际上,所有“工作”的自结束标记都是在技术上不一致的解析器上带有禁止结束标记的标记,实际上是无效的。正是W3C想出了这个破解方法,通过使XHTML与HTML兼容来帮助过渡到XHTML。
<script>的结束标记不被禁止。
“Self-ending”标签是HTML4中的一个黑客,没有任何意义。
HTML 5
HTML5有五种类型的标记,只有“void”和“foreign”标记可以自动关闭。
因为<script>不是空的(它可能有内容),也不是外来的(像MathML或SVG),所以无论您如何使用<script>,它都不能自我关闭。
但为什么?难道他们不能把它看作是外国的吗?
HTML5旨在向后兼容HTML4和XHTML1的实现。它不是基于SGML或XML;它的语法主要涉及记录和合并实现。(这就是为什么<br/><hr/>等是有效的HTML5,而不是无效的HTML4。)
自我关闭<script>是过去实现不同的标记之一。它曾经在Chrome、Safari和Opera中运行;据我所知,它从未在Internet Explorer或Firefox中运行过。
这是在HTML5起草时讨论过的,因为它破坏了浏览器兼容性而被拒绝。在旧浏览器中,自关闭脚本标记的网页可能无法正确呈现(如果有的话)。还有其他建议,但它们也不能解决兼容性问题。
草案发布后,WebKit将解析器更新为一致。
由于向后兼容HTML4和XHTML1,HTML5中不会出现自动关闭<script>。
XHTML 1/XHTML 5
当真正用作XHTML时,<script/>实际上是关闭的,正如其他答案所述。
除了规范中说它应该在用作HTML时工作:
XHTML文档。。。可以标记为Internet媒体类型“text/html”[RFC2854],因为它们与大多数html浏览器兼容。
那么,发生了什么?
人们要求Mozilla允许Firefox将符合标准的文档解析为XHTML,而不考虑指定的内容头(称为内容嗅探)。这将允许自动关闭脚本,无论如何,内容嗅探都是必要的,因为web宿主还不够成熟,无法提供正确的标头;IE很擅长。
如果第一次浏览器大战没有以IE6结束,XHTML可能也在名单上。但它确实结束了。IE 6有XHTML的问题。事实上,IE根本不支持正确的MIME类型,迫使每个人都为XHTML使用text/html,因为IE占据了整整十年的主要市场份额。
此外,内容嗅探也可能非常糟糕,人们认为应该停止。
最后,事实证明,W3C并不意味着XHTML是可窥探的:文档既是HTML又是XHTML,以及内容类型规则。人们可以说,他们坚持“只遵循我们的规范”,而忽视了什么是实际的。这个错误一直延续到后来的XHTML版本。
无论如何,这个决定解决了Firefox的问题。Chrome诞生前7年;没有其他重要的浏览器。就这样决定了。
由于以下规范,单独指定doctype不会触发XML分析。
与XML和XHTML不同,HTML不了解自动关闭语法。将XHTML解释为HTML的浏览器不知道/字符表示标记应该是自动关闭的;相反,它们将其解释为一个空属性,解析器仍然认为标记是“打开的”。
正如<script defer>被视为<script defer=“defer”>一样,<script/>被视为<script/=“/”>。
除Brad和squadette所说的之外,自动关闭的XML语法<script/>实际上是正确的XML,但要使其在实践中发挥作用,web服务器还需要将文档作为格式正确的XML发送,并在HTTP Content Type标头中使用类似application/xhtml+XML的XML mimetype(而不是text/html)。
然而,发送XML mimetype将导致IE7无法解析页面,IE7只喜欢text/html。
来自w3:
总之,“application/xhtml+xml”应用于XHTML系列文档,以及“text/html”的使用应限于HTML兼容XHTML 1.0文档。'应用程序/xml'也可以使用“text/xml”,但是只要合适,应使用“application/xhtml+xml”而不是那些通用的XML媒体类型。
几个月前我对此感到困惑,唯一可行的(兼容FF3+和IE7)解决方案是使用旧的<script></script>语法和text/html(html语法+html mimetype)。
如果您的服务器在其HTTP头中发送text/html类型,即使是格式正确的XHTML文档,FF3+也将使用其html呈现模式,这意味着<script/>将无法工作(这是一个变化,Firefox以前没有那么严格)。
无论对文档中的http equiv元元素、XML序言或doctype进行任何篡改,都会发生这种情况——Firefox一旦获得text/html头,就会分支,这决定了html或XML解析器是否在文档中查找,而html解析器不理解<script/>。
Internet Explorer 8和更早版本不支持XHTML解析。即使使用XML声明和/或XHTML文档类型,旧IE仍然将文档解析为纯HTML。在纯HTML中,不支持自动关闭语法。尾部斜杠被忽略,您必须使用显式结束标记。
即使是支持XHTML解析的浏览器(如IE9和更高版本),也会将文档解析为HTML,除非您使用XML内容类型提供文档。但在这种情况下,旧IE根本不会显示文档!