(X)HTML 中未定义的行为?

发布于 2024-10-17 21:46:56 字数 903 浏览 7 评论 0原文

(X)HTML 中是否存在未定义行为之类的事情?

在使用

但我注意到也可以使用 标签。完整示例:

<button>
    normal text
    <b>bold text</b>
    <a href="http://www.example.com/">linked text</a>
</button>

在 Firefox 上呈现如下:

在 Google Chrome 中:

现在,在 Firefox 上,链接目标不可可点击,只能点击按钮...但是,在 Chrome 上,链接可点击,并将重定向到 IANA RFC2606 页面

这是未定义的行为吗? (X)HTML 中是否还有更多可以被描述为未定义行为的情况?

Is there such a thing as undefined behaviour in (X)HTML?

I have wondered this after playing around with the <button> tag, which allows HTML to be rendered as button. Nothing new so far...

But I noticed that one can also use the <a> tag. Complete example:

<button>
    normal text
    <b>bold text</b>
    <a href="http://www.example.com/">linked text</a>
</button>

This is rendered as following on Firefox:

And in Google Chrome:

Now, On firefox, the link target is NOT clickable, only the button... However, on Chrome, the link is clickable, and will redirect to the IANA RFC2606 Page.

Is this undefined behaviour? Are there more cases in (X)HTML that could be described as undefined behaviour?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

尤怨 2024-10-24 21:46:56

它比仅检查 Yi Jiang 给出的 DTD 更复杂一点mu 太短

确实,XHTML 1.0 DTD 明确禁止 元素作为问题中给出的

XHTML 1.0也

<button>
    normal text
    <b>bold text</b>
    <span><a href="http://www.example.com/">linked text</a></span>
</button>

符合 Strict DTD。但 Firefox 和 Chrome 之间的行为差​​异与问题中的按钮片段相同。

现在,我们知道 DTD 在描述后代关系的限制方面存在问题,因此上述示例符合 DTD 也就不足为奇了。

然而。 XHTML 1.0 规范的附录 B 除了以下之外还规范地描述了后代限制DTD。它说:

以下元素有
禁止哪些元素
可以包含(请参阅 SGML 排除)。
该禁令适用于所有深度
嵌套,即它包含所有
后代元素。

按钮
不得包含输入、选择、文本区域、标签、按钮、表单、
fieldset、iframe 或 isindex 元素。

请注意,它包含 元素的排除。因此,XHTML 1.0 似乎并不禁止 元素成为

这种遗漏几乎肯定是一个错误。 元素应该位于附录 B 中禁止作为按钮后代的元素列表中。

HTML5(包括 XHTML5)在这个问题上更加彻底。它说:

4.10.8 按钮元素

内容模型:
措辞内容,但不得有交互式内容后代。

其中 交互式内容 定义为

交互式内容是指
专为用户设计
互动。

  • 一个
  • audio(如果存在 controls 属性)
  • 按钮
  • 详细信息
  • 嵌入
  • iframe
  • img(如果存在 usemap 属性)
  • input(如果type属性未处于Hidden状态)
  • 注册机
  • 标签
  • menu(如果type属性处于toolbar状态)
  • object(如果存在 usemap 属性)
  • 选择
  • 文本区域
  • video(如果存在 controls 属性)

因此在 (X)HTML5 中 元素禁止成为

It's a little more complex than just inspecting the DTD as given by Yi Jiang and mu is too short.

It's true that the XHTML 1.0 DTDs explicitly forbid <a> elements as children of <button> elements as given in your question. However it does not forbid <a> elements as descendants of <button> elements.

So

<button>
    normal text
    <b>bold text</b>
    <span><a href="http://www.example.com/">linked text</a></span>
</button>

is XHTML 1.0 Strict DTD conforming. But it has the same behavioural difference between Firefox and Chrome as the button fragment in the question.

Now, it is known that DTDs have problems describing limitations on descendant relationships, so it's maybe not surprising that the above sample is DTD conforming.

However. Appendix B of the XHTML 1.0 spec normatively describes descendant limitations in addition to the DTD. It says:

The following elements have
prohibitions on which elements they
can contain (see SGML Exclusions).
This prohibition applies to all depths
of nesting, i.e. it contains all the
descendant elements.

button
must not contain the input, select, textarea, label, button, form,
fieldset, iframe or isindex elements.

Note that it does not contain an exclusion for the <a> element. So it seems that XHTML 1.0 does not prohibit the <a> element from being non-child descendant of <button> and the behaviour in this case is indeed undefined.

This omission is almost certainly a mistake. The <a> element should have been in the list of elements prohibited as descendants of button in Appendix B.

HTML5 (including XHTML5) is much more thorough on the matter. It says:

4.10.8 The button element

Content model:
Phrasing content, but there must be no interactive content descendant.

where interactive content is defined as

Interactive content is content that is
specifically intended for user
interaction.

  • a
  • audio (if the controls attribute is present)
  • button
  • details
  • embed
  • iframe
  • img (if the usemap attribute is present)
  • input (if the type attribute is not in the Hidden state)
  • keygen
  • label
  • menu (if the type attribute is in the toolbar state)
  • object (if the usemap attribute is present)
  • select
  • textarea
  • video (if the controls attribute is present)

So in (X)HTML5 the <a> element is prohibited from being a descendant of the <button> element.

谎言月老 2024-10-24 21:46:56

HTML 4 规范 声明了

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- push button -->

如果我对 DTD 的阅读是正确的(而且我对此并不完全熟悉), 元素被明确禁止嵌套在 button 中,因此您看到的是无效的 HTML,因此这是未定义的行为。

The HTML 4 specifications declares the <button> as such:

<!ELEMENT BUTTON - -
     (%flow;)* -(A|%formctrl;|FORM|FIELDSET)
     -- push button -->

Which, if my reading of the DTD is correct (and I'm not exactly familiar with this), <a> elements are explicitly forbidden from being nested in buttons, so what you're looking at there is invalid HTML, and therefore it is undefined behavior.

山人契 2024-10-24 21:46:56

XHTML 说的是关于

<!-- button uses %Flow; but excludes a, form and form controls -->
<!ENTITY % button.content
   "(#PCDATA | p | %heading; | div | %lists; | %blocktext; |
    table | %special; | %fontstyle; | %phrase; | %misc;)*">

因此 也明确从 XHTML 中排除。

XHTML says this about <button>:

<!-- button uses %Flow; but excludes a, form and form controls -->
<!ENTITY % button.content
   "(#PCDATA | p | %heading; | div | %lists; | %blocktext; |
    table | %special; | %fontstyle; | %phrase; | %misc;)*">

So <a> is explicitly excluded from XHTML as well. The allowable elements inside <button> appear to be pretty much the same in XHTML-1.0 as in HTML-4.0.

各自安好 2024-10-24 21:46:56

添加到 Alohci 的好答案,但更具体地回答这个问题:如果您的 (X)HTML 无效,则行为始终根据定义,未定义。在这种情况下,浏览器可以随意解释标记(或者任何可能的情况),甚至可以拒绝它(真正的浏览器不会这样做)。

这正是标签汤引入的问题,也是 XML 严格解析规则和 HTML5 规范发展到超过 500 个页面的起源。

To add to Alohci's good answer, but more specifically to answer the question: If your (X)HTML is invalid, behaviour is always, per definitionem, undefined. In this case, browsers are free to interpret the markup as they like (or whatever chance will make out of it), or even to reject it (what no real browser does).

This is exactly the problem that the tag soup introduced and that was the origin of XML's strict parsing rules and the HTML5 spec growing to >500 pages.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文