The state of Web Components（待校正）

[nuysoft]

原文：The state of Web Components

The state of Web Components

Web Components 进展

By Wilson Page

Posted on June 9, 2015 in DOM, Featured Article, Standards, and Web Components

Web Components have been on developers’ radars for quite some time now. They were first introduced by Alex Russell at Fronteers Conference 2011. The concept shook the community up and became the topic of many future talks and discussions.

Web Components 进入开发者的视野已经有相当长的一段时间了。这一个概念最少被 Alex Russell 在 2011 年的 Fronteers Conference 上提出，震撼了整个社区，并且成为了许多关于未来谈话和讨论的话题。

自从 Alex Russell 在 Fronteers Conference 2011 上提出了 Web Components，进入开发者的视野已经过去了相当长的一段时间。这一个概念在社区中引起了不小的震动，并且成为众多演讲和讨论的话题。

In 2013 a Web Components-based framework called Polymer was released by Google to kick the tires of these new APIs, get community feedback and add some sugar and opinion.

在 2013 年，Google 发布了基于 Web Components 的框架 Polymer，来校验新增的 API、收集社区反馈、增加一些语法糖和改进。

By now, 4 years on, Web Components should be everywhere, but in reality Chrome is the only browser with ‘some version’ of Web Components. Even with polyfills it’s clear Web Components won’t be fully embraced by the community until the majority of browsers are on-board.

到现在已经第 4 个年头了，Web Components 本应该随处可见，但实际上，只有 Chrome 实现了 Web Components 的部分功能。很显然，在主流浏览器都实现 Web Components 之前，社区是不会接受的。

Why has this taken so long?

为什么花了这么久的时间？

To cut a long story short, vendors couldn’t agree.

长话短说的话，因为浏览器厂商不同意。

Web Components were a Google effort and little negotiation was made with other browsers before shipping. Like most negotiations in life, parties that don’t feel involved lack enthusiasm and tend not to agree.

Google 在开发 Web Components 之前，并没有和其他浏览器厂商沟通。就像生活中的大部分谈判一样，厂商们兴趣乏乏，无法达成一致。

Web Components were an ambitious proposal. Initial APIs were high-level and complex to implement (albeit for good reasons), which only added to contention and disagreement between vendors.

Web Components 曾经是一项野心勃勃的提案。最初的 API 高级、复杂、难以实现（尽管初衷是好的），这只会加剧浏览器厂商之间的竞争和分歧。

Google pushed forward, they sought feedback, gained community buy-in; but in hindsight, before other vendors shipped, usability was blocked.

Google 推进这项提案，他们看到了反馈，并且也得到了社区的认可；但是从事后看，在其他浏览器厂商支持前，这项提案仍然不实用。

Polyfills meant theoretically Web Components could work on browsers that hadn’t yet implemented, but these have never been accepted as ‘suitable for production’.

理论上，Polyfills 可以让 Web Components 在尚未支持的浏览器上运行，但是，这种做法被认为不适合生产环境。

Aside from all this, Microsoft haven’t been in a position to add many new DOM APIs due to the Edge work (nearing completion). And Apple, have been focusing on alternative features for Safari.

除了这些，Microsoft 继续向 Edge（即将完成）添加大量新的 DOM API，苹果也一直在为 Safari 寻找替代方案。

Custom Elements

自定义元素

Of all the Web Components technologies, Custom Elements have been the least contentious. There is general agreement on the value of being able to define how a piece of UI looks and behaves and being able to distribute that piece cross-browser and cross-framework.

在 Web Components 的所有技术概念中，自定义元素是最无争议的一个。能够定义 UI 的外观和行为、跨浏览器、跨框架，普遍认同这些价值。

‘Upgrade’

升级

The term ‘upgrade’ refers to when an element transforms from a plain old HTMLElement into a shiny custom element with its defined life-cycle and prototype. Today, when elements are upgraded, their createdCallback is called.

术语『升级』是指把一个普通的 HTMLElement 改造成闪闪发光的自定义元素，并且自带生命周期和原型。现在，当这样一个元素被创建时，原型方法 createdCallback 会被调用。

var proto = Object.create(HTMLElement.prototype);
proto.createdCallback = function() { ... };
document.registerElement('x-foo', { prototype: proto });

There are five proposals so far from multiple vendors; two stand out as holding the most promise.

到目前位置，浏览器厂商们提出了 5 项建议，其中有 2 项最有希望。

‘Dmitry’

德米特里

An evolved version of the createdCallback pattern that works well with ES6 classes. The createdCallback concept lives on, but sub-classing is more conventional.

结合 ES6 Class，可以把上面的代码改造为：

class MyEl extends HTMLElement {
  createdCallback() { ... }
}

document.registerElement("my-el", MyEl);

Like in today’s implementation, the custom element begins life as HTMLUnknownElement then some time later the prototype is swapped (or ‘swizzled’) with the registered prototype and the createdCallback is called.

上面的代码非常像现在的浏览器实现，自定义元素的生命周期从 HTMLUnknownElement 开始，稍后它的原型被赋值（或织入）为注册的原型，并且调用方法 createdCallback。

The downside of this approach is that it’s different from how the platform itself behaves. Elements are ‘unknown’ at first, then transform into their final form at some point in the future, which can lead to developer confusion.

这种方法的缺点是，它与浏览器的默认行为不一致。首先，元素是未知的，然后在将来某个时间点上，元素被转换成最终形态，这种不一致可能会导致开发者困惑。

Synchronous constructor

同步构造函数

The constructor registered by the developer is invoked by the parser at the point the custom element is created and inserted into the tree.

当自定义元素被创建并插入 DOM 树时，开发者注册的构造函数被浏览器解析器所调用。

class MyEl extends HTMLElement {
  constructor() { ... }
}

document.registerElement("my-el", MyEl);

Although this seems sensible, it means that any custom elements in the initial downloaded document will fail to upgrade if the scripts that contain their registerElement definition are loaded asynchronously. This is not helpful heading into a world of asynchronous ES6 modules.

看起来似乎是合理的，但是，如果注册自定义元素的代码是异步加载的，那么已下载文档中的任意自定义元素将会升级失败。

Additionally synchronous constructors come with platform issues related to .cloneNode().

另外，同步构造函数还会遇到与 .cloneNode() 有关的平台问题。

A direction is expected to be decided by vendors at a face-to-face meeting in July 2015.

浏览器厂商已经决定在 2015 年 7 月举行一场面对面的会议。

is=””

The is attribute gives developers the ability to layer the behaviour of a custom element on top of a standard built-in element.

这个属性允许开发者为内置标准元素赋予自定义元素的行为。

#### Arguments for #### 争议

Allows extending the built-in features of a element that aren’t exposed as primitives (eg. accessibility characteristics,

controls, ).
They give means to ‘progressively enhance’ an element, so that it remains functional without JavaScript.

允许扩展元素内置特性并不是原生语法（例如可访问性、

控件、）。这意味着渐进增强元素，因此即使没有 JavaScript，也可以保留功能。

Arguments against

分歧

1. Syntax is confusing.
2. It side-steps the underlying problem that we’re missing many key accessibility primitives in the platform.
3. It side-steps the underlying problem that we don’t have a way to properly extend built-in elements.
4. Use-cases are limited; as soon as developers introduce Shadow DOM, they lose all built-in accessibility features.

语法混乱。
回避了根本问题：平台缺少关键的可访问性。
回避了根本问题：我们无法正确地扩展内置元素。
测试用例有限；开发者引入的 Shadow DOM 缺少内置的可访问特性。

Consensus

共识

It is generally agreed that is is a ‘wart’ on the Custom Elements spec. Google has already implemented is and sees it as a stop-gap until lower-level primitives are exposed. Right now Mozilla and Apple would rather ship a Custom Elements V1 sooner and address this problem properly in a V2 without polluting the platform with ‘warts’.

普遍认为 is 是自定义元素提案的瑕疵。Google 已经实现的 is 被认为是一项权宜之计，直到底层特性被披露。现在，Mozilla 和 Apple 很快会启动『自定义元素 V1』，而这个问题将在 V2 中以不污染平台的方式被妥善解决。

HTML as Custom Elements is a project by Domenic Denicola that attempts to rebuild built-in HTML elements with custom elements in an attempt to uncover DOM primitives the platform is missing.

Domenic Denicola 的项目 HTML as Custom Elements 尝试用自定义元素重建内置的 HTML 元素，来发现平台缺失的 DOM 原生功能。

Shadow DOM

影子 DOM

Shadow DOM yielded the most contention by far between vendors. So much so that features had to be split into a ‘V1’ and ‘V2’ agenda to help reach agreement quicker.

到目前为止，影子 DOM 是浏览器厂商之间的最大争议点，为了尽快达成一致，提案不得不分成了 V1 和 V2 两个版本。

Distribution

分发

Distribution is the phase whereby children of a shadow host get visually ‘projected’ into slots inside the host’s Shadow DOM. This is the feature that enables your component to make use of content the user nests inside it.

分发是指影子宿主的子元素通过槽点访问影子宿主的影子 DOM。从而，使你的组件可以使用影子宿主内嵌的内容。

Current API

API 现状

The current API is fully declarative. Within the Shadow DOM you can use special <content> elements to define where you want the host’s children to be visually inserted.

目前的 API 完全是声明式的。在影子 DOM 中，你可以使用特定的 <content> 元素来定义子元素插入的位置。

<content select="header"></content>

Both Apple and Microsoft pushed back on this approach due to concerns around complexity and performance.

Apple 和 Microsoft 都采用了这种方案，是因为复杂度和性能的原因。

A new Imperative API

新的命令式 API

Even at the face-to-face meeting, agreement couldn’t be made on a declarative API, so all vendors agreed to pursue an imperative solution.

然后，在面对面的的会议上，声明式 API 并没有被通过，相反，所有的浏览器厂商都同意采用命令式的解决方案。

All four vendors (Microsoft, Google, Apple and Mozilla) were tasked with specifying this new API before a July 2015 deadline. So far there have been three suggestions. The simplest of the three looks something like:

四大厂商（Microsoft、Google、Apple 和 Mozilla）的任务是在 2015 年 7 月之前制定这一新 API。都目前为止已经有三个建议，它们简化之后看起来就像下面这样：

var shadow = host.createShadowRoot({
  distribute: function(nodes) {
    var slot = shadow.querySelector('content');
    for (var i = 0; i < nodes.length; i++) {
      slot.add(nodes[i]);
    }
  }
});

shadow.innerHTML = '<content></content>';

// Call initially ...
shadow.distribute();

// then hook up to MutationObserver

The main obstacle is: timing. If the children of the host node change and we redistribute when the MutationObserver callback fires, asking for a layout property will return an incorrect result.

最大的问题是：时机。如果宿主节点的子节点改变了，并且在 MutationObserver 的回调函数触发时重新执行了发布，此时，访问某个布局属性将返回错误的结果。

myHost.appendChild(someElement);
someElement.offsetTop; //=> old value

// distribute on mutation observer callback (async)

someElement.offsetTop; //=> new value

Calling offsetTop will perform a synchronous layout before distribution!

访问 offsetTop 将同步刷新布局，而且是在分发之前。

This might not seems like the end of the world, but scripts and browser internals often depend on the value of offsetTop being correct to perform many different operations, such as: scrolling elements into view.

可能看起来还不到世界末日（不算什么大问题），但是脚本和浏览器内部经常会依赖于 offsetTop 的值来执行不同的操作，例如：滚动浏览器，让元素处于可见范围。

If these problems can’t be solved we may see a retreat back to discussions over a declarative API. This will either be in the form of the current <content select> style, or the newly proposed ‘named slots’ API (from Apple).

如果这些问题得不到解决，我们可能得回到声明式 API 的讨论上来。可能是现在的 <content select>，也可能是新提案 可命名插槽 named slots API（来自 Apple）。

A new Declarative API – ‘Named Slots’

新的声明式 API - 可命名插槽

The ‘named slots’ proposal is a simpler variation of the current ‘content select’ API, whereby the component user must explicitly label their content with the slot they wish it to be distributed to.

提案『可命名插槽』是 content select 的简化版本，组件用户必须明确地用插槽标记出想要分发的内容。

Shadow Root of :

影子根节点是 ：

<slot name="header"></slot>
<slot></slot>
<slot name="footer"></slot>
<div>some shadow content</div>

Usage of <x-page>:

<x-page> 的用法：

<x-page>
  <header slot="header">header</header>
  <footer slot="footer">footer</footer>
  <h1>my page title</h1>
  <p>my page content<p>
</x-page>

Composed/rendered tree (what the user sees):

最终渲染的树（既用户所看到的）：

<x-page>
  <header slot="header">header</header>
  <h1>my page title</h1>
  <p>my page content<p>
  <footer slot="footer">footer</footer>
  <div>some shadow content</div>
</x-page>

The browser has looked at the direct children of the shadow host (myXPage.children) and seen if any of them have a slot attribute that matches the name of a element in the host’s shadowRoot.

浏览器已经知道影子宿主的子节点（myXPage.children），并且知道每个子节点是否含有 slot 属性，进而知道是否可以匹配影子宿主中的 节点。

When a match is found, the node is visually ‘distributed’ in place of the corresponding element. Any children left undistributed at the end of this matching process are distributed to a default (unamed) element (if one exists).

如果匹配，子节点被分发到 节点所在的位置。在匹配过程结束后，其余剩下的子节点被分发到默认（未命名的） 节点（如果有的话）。

For:

赞同：

1. Distribution is more explicit, easier to understand, less ‘magic’.
2. Distribution is simpler for the engine to compute.
3. 分发过程更加明确，更容易理解，更少的魔法。
4. 分发过程对引擎计算更简单。

Against:

反对：

1. Doesn’t explain how built-in elements, like , work. Decorating content with slot attributes is more work for the user. Less expressive. 没有解释内置元素是如何工作的，例如 。
2. 采用 slot 属性对内容进行装饰会带来用户更多的工作量。
3. 不直观。

‘closed’ vs. ‘open’

封闭 vs. 开放

When a shadowRoot is ‘closed’ the it cannot be accessed via myHost.shadowRoot. This gives a component author some assurance that users won’t poke into implementation details, similar to how you can use closures to keep things private.

如果一个 shadowRoot 是封闭的，将无法通过 myHost.shadowRoot 访问它。这样，组件作者可以避免掉组件用户影响到实现细节，类似于通过闭包保护某些私有的东西。

Apple felt strongly that this was an important feature that they would block on. They argued that implementation details should never be exposed to the outside world and that ‘closed’ mode would be a required feature when ‘isolated’ custom elements became a thing.

苹果强烈地感到，这是一个非常重要的功能，并且会阻塞了后面的工作。他们认为实现细节永远不该向外暴露，封闭模式是一个必需的功能，如果还想搞自定义元素的话（如果将来要隔离自定义元素的话）。

Google on the other hand felt that ‘closed’ shadow roots would prevent some accessibility and component tooling use-cases. They argued that it’s impossible to accidentally stumble into a shadowRoot and that if people want to they likely have a good reason. JS/DOM is open, let’s keep it that way.

谷歌则持不同的观点，他们认为封闭的影子根节点会限制可访问性和组件的应用场景。限制用户访问 shadowRoot 是不可能的，如果用户有足够的理由的话，就更不应该限制。JS 和 DOM 是开放的，我们也保持开放就好了。

At the April meeting it became clear that to move forward, ‘mode’ needed to be a feature, but vendors were struggling to reach agreement on whether this should default to ‘open’ or ‘closed’. As a result, all agreed that for V1 ‘mode’ would be a required parameter, and thus wouldn’t need a specified default.

在四月的会议上，对于应该封闭还是开放有了清晰的进展，即增加一个新特性 mode，但是对于它的默认值应该是 open 还是 closed，浏览器厂商们仍然无法达成一致。最终大家的结论是，在 V1 中，mode 作为一个必需的参数，这样就不需要规范默认值了（逗）。

element.createShadowRoot({ mode: 'open' });
element.createShadowRoot({ mode: 'closed' });

Shadow piercing combinators

影子穿透选择器

A ‘piercing combinator’ is a special CSS ‘combinator’ that can target elements inside a shadow root from the outside world. An example is /deep/ later renamed to >>>:

穿透选择器是一种特殊的 CSS 选择器，可以从外部定位到影子根节点内部的元素。用 >>> 指示深度选择：

.foo >>> div { color: red }

When Web Components were first specified it was thought that these were required, but after looking at how they were being used it seemed to only bring problems, making it too easy to break the style boundaries that make Web Components so appealing.

当 Web Components 第一次提出穿透选择器时，人们认为是合理和必需的，但是在看过如何使用之后，觉得穿透选择器只会带来问题，它轻而易举地就打破了样式的边界。

Performance

性能

Style calculation can be incredibly fast inside a tightly scoped Shadow DOM if the engine doesn’t have to take into consideration any outside selectors or state. The very presence of piercing combinators forbids these kind of optimisations.

如果浏览器引擎不考虑任何外部的选择器和状态，影子 DOM 内部的样式计算可能快的难以置信地。而穿透选择器恰恰会妨碍这类优化。

Alternatives

备选方案

Dropping shadow piercing combinators doesn’t mean that users will never be able to customize the appearance of a component from the outside.

放弃影子穿透选择器并不意味着用户永远无法从外部自定义组件的外观。

CSS custom-properties (variables)

CSS 自定义属性（变量）

In Firefox OS we’re using CSS Custom Properties to expose specific style properties that can be defined (or overridden) from the outside.

在 Firefox OS 中，我们可以使用 CSS 自定义属性来暴露特定的样式属性，从而可以从外部定义或重写这些样式属性。

External (user):
外部（用户）：

x-foo { --x-foo-border-radius: 10px; }

Internal (author):
内部（作者）：

.internal-part { border-radius: var(--x-foo-border-radius, 0); }

Custom pseudo-elements

自定义伪类元素

We have also seen interest expressed from several vendors in reintroducing the ability to define custom pseudo selectors that would expose given internal parts to be styled (similar to how we style parts of today).

我们已经看到一些浏览器厂商有意重新引入自定义伪类选择器的功能，暴露一些指定的内部元素，并允许用户自定义这些元素的样式（类似于我们定义 的部分样式）。

译注：How to Style Input Type Range in Chrome, Firefox, and IE

x-foo::my-internal-part { ... }

This will likely be considered for a Shadow DOM V2 specification.

这可能会在影子 DOM V2 规范中被考虑。

Mixins – @extend

混入 – @extend

There is proposed specification to bring SASS’s @extend behaviour to CSS. This would be a useful tool for component authors to allow users to provide a ‘bag’ of properties to apply to a specific internal part.

有一项提案建议把 SASS @extend 的功能引入 CSS。对于组件作者来说，这将是一个有用的工具，允许组件用户批量覆盖特定内部元素的样式。

External (user):
外部（用户）：

.x-foo-part {
  background-color: red;
  border-radius: 4px;
}

Internal (author):
内部（作者）：

.internal-part {
  @extend .x-foo-part;
}

Multiple shadow roots

多个影子根节点

Why would I want more than one shadow root on the same element?, I hear you ask. The answer is: inheritance.

你可能会问：为什么需要多个影子根节点呢？答案是：继承。

Let’s imagine I’m writing an <x-dialog> component. Within this component I write all the markup, styling, and interactions to give me an opening and closing dialog window.

想象一下，我正在编写一个 <x-dialog> 组件。在这个组件中，我写下了所有的标记、样式，以及用于打开和关闭窗口的按钮。

<x-dialog>
  <h1>My title</h1>
  <p>Some details</p>
  <button>Cancel</button>
  <button>OK</button>
</x-dialog>

The shadow root pulls any user provided content into div.inner via the <content> insertion point.

影子根节点通过槽点 <content> 把用户提供的所有内容放入 div.inner 中。

<div class="outer">
  <div class="inner">
    <content></content>
  </div>
</div>

I also want to create <x-dialog-alert> that looks and behaves just like <x-dialog> but with a more restricted API, a bit like alert('foo').

然后，我想创建一个 <x-dialog-alert> 组件，外观和行为很像 <x-dialog>，但是提供一个更受限的 API，类似于 alert('foo')。

<x-dialog-alert>foo</x-dialog-alert>

var proto = Object.create(XDialog.prototype);

proto.createdCallback = function() {
  XDialog.prototype.createdCallback.call(this);
  this.createShadowRoot();
  this.shadowRoot.innerHTML = templateString;
};

document.registerElement('x-dialog-alert', { prototype: proto });

The new component will have its own shadow root, but it’s designed to work on top of the parent class’s shadow root. The <shadow> represents the ‘older’ shadow root and allows us to project content inside it.

这个新组件将拥有它自己的影子根节点，但它是基于父类的影子根节点设计的。节点 <shadow> 代替了旧的影子根节点，兵允许修改其中的内容。

<shadow>
  <h1>Alert</h1>
  <content></content>
  <button>OK</button>
</shadow>

Once you get your head round multiple shadow roots, they become a powerful concept. The downside is they bring a lot of complexity and introduce a lot of edge cases.

一旦你理解了多重影子根节点，它们将变成一个非常强大的概念。然后不足之处在于，它们带来了很多的复杂度，并引入大量的边界情况。

Inheritance without multiple shadows

不基于多重影子的继承

Inheritance is still possible without multiple shadow roots, but it involves manually mutating the super class’s shadow root.

即使没有多重影子根节点，实现继承也是可能的，但是它需要手动修改超类的影子根节点。

var proto = Object.create(XDialog.prototype);

proto.createdCallback = function() {
  XDialog.prototype.createdCallback.call(this);
  var inner = this.shadowRoot.querySelector('.inner');

  var h1 = document.createElement('h1');
  h1.textContent = 'Alert';
  inner.insertBefore(h1, inner.children[0]);

  var button = document.createElement('button');
  button.textContent = 'OK';
  inner.appendChild(button);

  ...
};

document.registerElement('x-dialog-alert', { prototype: proto });

The downsides of this approach are:
这种方案的缺点是：

1. Not as elegant.
2. Your sub-component is dependent on the implementation details of the super-component.
3. This wouldn’t be possible if the super component’s shadow root was ‘closed’, as this.shadowRoot would be undefined.
4. 不优雅。
5. 子组件依赖于父组件的实现细节。
6. 如果父组件的影子根节点是封闭的，this.shadowRoot 将是 undefined。

HTML Imports

HTML Imports provide a way to import all assets defined in one .html document, into the scope of another.

HTML Imports 提供了把一个 .html 文档中的全部资源文件引入到另一个文档的方式。

<link rel="import" href="/path/to/imports/stuff.html">

As previously stated, Mozilla is not currently intending to implementing HTML Imports. This is in part because we’d like to see how ES6 modules pan out before shipping another way of importing external assets, and partly because we don’t feel they enable much that isn’t already possible.

从这篇文档可以知道，Mozilla 目前不打算实现 HTML Imports。部分原因是，在启动一种引入外部资源的新方式之前，我们想先看看 ES6 的模块化效果如何，另一部分原因是，相交于现状，HTML Imports 并没有带来更多的特性。

We’ve been working with Web Components in Firefox OS for over a year and have found using existing module syntax (AMD or Common JS) to resolve a dependency tree, registering elements, loaded using a normal <script> tag seems to be enough to get stuff done.

我们已经在 Firefox OS 上应用 Web Components 超过了一年的时间，发现可以利用现有的模块语法（AMD 或 Common JS）来解决依赖问题，通过一个普通的 <script> 标签来加载依赖，似乎看起来就足以满足需求了。

HTML Imports do lend themselves well to a simpler/more declarative workflow, such as the older <element> and Polymer’s current registration syntax.

HTML Imports 做的更好的地方在于，它更加简单、更加声明式的工作流程，例如早期的 <element> 和现在的 Polymer 注册语法。

With this simplicity has come criticism from the community that Imports don’t offer enough control to be taken seriously as a dependency management solution.

这种简单性饱受社区的批评，因为如果把它当作一种依赖管理解决方案来认真对待的话，它并没有提供足够的控制。

Before the decision was made a few months ago, Mozilla had a working implementation behind a flag, but struggled through an incomplete specification.

在几个月前做出这项决定之前，Mozilla 已经实现了这项特性，但是因为不完善的规范而步履维艰。

What will happen to them?

未来会如何？

Apple’s Isolated Custom Elements proposal makes use of an HTML Imports style approach to provide custom elements with their own document scope;: Perhaps there’s a future there.

Apple 对于隔离自定义元素的建议，利用了 HTML Imports 来提供自定义元素，并保留元素的文档作用域，这是一种可能的未来。

At Mozilla we want to explore how importing custom element definitions can align with upcoming ES6 module APIs. We’d be prepared to implement if/when they appear to enable developers to do stuff they can’t already do.

Mozilla 则想要探讨如何保证引入自定义元素定义的方式与即将到来的 ES6 模块化 API 保持一致。我们已经准备好实现开发者所不能实现的工作。

To conclude

总括

Web Components are a prime example of how difficult it is to get large features into the browser today. Every API added lives indefinitely and remains as an obstacle to the next.

如今，想向浏览器添加大型功能非常的困难，Web Components 就是一个典型例子。每个已经添加的 API 将无限期的存在下去，并且阻碍了新功能。

Comparable to picking apart a huge knotted ball of string, adding a bit more, then tangling it back up again. This knot, our platform, grows ever larger and more complex.

这就像从巨大的毛线球上拽出一截线头，在这节线头上增加点东西，再把这节线头缠回毛线球。这个毛线球，即我们的浏览器平台，将增长的越来越大，越来越复杂。

Web Components have been in planning for over three years, but we’re optimistic the end is near. All major vendors are on board, enthusiastic, and investing significant time to help resolve the remaining issues.

Web Components 已经规划了三年多，从乐观的角度看，似乎快要完成了。所有的浏览器厂商都处在同一条船上，充满热情，并且投入大量时间来解决剩余的问题。

Let’s get ready to componentize the web!
让我们准备好构建组件化的网站！