为什么不能自动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是一个完全不同的野兽; 地面 因此把它们分开是明智的做法。