摘要

  • W3C 于 2013 年 5 月 14 日发表 Custom Elements 首份公开草案。2016 年草案详细描述类、注册表、已存在元素的升级与生命周期回调；2018 年说明记录了内容并入 DOM 和 HTML 规范的过程。
  • 现行 HTML 标准让作者向 CustomElementRegistry 登记定义。浏览器匹配并升级元素，在连接、离开或受观察属性变化等时机运行反应；具体业务行为由组件作者编写。

想象一家新闻编辑部，想在每篇报道旁摆放图片、标题和阅读链接组成的卡片。可以写一个脚本，每次载入页面都巡视所有卡片，逐个安排工作。也可以让浏览器记住 <story-card> 的定义，在元素出现、离开或更新时直接通知它。后者让岗位职责跟着标签走，不必靠一位忙不过来的巡视员。

W3C 2013 年 5 月 14 日的首份公开草案提出，网页作者可以定义新的 DOM 元素类型。早期方案把名称、原型与生命周期回调联系起来。具体接口后来演变，但分工已经成形：平台负责新类型怎样进入文档中的普通元素体系，作者负责它上岗后做什么。

W3C 2016 年 6 月 9 日的工作草案展示更熟悉的程序：作者写一个继承 HTMLElement 的类，再用 customElements.define() 登记。草案举例，一个元素已在文档中，定义却尚未登记；定义到来后，符合条件的元素得到升级。网页可以先摆好工位，浏览器等岗位说明书到手，再让它开工。

注册表还负责核对名称，安排升级与反应。自主定义的标签名含连字符，为作者的新名称留出空间。组件可以声明要观察哪些属性；属性改变时运行 attributeChangedCallback()。连入文档时有 connectedCallback()，离开时有 disconnectedCallback()。浏览器按元素反应规则安排这些调用，卡片作者把初始化和清理写在卡片自己的类里。

上岗后也会有调动。元素可能先出现在 HTML 中，之后才加载定义；它也可能被移动、移除又重新接入。作者要让代码承受真实的生命周期，包括重复连接。浏览器保证登记、匹配与回调时机，编辑部仍要决定照片怎么排、标题怎么写。人事部不会替记者写稿。

独立规范后来搬了家。W3C 2018 年 5 月 3 日的工作组说明指出，Custom Elements 内容正在并入 DOM、HTML 等相关规范。W3C 发布史保存了从 2013 年首稿到 2018 年迁移的文档轨迹。这套机制进入了平台的主干规则。

现行的 WHATWG HTML Living Standard 中 Custom Elements 一章规定注册表、名称检查、升级和反应队列，也覆盖后来发展的采用、表单参与等场景。核心协议仍然简明：浏览器让已登记的名字与元素实例相认，作者赋予这个名字实际用途。

Shadow DOM 处理组件内部树的安排及与外部内容的接触；Custom Elements 处理标签的身份与生命周期。新闻卡片可以同时使用两者：一套图纸安排房间，一张工牌说明谁来工作。标签终于不只是挂在网页上的名字。