在以下代码段中,<在Firefox 37.0.2中按预期呈现,我在许多其他现代浏览器中也看到过相同的内容。这个textarea规范是否有效HTML5?理想情况下,它不应该是& lt;通过逃避"<"
<html>
<textarea>
Hello World <
</textarea>
</html>
HTML解析器如何区分标记打开和&#34;&lt;&#34;?大多数浏览器通过猜测自动处理错误,这是一个这样的情况吗?
我对此感兴趣的原因是因为当我们在Web Apps中使用WYSIWYG编辑器时 - 我们主要从编辑器源中保存HTML。当我们将它模板回到前端时,这种行为使得后端的HTML引用不是强制性的。它可以在没有HTML Quoting的情况下工作,但它可能导致不希望的效果,例如冻结/无限循环至少与TinyMCE编辑器的3.5.8版本。
答案 0 :(得分:4)
这确实只是在猜测。在HTML中使用文字<
的正确方法是使用<
(和>
>
)。
也就是说,textarea
有点具体,因为它永远不能包含任何其他HTML元素 - 因此解析器可以确定你是文字<
而不是起始标记。当然,它会导致</textarea>
:)
来自HTML 4规范:
第5.3.2节:
作者希望将&#34;&lt;&#34;文字中的字符应使用&#34;&lt;&#34; (ASCII十进制60)以避免可能与标记的开头混淆(开始标记打开分隔符)。同样,作者应该使用&#34;&gt;&#34; (ASCII十进制62)在文本而不是&#34;&gt;&#34;避免旧的用户代理在出现在带引号的属性值中时错误地将其视为标记结尾(标记关闭分隔符)的问题。
因此,HTML 4并非必要,但它仍然是不错的做法。当然,XHTML和/或HTML 5可能会更加严格。
HTML规范在很多方面实际上都是非特定的,这对于确保浏览器(或多或少)微妙的方式彼此不兼容有很大帮助。最好的办法是不要依赖HTML 允许的所有内容,而只能依赖那些非常明确和具体的内容。原因很简单 - 两个浏览器可以100%完全符合HTML规范,并且仍然以完全无用的方式处理相同的HTML。
答案 1 :(得分:2)
如果没有深入了解实际代码,很难说,但是当遇到开始标记时,常见的HTML解析器会尝试找到结束标记。
与元素不相似的所有字符都被打印出来,好像它们被转义一样如果你幸运的话 这对于只允许文本的元素来说肯定是正确的,例如<textarea>
in你的样本。
这不是有效的HTML,显然应该避免使用。
答案 2 :(得分:2)
Mozilla HTML解析器将忽略任何“小于”角括号,而不会立即由有效标记类型继承。 任何空格字符(空格,制表符,换行符等)都会使括号“不是标记”。 textarea中的任何内容也只能是文本。
答案 3 :(得分:1)
无论有效性如何,HTML5规范都完全定义了精确的解析规则。
当树构建规则遇到<textarea>
标记时,令牌生成器会切换到RCDATA state
在该状态下,如果令牌系统遇到<
字符,则会切换到RCDATA less-than sign state
在该状态下,除非下一个字符是/
,否则它会将<
简称为<
并继续。否则,令牌器切换到RCDATA end tag open state
依此类推,其目的是允许解析器检测</textarea>
标记,但将其他所有内容作为文本传递。
没有&#34;猜测&#34;所涉及的,以及所有现代浏览器,包括IE,因为IE10遵循这些规则。