浏览器无法正确识别的原因是什么:
<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文档中使用<br/>等,但这种位置上的任何/基本上都被忽略了,只有在试图使某种东西既可解析为XML又可解析为HTML时才使用。例如,尝试<p/>foo</p>,就会得到一个常规段落。
其他回答
除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根本不会显示文档!
自动关闭的脚本标记不起作用,因为脚本标记可以包含内联代码,而HTML不够聪明,无法根据属性的存在来启用或禁用该功能。
另一方面,HTML确实有一个很好的标记,用于包括对外部资源的引用:<link>标记,它可以是自动关闭。它已经用于包括样式表、RSS和Atom提要、规范URI和其他各种好东西。为什么不呢?JavaScript?
如果你想让脚本标签是自我封闭的,你不能像我所说的那样做,但有一个替代方案,尽管不是一个聪明的方案。您可以使用自动关闭的链接标记,并通过为其提供一种text/JavaScript和rel as脚本来链接到JavaScript,如下所示:
<link type="text/javascript" rel ="script" href="/path/tp/javascript" />
与XML和XHTML不同,HTML不了解自动关闭语法。将XHTML解释为HTML的浏览器不知道/字符表示标记应该是自动关闭的;相反,它们将其解释为一个空属性,解析器仍然认为标记是“打开的”。
正如<script defer>被视为<script defer=“defer”>一样,<script/>被视为<script/=“/”>。
这是因为脚本标签不是无效元素。
在HTML文档中,VOID ELEMENTS根本不需要“结束标记”!
在xhtml中,所有内容都是通用的,因此它们都需要终止,例如“结束标记”;包括br,一个简单的换行符,如<br></br>或其简写<br/>。
然而,脚本元素永远不是空元素或参数元素,因为脚本标记先于其他元素,是浏览器指令,而不是数据描述声明。
原则上,语义终止指令(例如,“结束标记”)仅用于处理语义不能被后续标记终止的指令。例如:
<H1>语义不能被后面的<P>终止,因为它没有足够的自身语义来覆盖并因此终止前面的H1指令集。虽然它可以将流拆分为新的段落行,但它“不够强大”,无法覆盖当前的字体大小和样式行高度,即从H1泄漏(因为P没有)。
这就是为什么发明了“/”(终止)信令。
一个通用的无描述终止标记,如</>,对于遇到的级联中的任何一次跌落都是足够的,例如:<H1>标题</>,但情况并非总是这样,因为我们还希望能够“嵌套”流的多个中间标记:在包装/跌落到另一个级联之前拆分成种子。因此,像</>这样的通用终止符将无法确定要终止的属性的目标。例如:<b>bold<i>bold italic</>italic</>normal。毫无疑问,我们无法正确理解我们的意图,很可能会将其解释为大胆的大胆的意大利大胆的正常。
包装器即容器的概念就是这样诞生的。(这些概念非常相似,以至于无法识别,有时同一个元素可能同时具有这两者。<H1>同时是包装器和容器。而<B>只是一个语义包装器)。我们需要一个简单、无语义的容器。当然,DIV元素的发明也随之而来。
DIV元素实际上是一个2BR容器。当然,CSS的出现使整个情况变得更加奇怪,并造成了巨大的混乱和许多巨大的后果——间接的!
因为使用CSS,您可以很容易地覆盖新发明的DIV的本机前置和后置BR行为,所以它通常被称为“不做任何事情的容器”。这自然是错误的!DIV是块元素,并且在结束信令之前和之后都会本地中断流的线路。很快,WEB开始遭受页面DIV的困扰。他们中的大多数人仍然如此。
随着CSS的出现,它能够完全覆盖并完全重新定义任何HTML标记的本地行为,不知何故,它混淆并模糊了HTML存在的全部含义。。。
突然间,所有HTML标记都显得过时了,它们被污损了,失去了所有的原始含义、身份和用途。不知怎么的,你会觉得他们不再需要了。说:一个容器包装标签就可以满足所有数据表示。只需添加所需的属性。为什么不使用有意义的标签;边走边发明标签名,让CSS来处理剩下的。
这就是xhtml是如何诞生的,当然也是伟大的直言不讳,新来者付出了如此高昂的代价,对什么是什么以及这一切的该死的目的有着扭曲的看法。W3C从万维网变成了什么出了问题,同志们?!!
HTML的目的是将有意义的数据流传输给人类接收者。
传递信息。
正式部分只是为了帮助信息传递的清晰。xhtml丝毫没有考虑信息。-对它来说,这些信息是绝对无关的。
最重要的是要知道并能够理解xhtml不仅仅是某些扩展HTML的一个版本,xhtml是一个完全不同的野兽;磨碎;因此,将它们分开是明智的。