HTML行为属于HTML

|

当您单击下面的按钮时，它会向您弹出一条消息。

当用户点击按钮时弹出一个窗口，这不是按钮本身所能支持的，您必须对其进行编码。有两种方法可以将自定义功能附加到 HTML 元素上：内联或使用事件监听器。

这是使用内联处理程序的方式：

<button onclick="alert('I was clicked!')">Click me</button>

这就是使用事件侦听器的方式：

<button>Click me</button>

<script>
const btn = document.querySelector("button")

btn.addEventListener("click", () => {
  alert('I was clicked!')
})
</script>

如果您以前从未考虑过这一点，您可能会做出反应：第一个示例（内联）似乎更好。它占用的空间要小得多，并将所有相关信息放在按钮上。可专家称，事实并非如此。MDN Web Docs 有这样的说法使用内联事件处理程序：

你可以找到许多事件处理器属性的 HTML 属性的等价表示；但是，你不应该使用这些属性——它们被认为是不好的做法。如果你正在做一些非常快速的事情，使用事件处理器属性可能看起来很容易，但它们很快就会变得无法管理和低效。

或者，如果这还不够清楚：

你永远不应该使用 HTML 事件处理器属性——那些已经过时了，使用它们是不好的做法。

在我看来，这是完全错误的。在这一点上，新手们是对的。MDN 是一个巨大的资源，我理解他们推荐第二种形式的原因，但要恢复 HTML 的全部功能并用它构建持久的应用程序，与这种特殊的意识形态作斗争至关重要。我来解释一下。

<form>和function

MDN 不希望你使用内联事件处理程序，因为它们不希望你混合表单 （HTML）和函数 （JS）。这是一个编程原理，称为 分离关注点 和HTML/CSS/JS split 就是一个教科书式的例子。来自维基百科（在撰写本文时）：

HTML主要用于组织网页内容，CSS用于定义内容呈现风格，JS 定义内容如何与用户交互和行为。

分离关注点是一个伟大的原则，但我认为这个原则划错了地方。在这种网页概念中，HTML 本质上是一个脚手架，你可以用 CSS（样式）和 JS（交互性）来装饰它。但 HTML 本身也具有交互性。它的交互性足以支持价值数十亿美元的业务，而不需要一行 JavaScript。

比方说，您想设置一个文本框和一个搜索按钮，以便人们可以搜索网页。首先，您需要为文本框设置一个 <input type=text>，为搜索设置一个 <button>。

<div>
  <input type=text name=q>
  <button>Search</button>
</div>

在页面上，它看起来像这样：


这个按钮没有任何作用，文本也不知道到哪里去了。但如果将 <div> 替换为 <form>，就像这样：

<form method=/search action=GET>
  <input type=text name=q>
  <button>Search</button>
</form>

然后点击按钮将输入内容作为查询提交，并导航到结果。因此，如果您在 https://example.com 上，而文本框里有猫，点击提交就会导航到 https://example.com/search?q=cats。在很长一段时间里，谷歌主页都是这样工作的。

HTML 完全定义了这一功能。当你点击按钮时，页面会进行一些交互操作–利用你的输入进行网络请求，而不涉及 JavaScript。它易于阅读，符合语义，并能在所有网络浏览器中永久运行。最重要的是，它证明了 “HTML 定义布局，JS 定义功能 “的整个概念在定义上是错误的。

增强语义

这样做的问题是，HTML 的功能非常有限，要增强这些功能，我们需要 JavaScript。表单验证就是一个很好的例子。此表格与上一个表格非常相似，只是现在它要求至少 8 个字符电子邮件地址：

<form>
  <input type="email" id="mail" name="mail" required minlength="8" />
  <button>Submit</button>
</form>

这也算是完成了任务。它可以防止用户提交太短或看起来不像电子邮件的内容，但不能让你自定义如何告知用户电子邮件地址的要求。这个表单是从 MDN 的表单验证页面改编而来的，演示了如何做到这一点：

<form novalidate>
  <input type="email" id="mail" name="mail" required minlength="8" />
  <span class="error" aria-live="polite"></span>
  <button>Submit</button>
</form>

现在有一个 <span>，一开始是空的，但如果电子邮件无效，就会填充一条错误信息。表单上还有一个 novalidate 属性，它告诉浏览器不要进行 HTML 内置的验证，因为我们将在 JavaScript 中完成所有验证。下面的 JavaScript 决定了信息的内容，并将其添加到 span 中。

const form = document.querySelector("form");
const email = document.getElementById("mail");
const emailError = document.querySelector("#mail + span.error");

email.addEventListener("input", (event) => {

  if (email.validity.valid) {
    emailError.textContent = "";
    emailError.className = "error";
  } else {
    showError();
  }
});

form.addEventListener("submit", (event) => {
  if (!email.validity.valid) {
    showError();
    event.preventDefault();
  }
});

function showError() {
  if (email.validity.valueMissing) {
    emailError.textContent = "You need to enter an email address.";
  } else if (email.validity.typeMismatch) {
    emailError.textContent = "Entered value needs to be an email address.";
  } else if (email.validity.tooShort) {
    emailError.textContent = `Email should be at least ${email.minLength} characters; you entered ${email.value.length}.`;
  }

  emailError.className = "error active";
}

该代码增强了 HTML，使其执行以下操作：

  • 如果用户提交了无效的电子邮件，请向他们显示错误消息
  • 如果电子邮件为空，请显示“您需要输入电子邮件地址”。
  • 如果电子邮件太短，请显示“电子邮件应至少为 8 个字符;你输入了 X“（其中 X
    是他们输入的字符数）
  • 如果电子邮件不是电子邮件，则显示“输入的值必须是电子邮件地址”。
  • 当用户开始键入时，删除错误消息

所有这些内容都没有内置在 HTML 中，因此必须用 JavaScript 来编写。大量的 JavaScript。但如果是这样呢？假设一下，你可以在 HTML 中设计以下界面：

<form>
  <input type="email"
         name="mail"
         required
         minlength="8"
         message-target="#email-error"
         value-missing-message="You need to enter an email address."
         type-mismatch-message="Entered value needs to be an email address."
         too-short-message="Email should be at least ${email.minLength} characters; you entered ${email.value.length}."
  >
  <span id=email-error></span>
  <button>Submit</button>
</form>

您不是在 JavaScript 中添加新消息，而是将它们写在输入本身上。那更好，因为
有几个原因：

  • 代码清晰易读。“输入太短”消息在哪里定义？在 too-short-messsage中。
  • 这种行为是局部的。我们不可能不知道有人修改了信息，也不可能不知道是在哪里修改的。
  • 该逻辑可以在不同的输入上轻松重用
  • 该接口会自动实现适合验证消息的aria-live设计模式

从某种意义上说，这些优点都是一样的：它们赋予 HTML 更丰富的语义。

希望你正在为此对着电脑屏幕嚎啕大哭。”你什么都没解决！进行验证是件复杂的事，而你只是通过设计一个完美的界面，用魔法将它化解了”。没错。没错。这就是界面应该做的。有了更好的语义，程序员就可以描述元素的作用，其他人就可以替他们处理细节问题。

但如果我们开始编写 JavaScript 库来丰富 HTML 的语义，而不是取而代之，那么我们可能会从两者中获得更多好处。

请记住，在现阶段，我所使用的自定义语义仍然纯粹是理论性的。我们稍后将讨论前向兼容性、数据属性和所有细节问题。我们的首要任务是承认，作为一种超文本标记语言，HTML 本身就具有功能性：”超 “表示我们添加到文本中的所有额外功能，如链接和表单。要为 HTML 构建良好的界面，就必须认真对待 HTML。

一旦我们做到了这一点，接下来的任务就是想出最好的办法，用我们自己的语义来增强其有限的语义。这一部分很难。

回到现实

好的，那么如果我们想丰富 HTML 的语义，正确的方法是什么？

这里的主要问题是，HTML 既是一种有生命力的标准，也是一种无情的向后兼容标准（有史以来第一个网站至今仍在运行，并能在现代网络浏览器上完美显示，这是一项了不起的成就）。因此，如果我在输入元素中添加了 too-short-messsage 属性，而几年后 WHATWG 又添加了一个新的 too-short-messsage 属性，那么网页就会以意想不到的方式出现问题。

Microformats是一个非常古老的标准，如今仍在使用，其中最著名的可能是作为 Webmentions 规范的一部分。微格式让你可以在类声明中添加属性，就像下面这样：

<a class="p-name u-url" href="https://alexpetros.com">Alex Petros</a>

解析网页的东西会知道，这个链接不是一个随机链接，而是一个以我的名字为文本（p-name）、以那个人的主页为 URL（u-url）的链接。这很有趣，但非常有限。你无法使用这样的类名实现自定义信息。

HTML 通过为自定义属性保留 data- 前缀来解决这个问题。这样做效果很好，一些自定义属性库（如 Turbo）也接受了这一做法。就拿他们文档中的这个例子来说，它使用 data-turbo-method 属性将链接的方法从 GET 改为 DELETE（我并不保证你是否应该这么做）：

<a href="/articles/54" data-turbo-method="delete">Delete the article</a>

好用！它永远不会被 HTML 标准的未来更新所覆盖。如果你想用这种方式编写你的整个属性库，你可以这样做。

如果我听起来有点矛盾，那是因为我认为 data-* 属性的一切，从它们的名称到人们使用的例子，都表明它们是用来存储数据而不是行为的。当然，你也可以直接用它来扩展 HTML，但它的名字和冗长的语法确实让人不愿意用它来构建语义。如果你说数据属性是用于 “应与特定元素相关联的数据，但不必具有任何定义的含义”，那么人们就会这样使用它们。

我们之所以知道这是真的，是因为一些非常流行的 JavaScript 库完全摒弃了 data- 属性，而只是添加了带有前缀的自定义属性，而这些属性不太可能被添加到 HTML 中。经典的 AngularJS 使用 ng-，这种前缀如今仍在互联网上随处可见；Alpine.js 使用 x- 作为其 15 个自定义属性的前缀；htmx 也使用 hx-（不过 AngularJS 和 htmx 都支持在前缀前加上 data-，这只是为了方便迂腐的人使用）。

浏览器早已非正式地支持这一功能，而且效果也很好。下面是一个使用 Alpine.js 来切换任意属性的按钮：

<button x-on:click="open = ! open">Toggle</button>

在我看来，这是一个正确的总体思路，尽管我（主观上）不喜欢它的几乎所有内容。我觉得 open = ! open 有点奇怪（我猜它是一个全局变量吧？），用 x- 命名空间仍然是一个小麻烦，总的来说，它偏离了 HTML 的语义，我不喜欢这种方式。可以肯定的是，WHATWG 不会添加 x-on:click，但在撰写本文时也不能保证。

自定义属性（仍然）是一种方式

2009 年，在 HTML5 规范制定过程中，John Allsop 在他的博客 “HTML 5 中的语义 “中提倡认真对待自定义属性的可能性。

HTML 5 应采用大量新属性，而不是新元素。每个属性都与语义的类别或类型有关。例如，正如我在另一篇文章中详述的，HTML 包括结构语义、修辞语义、角色语义（从 XHTML 中采用）以及其他类别或类别的语义。

这些新属性的使用方法与类属性的使用方法类似：将描述元素性质的语义附加到元素上，或添加有关元素的元数据。

他举了几个例子，比如在一个段落中标注 “具有讽刺意味”（我原以为这是个可笑的例子，直到我想起人们其实一直在非正式地用”/s “之类的东西这样做）：

<p rhetoric="irony">He’s a fantastic person.</p>

或者这个可以让你以机器可理解的格式指定时间的元素（后来通过引入 

<span equivalent=“2009-05-01”>May Day next year</span>

这是一条正确的道路。这件事说明了它是什么，并以最适合人类阅读的方式指定了机器可解析的语义（虽然 “等价 “在这种情况下是一个糟糕的名称选择）。

要使其正常运行，还有很多问题需要解答，Allsop 当时也承认了这一点：

我将本节标题定为 “关于解决方案的一些想法”，因为要真正制定出可行的解决方案，还需要做大量的工作。悬而未决的问题包括以下几点。

  • 应该有多少种不同的语义属性？这些类别是否应该可以扩展？
  • 如何确定词汇表？
  • 我们是像开发人员使用类值那样简单地发明我们想要的术语，还是所有可能的值都应由标准化规范来确定？还是应该有一种机制，利用某种配置文件来发明（并希望共享）词汇表？
  • 如果两个词汇表之间存在冲突，比如两个不同的词汇表定义了两个相同的术语，该如何解决？
  • 我们是否需要一种名称间隔形式，或者是否存在其他机制？

这些问题中的许多仍然没有很好的答案，因为网络开发领域在其 “去他妈的，JavaScript 什么都能做 “的阶段，大多让这个问题变了味。如果每次都重写表单，就不需要扩展表单的行为。当我们开始走出那个时代时，我建议我们从 Allsop 离开的地方重新开始，将 HTML 打造成一个安全的可扩展超文本系统。

我们可以做的一件事就是立即正式认可 Kebab-case 属性，这与本建议大致相同（感谢 Deniz Akşimşek 向我展示了这一点）。这不仅能让许多最流行的 HTML 增强框架，以及互联网上的大量现有代码都能使用有效的 HTML，还能让使用用户或库定义的语义来扩展 HTML 的项目合法化。

好吧，亚历克斯，你会如何扩展这个按钮？

还记得从一开始就的按钮吗？

如果你想制作大量显示点击信息的按钮，最好的方法不是使用 onclick 或事件监听器，而是增强按钮，这样你就可以将任何按钮变成信息按钮。

<button alert message="I was clicked">Click me</button>

<script>
// Get all the buttons with the 'alert' attribute
const buttons = querySelectorAll('button[alert]')
buttons.forEach(btn => {
  // Get the message property of the button
  const message = btn.getAttribute('alert')
  // Set the button to alert that message when clicked
  btn.addEventListener('click', () => { alert(message) })
})
<script>

这样做的好处是可以在文档中的任何按钮上重复使用。对于不那么琐碎的应用，您可以将该行为捆绑到一个界面非常漂亮的库中（目前可能带有前缀）。

不过，如果您只需要为一个或两个按钮执行此操作，只需使用 onclick 即可。这样代码量更少，不需要指定 id，也不会让你跑到代码库的另一部分去看它做了什么。在我看来，这些都是 “最佳实践”。

备注

  • 至于如何实现 tooShortMessage 和相关属性，就留给读者去实践吧。
  • 对于按钮示例来说，type=alert 可能会更好，因为它扩展了现有的语义，但我真的不想讨论如何命名以实现兼容性。
  • 具有讽刺意味的是，与 document.getElementById 添加功能的方式相比，属性接口的内联定义更有优势，因为启用接口的代码实际上可以在元素间通用重用。
  • 有些人认为 “自定义语义 “是一个矛盾的说法，因为如果它不在 HTML 标准中，就不是 “语义”。其实语义并非如此。语义描述的是事物的表达能力。把它想象成一种语言：某种东西是不是一种语言，与有多少人讲这种语言无关；这只会影响学习这种语言的实用性。用户定义的语义可能是非标准的（至少在正式采用之前），但它们仍然是语义。
  • 很多人都非常讨厌在属性声明中看到哪怕是极少量的 JS 语法。我认为这有点愚蠢，但我也能理解。我将来会写关于这个问题的文章。

本文文字及图片出自 Behavior Belongs in the HTML

你也许感兴趣的：

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注