diff --git a/proposals/DOM-Parts-Declarative-Template.md b/proposals/DOM-Parts-Declarative-Template.md
new file mode 100644
index 0000000..2d6121f
--- /dev/null
+++ b/proposals/DOM-Parts-Declarative-Template.md
@@ -0,0 +1,73 @@
+# DOM Parts Declarative Template API
+
+This proposal covers the declarative API for creating a DOM part within a
+`<template>` element.
+
+## Proposal
+
+Double curly braces `{{}}` provide markers for DOM parts.
+
+In the most basic level, this proposal can produce the three DOM parts:
+`NodePart`, `AttributePart`, `ChildNodePart`.
+
+### Basic Examples
+
+Suppose we had the following template in some HTML extension template languages
+where `{name}` and `{email}` indicated locations of dynamic data insertion:
+
+```html
+<section>
+  <h1 id="name">{name}</h1>
+  Email: <a id="link" href="mailto:{email}">{email}</a>
+</section>
+```
+
+And the application has produce a template with the following content:
+
+```html
+<template>
+  <section>
+    <h1 id="name">{{}}</h1>
+    Email: <a id="link" href="{{}}">{{}}</a>
+  </section>
+</template>
+```
+
+This will create a `ChildNodePart` attached to `<h1>` with no content, a
+`NodePart` attached to `<a>`, and an `AttributePart` connected to `href`.
+
+A framework could fetch these parts use either a
+[`DocumentPart`](./DOM-Parts-Imperative.md#option-2-documentpartgroup) on the
+`DocumentFragment` produced by the template.
+
+## `PartialAttributePart`
+
+Allowing `{{}}` inside an attribute with some static content raises the same
+question as a
+[`PartialAttributePart`](./DOM-Parts-Imperative.md#partial-attribute-updates),
+but if the imperative questions are resolved so too could the declarative
+template syntax.
+
+## Metadata
+
+Templating systems may need to serialize data about the nodes they are marking
+into the processing instructions. Or at the very least parts could be named so
+that they are easier to fetch.
+
+```html
+<div>{{email data="foo"}}</div>
+```
+
+This could be exposed on the imperative API to be consumed in JavaScript by
+application logic.
+
+## Choice of marker
+
+The `{{}}` is a reasonable DOM part marker, but it could be something else, or
+it could even be something that is declared as the placeholder.
+
+## Compatability
+
+It may be challenging to implement `<template>` parsing of `{{}}` for
+compatability reasons, so there may need to be restrictions such as only
+allowing this template syntax in a new API like `createTemplateWithParts()`.
diff --git a/proposals/DOM-Parts-Imperative.md b/proposals/DOM-Parts-Imperative.md
new file mode 100644
index 0000000..8034a6c
--- /dev/null
+++ b/proposals/DOM-Parts-Imperative.md
@@ -0,0 +1,608 @@
+# DOM Parts Imperative API
+
+This proposal covers the imperative API for creating a DOM part.
+
+## Proposal
+
+A DOM part is represented by the `Part` interface and its sub interfaces.
+
+```webidl
+interface Part {
+    attribute any value;
+    void commit();
+};
+
+interface NodePart : Part {
+    constructor(Node node);
+    readonly attribute Node node;
+};
+
+interface AttributePart : Part {
+    constructor(Element element, DOMString qualifiedName, DOMString? namespace);
+    readonly attribute DOMString prefix;
+    readonly attribute DOMString localName;
+    readonly attribute DOMString namespaceURI;
+};
+
+interface ChildNodePart : Part {
+    constructor(Node node, Node? previousSibling, Node? nextSibling);
+    readonly attribute Node? previousSibling;
+    readonly attribute Node? nextSibling;
+};
+```
+
+The `Part` has one property named "value" of
+[_any_ type](https://heycam.github.io/webidl/#idl-any).
+
+When a new value is set or assigned to a DOM part, the change does not
+immediately reflect back to the corresponding
+[node](https://dom.spec.whatwg.org/#concept-node), its
+[attributes](https://dom.spec.whatwg.org/#concept-attribute), or its
+[properties](<(https://tc39.es/ecma262/#sec-object-type)>). Instead, the new
+value is staged to be later committed in a batch. This batching reduces the
+runtime overhead of constantly returning control back from browser's
+implementation to JavaScript between each DOM mutation and allows browser
+engine's to avoid or batch certain sanity checks and housekeeping tasks.
+
+In the most basic level, this proposal consists of three DOM parts:
+
+1. `NodePart` represents a single
+   [node](https://dom.spec.whatwg.org/#concept-node).
+1. `AttributePart` represents a single
+   [attribute](https://dom.spec.whatwg.org/#concept-attribute).
+1. `ChildNodePart` represents a sequence of
+   [child](https://dom.spec.whatwg.org/#concept-tree-child)
+   [nodes](https://dom.spec.whatwg.org/#concept-node) of a node which can be
+   [replaced](https://dom.spec.whatwg.org/#concept-node-replace).
+
+### Basic Examples
+
+Suppose we had the following template in some HTML extension template languages
+where `{name}` and `{email}` indicated locations of dynamic data insertion:
+
+```html
+<section>
+  <h1 id="name">{name}</h1>
+  Email: <a id="link" href="mailto:{email}">{email}</a>
+</section>
+```
+
+And the application has produced the following HTML with the static content:
+
+```html
+<section>
+  <h1 id="name"></h1>
+  Email: <a id="link"></a>
+</section>
+```
+
+Then the application can imperatively create a `ChildNodePart` for
+[`h1` element](https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements)
+and
+[`a` element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element)
+and an `AttributePart` for
+[`a` element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element)
+as follows:
+
+```js
+const name = staticContent.getElementById("name");
+const link = staticContent.getElementById("link");
+const namePart = new ChildNodePart(name);
+const emailPart = new ChildNodePart(link);
+const emailAttributePart = new AttributePart(link, "href");
+```
+
+Then assigning values as follows will update the DOM:
+
+```js
+namePart.value = "Ryosuke Niwa";
+emailPart.value = "rniwa@webkit.org";
+emailAttributePart.value = "mailto:rniwa@webkit.org";
+namePart.commit();
+emailPart.commit();
+emailAttributePart.commit();
+```
+
+The resultant DOM will look like this:
+
+```html
+<section>
+  <h1 id="name">Ryosuke Niwa</h1>
+  Email: <a id="link" href="mailto:rniwa@webkit.org">rniwa@webkit.org</a>
+</section>
+```
+
+## Part Groups
+
+DOM parts need grouping and ownership to provide batching and to enable parts
+created declaratively to be retrieved and updated by JavaScript.
+
+### Option 1. `PartGroup`
+
+One option is to make the concept of DOM part group a real DOM
+[interface](https://heycam.github.io/webidl/#idl-interfaces):
+
+```webidl
+interface PartGroup {
+    constructor(sequence<Part> parts);
+    readonly attribute FrozenArray<Part> parts;
+    void commit();
+}
+```
+
+Note that if we allow a single `Part` to belong to multiple `PartGroup`s, the
+first `PartGroup` which commits the changes would apply the mutations. In
+effect, this allows
+non-[partitioned](https://en.wikipedia.org/wiki/Partition_of_a_set) grouping of
+`Part` objects to be committed together.
+
+There is also a question of how mutable parts should be, and whether a
+`PartGroup` can appear as a part of another `PartGroup` for nested template
+instances or not. It doesn't make much sense for the list of _DOM parts_
+associated with `PartGroup` to get mutated after we've started committing things
+but there certainly is a room for adding or removing _DOM parts_ based on new
+input or state.
+
+If we made the relationship between DOM parts and `PartGroup` not dynamically
+mutable, users of this API could still create a new `PartGroup` each time such a
+mutation would have needed instead.
+
+The `parts` order would be the order in which DOM part was inserted to the
+`PartGroup`. Although there could be multiple DOM parts which reference the same
+element in different parts of the array, that doesn't necessarily pose an
+obvious issue other than a slight inefficiency in batching certain DOM
+operations.
+
+### Option 2. `DocumentPartGroup`
+
+A dynamic list of parts could be maintained at the `document` (and document
+fragment) level that would allow fetching all parts.
+
+```webidl
+interface DocumentPartGroup {
+  readonly attribute Array<Part> parts;
+  void commit();
+}
+
+partial interface Document {
+  readonly attribute DocumentPartGroup documentPart;
+}
+```
+
+The list of parts would be cached initially on render, and then invalidated for
+lazy recalculation for any new `Part` that was declaratively or imperatively
+added to the `document`.
+
+The `parts` array would be in DOM-order. The exact algorithm for how to keep the
+`parts` array up to date with the `document` is an open question.
+
+### Option 3. `ChildNodePart` is a `PartGroup`
+
+To make `DocumentPartGroup` more performant and to provide better structure to
+`Part` relationships for a more optimal DOM walk, `ChildNodePart` could itself
+be a `PartGroup`, and would contain any `Part` objects that were nested inside
+its range, and child `parts` would not be part of any parent `ChildNodePart` or
+`DocumentPartGroup`.
+
+```webidl
+interface ChildNodePart {
+  readonly attribute Array<Part> parts;
+  void commit();
+}
+```
+
+The `parts` array would be in DOM-order. The exact algorithm for how to keep the
+`parts` array up to date with the DOM subtree rooted by the `ChildNodePart` is
+an open question.
+
+## Cloning Parts
+
+Cloning parts along with the nodes they refer to is a major use case for DOM
+parts.
+
+### Option 1: `cloneWithParts`
+
+One option would to add a new API to `Node`:
+
+```webidl
+partial interface Node {
+    NodeWithParts cloneWithParts(optional CloneOptions options = {});
+};
+
+dictionary CloneOptions {
+    boolean deep = true;
+    Document? document;
+    PartGroup? partGroup;
+};
+
+dictionary NodeWithParts {
+    Node node;
+    PartGroup? partGroup;
+};
+```
+
+Here, we're proposing a slightly nicer API by combining
+[`importNode`](https://dom.spec.whatwg.org/#dom-document-importnode) and
+[`cloneNode`](https://dom.spec.whatwg.org/#dom-node-clonenode) and making the
+[cloning](https://dom.spec.whatwg.org/#concept-node-clone) deep by default.
+
+### Option 2: `cloneWithParts` on `DocumentPart` and `ChildNodePart`
+
+Since `DocumentPart` and `ChildNodePart` both are rooted at a specific node, the
+clone semantics are clearer:
+
+```webidl
+partial interface DocumentPart {
+    NodeWithParts clone();
+}
+
+partial interface ChildNodePart {
+    NodeWithParts clone();
+}
+```
+
+### Other Cloning Questions
+
+There are some questions here as well. What happens to the current values of DOM
+parts? Do we allow DOM parts to have some non-initial values and do we clone
+those values as well? If so, what do we do with proposed extensions like
+`PropertyPart` / `CustomPart`?
+
+## Partial Attribute Updates
+
+Note in that above example,
+[`href` attribute](https://html.spec.whatwg.org/multipage/links.html#attr-hyperlink-href)
+had initially contained `mailto:` before `{email}` but we could not capture this
+prefix in the attribute value because `AttributePart` could only set the whole
+attribute value.
+
+There are a few options for how to support the use case of updating attributes
+with embedded static content such as `mailto:`
+
+### Option 1. Create Multiple `AttributePart`s Together
+
+In this approach, `AttributePart` gets a new static function which creates a
+list of `AttributePart`s which work together to set a value when the values are
+to be committed:
+
+```js
+const [firstName, lastName] = AttributePart.create(element, "title", null, [
+  null,
+  " ",
+  null,
+]);
+// Syntax to be improved. Here, a new AttributePart is created between each string.
+```
+
+- **Pros**: Simplicity.
+- **Cons**: Coming up with a nice syntax to create a sequence of AttributePart
+  and string can be tricky.
+
+### Option 2. Introduce `AttributePartGroup`
+
+In this approach, we group multiple `AttributePart`s together by creating an
+explicit group:
+
+```js
+const firstName = new AttributePart();
+const lastName = new AttributePart();
+const group = AttributePartGroup(element, "title");
+group.append(firstName, " ", lastName);
+```
+
+This is morally equivalent to option 1 except there is an explicit grouping
+step.
+
+- **Pros**: Nicer syntax by the virtue of individual "partial" `AttributePart`'s
+  existence at the time of grouping. Code that assigns values to `AttributePart`
+  only needs to know about `AttributePart`
+- **Cons**: More objects / complexity. `AttributePart` will have two modes.
+
+### Option 3. Introduce `AttributePartFragment`
+
+Unlike option 2, this creates `AttributePartFragment`s from `AttributePart`,
+meaning that `AttributePart` in option 3 plays the role of `AttributePartGroup`
+in option 2:
+
+```js
+const firstNamePartial = new AttributePartFragment();
+const lastNamePartial = new AttributePartFragment();
+const part = AttributePart(element, "title");
+part.values = [firstNamePartial, " ", lastNamePartial];
+```
+
+- **Pros**: Nicer syntax by the virtue of individual `AttributePartFragment`'s
+  existence at the time of grouping. `AttributePart` just knows one thing to do:
+  to set the whole content attribute value.
+- **Cons**: More objects / complexity. Code that uses a template has to deal
+  with two different kinds of objects: `AttributePartFragment` and
+  `AttributePart`.
+
+### Option 4. Support arbitrary JavaScript objects
+
+One way of punting is to support arbitrary JavaScript objects as `value` that
+conform to some interface. This interface could be as simple as `toString()`, or
+could use `Symbol` to determine how to populate attributes. This would allow
+code that wanted to represent partial attributes, but would maintain the
+property that parts represent nodes or groupings of nodes.
+
+```js
+class TitleAttributeValue {
+  constructor() {
+    this.firstName = "";
+    this.lastName = "";
+  }
+
+  toString() {
+    return `${this.firstName} ${this.lastName}`;
+  }
+}
+
+const part = AttributePart(element, "title");
+part.value = new TitleAttributeValue();
+part.value.firstName = "Ryosuke";
+part.value.lastName = "Niwa";
+```
+
+- **Pros** No need for new `PartialAttributePart` or `AttributePart`
+  coordination. Does not block a future API object that represents partial
+  attributes.
+- **Cons** Need a way to represent partial attributes that are declaratively
+  defined.
+
+## Sibling `ChildNodePart`s
+
+Like partial attribute updates, when there are multiple points of interests
+under a single [parent](https://dom.spec.whatwg.org/#concept-tree-parent)
+[node](https://dom.spec.whatwg.org/#concept-node), and they're next to each
+other, index does not adequately describe a specific location in the DOM when
+other parts [insert](https://dom.spec.whatwg.org/#concept-node-insert) or
+[remove](https://dom.spec.whatwg.org/#concept-node-remove)
+[children](https://dom.spec.whatwg.org/#concept-tree-child).
+
+### Option 1. Create Multiple `ChildNodePart`s Together
+
+In this approach, `ChildNodePart` gets a new static function which creates a
+list of `ChildNodePart`s which work together to set a value when the values are
+to be committed:
+
+```js
+const [firstName, lastName] = ChildNodePart.create(element, null, null, [
+  null,
+  " ",
+  null,
+]);
+```
+
+- **Pros**: Simplicity.
+- **Cons**: Coming up with a nice syntax to create a sequence of `ChildNodePart`
+  and string can be tricky.
+
+### Option 2. Introduce `ChildNodePartGroup`
+
+In this approach, we group multiple `ChildNodePart`s together by creating an
+explicit group:
+
+```js
+const firstName = new ChildNodePart();
+const lastName = new ChildNodePart();
+const group = ChildNodePartGroup(element, null, null);
+group.append(firstName, " ", lastName);
+```
+
+This is morally equivalent to option 1 except there is an explicit grouping
+step.
+
+- **Pros**: Nicer syntax by the virtue of individual "partial" `ChildNodePart`s
+  existence at the time of grouping. Code that sets new children to
+  `ChildNodePart`s only needs to know about `ChildNodePart`.
+- **Cons**: More objects / complexity. `ChildNodePart` will have two modes.
+
+### Option 3. Introduce `PartialChildNodePart`
+
+This creates `PartialChildNodePart` from `ChildNodePart`:
+
+```js
+const firstNamePartial = new PartialChildNodePart();
+const lastNamePartial = new PartialChildNodePart();
+const part = ChildNodePart(element, null, null);
+part.values = [firstNamePartial, " ", lastNamePartial];
+```
+
+- **Pros**: Nicer syntax by the virtue of individual `PartialChildNodePart`s
+  existence at the time of grouping.
+- **Cons**: More objects / complexity. Code that uses a template has to deal
+  with two different kinds of objects: `PartialChildNodePart` and
+  `ChildNodePart`.
+
+### Option 4. Allow `nextSibling` and `previousSibling` to point to another `ChildNodePart`
+
+We would update `ChildNodPart` interface as follows and allow `previousSibling`
+and `nextSibling` to point to another `ChildNodePart` as well as `Node`:
+
+```webidl
+interface ChildNodePart : Part {
+    constructor(Node node, (Node or ChildNodePart)? previousSibling, (Node or ChildNodePart)? nextSibling);
+    readonly attribute Node parentNode;
+    readonly attribute (Node or ChildNodePart)? previousSibling;
+    readonly attribute (Node or ChildNodePart)? nextSibling;
+};
+```
+
+Then we can insert two consecutive `ChildNodePart`s by relating them in the
+constructor as follows:
+
+```js
+const firstName = new ChildNodePart(element);
+const lastName = new ChildNodePart(element, firstName);
+```
+
+Note that `lastName` takes `firstName` as the previous sibling but `firstName`
+doesn't `lastName` as the next sibling (since `lastName` doesn't exist at that
+point in time). This would mean that we'd have to do a bit of implicit updating
+of previous/next sibling of other parts in the constructor.
+
+An alternative is to add an explicit API to chain multiple parts togethers:
+
+```js
+const firstName = new ChildNodePart(element);
+const lastName = new ChildNodePart(element);
+ChildNodePart.chain(firstName, lastName);
+```
+
+- **Pros**: API simplicity. Only `ChildNodePart` is involved but construction
+  isn't as awkward as option 1.
+- **Cons**: "Chained" `ChildNodePart` must coordinate when applying mutations.
+
+### Option 5. Throw an error if two `ChildNodePart`s overlap
+
+Instead of worrying about coordination, the imperative API could throw an
+`Error` if users constructed two `ChildNodePart`s that overlapped.
+
+```js
+const firstName = new ChildNodePart(element);
+const lastName = new ChildNodePart(element); // throws an Error.
+```
+
+Like in option 4, new APIs like `chain` or an a `append` could be added that
+make it easier to have repeated `ChildNodePart`s.
+
+- **Pros**: API simplificity. Prevents nodes from getting into conflicting or
+  confusing states.
+- **Cons**: Parts need to be aware of one another.
+
+## `ChildNodePart` After DOM Mutations
+
+A `ChildNodePart` can be constructed with a `previousSibling` and/or
+`nextSibling`. This raises the question of what happens if these nodes are
+mutated, such as being removed from the DOM or added underneath a different
+parent.
+
+### Option 1. Part validity
+
+It does not make sense to treat DOM parts as valid if the nodes in the DOM are
+not in a state that is logical. So a new validity concept could be introduced
+with the following constraints for `ChildNodePart`:
+
+1. `previousSibling` and `nextSibling` do not share the same parent
+1. Another `ChildNodePart` is overlapping, meaning it starts before
+   `previousSibling` and ends between `previousSibling` and `nextSibling` or
+   starts between `previousSibling` and `nextSibling` and ends after
+   `nextSibling`.
+
+If a `ChildNodePart` is invalid, `.value` is empty string and setting it does
+nothing, and `.commit()` throws an Error.
+
+For `NodePart` and `AttributePart`, validity could also be whether the related
+`Node` was in a `document`, but it could also make sense to allow updates to
+disconnected `Node`s.
+
+### Option 2. Use an invisible markers after construction.
+
+`ChildNodePart` could create an invisible marker immediately after
+`previousSibling` and immediately before `nextSibling`, much like how `Range`
+works. This comes with all the drawbacks or `Range`, but does have better
+performance because they can only be added to via `ChildNodePart` APIs, and
+always are scoped to a single `Node`'s children.
+
+These invisible markers would not be `Node`s and so would be backwards
+compatible. DOM mutations would follow shrinking `Range` semantics, meaning the
+`ChildNodePart` would remove any `Node` that is removed in between the markers,
+and would only add a `Node` if it is added in between the markers.
+
+## `PropertyPart` and `CustomCallbackPart`
+
+Adding the support to set a
+[JavaScript property](https://tc39.es/ecma262/#sec-object-type) on, or invoking
+the [setter](https://tc39.es/ecma262/#table-accessor-property-attributes) of, a
+[DOM node](https://dom.spec.whatwg.org/#concept-node) poses an unique challenge
+but it has been
+[one of the most consistent feedback](https://github.com/w3c/webcomponents/issues/810).
+A naive approach can reduce or eliminate the benefit of batching multiple DOM
+mutations together since invoking JavaScript forces the browser engine to update
+all its internal states to a consistent state prior to any script execution. On
+the other hand, re-ordering so that all JavaScript related operations happen at
+the end can cause a
+[JavaScript setter](https://tc39.es/ecma262/#table-accessor-property-attributes)
+to override [content attributes](https://dom.spec.whatwg.org/#concept-attribute)
+which appear later in the markup, which would be a confusing behavior for users
+of a template engine.
+
+One way to solve this issue by delaying JavaScript execution until all DOM
+mutations are done but interleaving
+[custom element callback reactions](https://html.spec.whatwg.org/multipage/custom-elements.html#callback-reaction)
+in-between setter calls. This ensures
+[custom element callback reaction](https://html.spec.whatwg.org/multipage/custom-elements.html#callback-reaction)
+for [attribute changes](https://dom.spec.whatwg.org/#handle-attribute-changes)
+and setter calls occur in the order they are scheduled.
+
+To achieve this observable behavior, when a DOM part of this type `PropertyPart`
+appears on an [element](https://dom.spec.whatwg.org/#concept-element), we insert
+a new kind of an item into the
+[element](https://dom.spec.whatwg.org/#concept-element)'s
+[custom element reaction queue](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-reaction-queue).
+This new kind of item, let us call it **property reaction**, is simply an
+arbitrary entry point back to the code which invokes the
+[JavaScript setter](https://tc39.es/ecma262/#table-accessor-property-attributes)
+unlike other items in the queue which involves some predefined method passed to
+[`customElements.define`](https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-define).
+
+Consider two `AttributePart`s and a `PropertyPart` which all work an
+[element](https://dom.spec.whatwg.org/#concept-element) `A`, another
+`AttributePart` and `PropertyPart` for different
+[element](https://dom.spec.whatwg.org/#concept-element) `B`, and a sequence of
+updates as shown below where each A* and B* are `AttributePart`s and
+`PropertyPart`s for respective elements:
+
+```js
+bPropertyPart.value = "foo";
+aAttributePart1.value = "foo";
+bAttributePart.value = "foo";
+aPropertyPart.value = "foo";
+aAttributePart2.value = "foo";
+```
+
+Recall that these assignments to DOM parts simply stage values to be set when
+the groups later commit changes. It has a queue unique to each element of the
+"staged" DOM parts with pending mutations, in this case:
+`[aAttributePart1, aPropertyPart1, aAttributePart2]` for `A` and
+`[bPropertyPart, bAttributePart]` for `B`. Suppose `A` appears before `B` in the
+group all these DOM parts belong to. Then as the browser engine makes DOM
+mutations for `aAttributePart1` and `aAttributePart2` on `A`, it also schedules
+a _property reaction_ for `aPropertyPart` between the two. It would then
+schedule a _property reaction_ for `bPropertyPart` then makes DOM mutation for
+`bAttributePart`.
+
+If `A` is a
+[custom element](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element),
+then the following sequence of events will take place:
+
+- `attributeChangedCallback` for `aAttributePart1` gets invoked.
+- _Property reaction_ and therefore the corresponding
+  [JavaScript setter](https://tc39.es/ecma262/#table-accessor-property-attributes)
+  for `aPropertyPart` gets invoked.
+- `attributeChangedCallback` for the attribute `aAttributePart` marks gets
+  invoked.
+
+The _property reaction_ of `PropertyPart` simply invokes
+[`Set(O, P, V, Throw)`](https://tc39.es/ecma262/#sec-set-o-p-v-throw) on `A`.
+With this in mind, `PropertyPart`'s interface could simply be:
+
+```webidl
+interface PropertyPart : Part {
+    constructor(Node node, DOMString propertyName);
+    readonly attribute propertyName;
+}
+```
+
+Since the mechanism of invoking a _property reaction_ is generic enough to
+execute arbitrary scripts, not just
+[`Set(O, P, V, Throw)`](https://tc39.es/ecma262/#sec-set-o-p-v-throw), we could
+generalize it to support arbitrary code execution like this:
+
+```webidl
+callback CustomPartCallback = undefined (Node node, CustomPart part);
+interface CustomPart : Part {
+    constructor(Node node, CustomPartCallback callback);
+}
+```
diff --git a/proposals/DOM-Parts.md b/proposals/DOM-Parts.md
index 6b86468..94e9aeb 100644
--- a/proposals/DOM-Parts.md
+++ b/proposals/DOM-Parts.md
@@ -1,521 +1,106 @@
-# DOM Part API - First Step of Template Instantiation
+# DOM Part API
 
-This is a joint proposal by Ryosuke Niwa and Theresa O'Connor at Apple and Justin Fagnani, Mason Freed, and Yuzhe Han at Google.
+This is a joint proposal by Ryosuke Niwa and Theresa O'Connor at Apple and
+Justin Fagnani, Mason Freed, Tom Wilkinson, and Yuzhe Han at Google.
 
 ## Motivation
 
-The HTML5 specification defines the [template element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element)
-but doesn't provide a native mechanism to instantiate it with some parts of it substituted,
-conditionally included, or repeated based on JavaScript values
-&mdash; unlike popular JavaScript frameworks such as [Ember.js](https://guides.emberjs.com/v2.16.0/templates/)
-and [Angular](https://angular.io/guide/template-syntax) allow.
-
-In 2017, [Apple proposed the Template Instantiation API](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md),
-a Web API to parameterize a template instance and allow interpolation of JavaScript data during the initial instantiation as well as in subsequent updates.
-
-Reflecting on many feedbacks we've received including whether such as
-us having to [ensure API materially improves the platform at all](https://github.com/w3c/webcomponents/issues/704),
-this refined proposal focuses on the essence of the previous proposal:
-[`NodeTemplatePart`](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#46-nodetemplatepart-interface)
-and [`AttributeTemplatePart`](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#45-attributetemplatepart-interface)
-which provide mechanisms to insert or replace content at a specific location in a DOM tree.
-We've heard from multiple library and framework authors that such API, if designed right,
-can be adopted and reduce the amount of code they have to write.
-The fact there is a [similar proposal made by a framework author](https://github.com/whatwg/dom/issues/736) gives us confidence
-that extracting the essence of `NodeTemplatePart` and `AttributeTemplatePart` would bring a material benefit to the platform
-while paving our way for the full declarative syntax for custom elements.
-
-As such, this proposal foregoes the previously controversial parts of the proposals:
-a standard syntax for data interpolations, conditionals, and loops, and a mechanism
-to define different types of template processing model that are needed to address
-[all the use cases mentioned in the old proposal](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#2-use-cases) to a future extension.
+The existing specifications that provide the ability to update DOM update after
+an initial render are limited. Frameworks can walk the DOM or query for nodes,
+and use JavaScript APIs to imperatively update attributes, text content, and
+other JavaScript properties of these nodes. However, the framework code that
+initially locates DOM that will need to be updated and repeatedly updates that
+DOM has not been optimized.
+
+Many frameworks provide specific domain-specific templating languages that
+provide a higher level semantic representation of the DOM structure that
+includes static parts that never change, dynamic parts that change depending on
+data context, and other non-HTML structures like event listeners.
+
+A sampling of frameworks and templating:
+
+1. React, Solid.js, and others use HTML-in-JS
+   [JSX](https://react.dev/learn/writing-markup-with-jsx).
+1. Angular uses an extension of
+   [HTML](https://angular.io/guide/template-overview).
+1. Svelte uses a combined HTML/JS
+   [template](https://svelte.dev/docs#template-syntax).
+1. Lit uses
+   [tagged template literals](https://lit.dev/docs/templates/overview/).
+
+There are many other frameworks that similarly have created templating languages
+to represent the logic of rendering an HTML component from static strings and
+dynamic data. These templating systems are used as blueprints to determine how
+to hydrate, render, or update DOM.
+
+The HTML5 specification defines the
+[template element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element)
+that provides the ability to render HTML with the intention of cloning the HTML.
+When it comes to updating the template with dynamic content, the specification
+does not provide any assistance and leaves it to the framework to walk or query
+the newly rendered DOM. Often, the dynamic boundaries of a template are known
+statically, and frameworks have no need to visit static nodes in the cloned DOM.
+Additionally, it's up to frameworks to cache the boundaries of these dynamic
+portions of the output HTML for later use in update operations if the data
+changes in such a way that the HTML needs to update.
+
+When it comes to hydrating HTML that was rendered by a server response,
+frameworks have similar needs for locating and updating nodes. Frameworks today
+use different strategies to hydrate the DOM after an initial server-side HTML
+render, but all use either a DOM query or a DOM walk to visit nodes that require
+hydration or later update.
+
+For updating, the methods today are limited to JavaScript APIs to update text
+content, modify or add child nodes, add or remove attributes, or call
+`HTMLElement` specific APIs. From the perspective of the browser, these updates
+are atomic and unrelated. This prevents the browser from being able to take
+advantage of knowledge that the framework has, such as whether updates will be
+batched. It also creates awkward experiences for frameworks that are trying to
+perform operations that aren't easy to make atomic, such as moving an element
+with focus.
+
+In general, there's no way to identify arbitrary positions and content in HTML.
+Most identifying APIs today are graph based (like child index or parent) or node
+property based (`id`, `class`) and require either DOM walks or DOM querying with
+worse than constant-time runtime cost for anything other than `id` based
+queries. Current identifying APIs also leave out whole classes of HTML content
+that cannot be easily identified:
+
+1. Text content
+1. Attributes, or content within attributes
+1. Positions in between nodes and ranges of nodes (there is a
+   [`Range`](https://developer.mozilla.org/en-US/docs/Web/API/Range) but it is
+   not performant).
+1. Comment nodes.
+
+Being able to identify these types of position and content matters when thinking
+about a templating system, but it also matters when thinking about other APIs,
+for example a deferred content API which needs to identify a specific insertion
+point.
+
+These use cases point to the requirement for a generalized specification that
+would allow marking and updating arbitrary positions and content in the DOM and
+properties exposed only via JavaScript APIs. This principally serves as a
+write-target for template languages, but would also be understandable without a
+third-party templating system.
+
+This proposal focuses on the key parts of these use cases:
+
+1. Identifying positions and content as fast as `id` based queries.
+1. Updating positions and content as fast as current DOM-update APIs.
 
 ## Proposal
 
-We introduce the concept of a **DOM part**, which represents an unit of mutable state in a DOM tree.
-It could be a [content attribute](https://dom.spec.whatwg.org/#concept-attribute) of an [element](https://dom.spec.whatwg.org/#concept-element),
-[child](https://dom.spec.whatwg.org/#concept-tree-child) nodes of a [node](https://dom.spec.whatwg.org/#concept-node),
-or even a [JavaScript property](https://tc39.es/ecma262/#sec-object-type) of an element.
-A *DOM part* is represented by the `Part` interface.
-It has one property named "value" of [*any* type](https://heycam.github.io/webidl/#idl-any).
-
-When a new value is set or assigned to a *DOM part*,
-the change does not immediately reflect back to the corresponding [node](https://dom.spec.whatwg.org/#concept-node),
-its [attributes](https://dom.spec.whatwg.org/#concept-attribute),
-or its [properties]((https://tc39.es/ecma262/#sec-object-type))
-Instead, the new value is staged to be later committed in a batch,
-which is defined by an ordered set of *DOM parts* called **DOM parts group**.
-Each *DOM part* may belong to at most one *DOM part group*.
-This batching reduces the runtime overhead of constantly returning control back from browser's implementation to JavaScript
-between each DOM mutation and allows browser engine's to avoid or batch certain sanity checks and housekeeping tasks.
-
-In the [old proposal](https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#3-proposal),
-a *DOM part group* was represented by a [template element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element).
-This proposal keeps that approach possible but does not keep it the sole approach possible.
-
-### Interfaces
-
-```webidl
-interface Part {
-    attribute any value;
-    void commit();
-};
-
-interface NodePart : Part {
-    readonly attribute Node node;
-};
-
-interface AttributePart : Part {
-    constructor(Element element, DOMString qualifiedName, DOMString? namespace);
-    readonly attribute DOMString prefix;
-    readonly attribute DOMString localName;
-    readonly attribute DOMString namespaceURI;
-};
-
-interface ChildNodePart : Part {
-    constructor(Node node, Node? previousSibling, Node? nextSibling);
-    readonly attribute Node parentNode;
-    readonly attribute Node? previousSibling;
-    readonly attribute Node? nextSibling;
-};
-```
-
-In the most basic level, this proposal consists of two *DOM parts*:
-`AttributePart` represents a single [attribute](https://dom.spec.whatwg.org/#concept-attribute) which can be set
-and `ChildNodePart` represents a sequence of [child](https://dom.spec.whatwg.org/#concept-tree-child) [nodes](https://dom.spec.whatwg.org/#concept-node)
-of a [node](https://dom.spec.whatwg.org/#concept-node) which can be [replaced](https://dom.spec.whatwg.org/#concept-node-replace).
-
-### Basic Examples
-
-Suppose we had the following template where `{name}` and `{email}` are locations of our interests:
-```html
-<section><h1 id="name">{name}</h1>Email: <a id="link" href="mailto:{email}">{email}</a></section>
-```
-
-And we've parsed the following HTML so far (future extensions will make this parsing possible without extra JavaScript code):
-```html
-<section><h1 id="name"></h1>Email: <a id="link" href=""></a></section>
-```
-
-Then we can create `ChildNodePart` for [`h1` element](https://html.spec.whatwg.org/multipage/sections.html#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements)
-and [`a` element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element)
-and `AttributePart` for [`a` element](https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element) as follows: 
-```js
-namePart = new ChildNodePart(name)
-emailPart = new ChildNodePart(link)
-emailAttributePart = new AttributePart(link, 'href')
-
-Then assigning values as follows will update the DOM:
-namePart.value = "Ryosuke Niwa"
-emailPart.value = "rniwa@webkit.org"
-emailAttributePart.value = "mailto:rniwa@webkit.org"
-namePart.commit();
-emailPart.commit();
-emailAttributePart.commit();
-```
-
-The resultant DOM will look like this:
-```html
-<section><h1 id="name">Ryosuke Niwa</h1>Email: <a id="link" href="mailto:rniwa@webkit.org"></a></section>
-```
-
-### Example with Templates
-
-Suppose we had the following [template](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element):
-```html
-<template id="t1"><section><h1 id="name">{name}</h1>Email: <a id="link" href="{emailAddress}">{email}</a></section></template>
-```
-
-We can create [clone](https://dom.spec.whatwg.org/#concept-node-clone)
-its [content](https://html.spec.whatwg.org/multipage/scripting.html#template-contents)
-and create *DOM parts* as follows:
-```js
-const instance = document.importNode(t1.content, /* deep */ true);
-const parts = createParts(instance);
-container.appendChild(instance);
-
-function createParts(node, parts = {}) {
-    const add = (replaceable, part) => {
-        parts[replaceable.substring(1, replaceable.length - 1)] = part;
-    }
-    if (node.nodeType == Node.TEXT_NODE && node.data.match(/^\{\w+\}$/)) {
-        add(node.data, new ChildNodePart(node.parentNode, node.previousSibling, node.nextSibling));
-        node.remove();
-        return;
-    }
-    for (const attr of (node.attributes || [])) {
-        if (attr.value.match(/^\{\w+\}$/)) {
-            add(attr.value, new AttributePart(node, attr.name, attr.namespaceURI);
-            attr.value = '';
-        }
-    }
-    for (const childNode of node.childNodes)
-        createParts(childNode, parts);
-    return parts;
-}
-```
-
-After running this code, `instance` would contain a DOM tree equivalent of:
-```html
-<section><h1 id="name"></h1>Email: <a id="link" href=""></a></section>
-```
-
-Then we can assign values to various parts we've just created as follows:
-```js
-updateParts(parts, {name: "Ryosuke Niwa", email: "rniwa@webkit.org", "emailAddress": "mailto:rniwa@webkit.org"})
-
-function updateParts(parts, object) {
-    for (const name in object) {
-        const part = parts[name];
-        if (part) {
-            part.value = object[name];
-            part.commit();
-        }
-    }
-}
-```
-
-which will update the DOM tree of instance to the equivalent of:
-```html
-<section><h1 id="name">Ryosuke Niwa</h1>Email: <a id="link" href="mailto:rniwa@webkit.org">rniwa@webkit.org</a></section>
-```
-
-We can call `updateParts` many times over after this point,
-and the same DOM tree would get updated according to the values of the object passed to updateParts.
-
-## Partial Attribute Updates
-
-Note in that above example, [`href` attribute](https://html.spec.whatwg.org/multipage/links.html#attr-hyperlink-href)
-had initially contained `mailto:` before `{email}` but we could not capture this prefix in the attribute value
-because `AttributePart` could only set the whole attribute value.
-One native solution for this limitation is to add the support for specifying a prefix or an offset within the attribute value like so:
-```js
-emailAttributePart = new AttributePart(link, 'href', {'prefix': 'mailto:'})
-```
-
-or:
-```js
-emailAttributePart = new AttributePart(link, 'href', 7)
-```
-
-However, this approach falls apart once when we have multiple parts within a single attribute
-since prefix or offset depends on the present value of other parts. e.g.
-```html
-<section><h1 id="name" title="{lastName}, {firstName}">{name}</h1></section>
-```
-
-To facilitate cases like this, [`AttributeTemplatePart` in the old proposal](https://github.com/rniwa/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#45-attributetemplatepart-interface)
-had a concept of [attribute value setter](https://github.com/rniwa/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#41-attribute-value-setter),
-which takes the values of all parts involved for each [content attribute](https://dom.spec.whatwg.org/#concept-attribute)
-and sets a single string value by concatenating them upon committing.
-
-This approach worked in the old proposal because
-the [browser engine was parsing](https://github.com/rniwa/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#43-creating-template-parts)
-a [template element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element)'s mustache syntax
-and generated a group of `AttributeTemplatePart` together.
-The same approach can't be taken in the world we're introducing `AttributePart` as a primitive API.
-
-Here, we consider a few alternatives.
-We can create a group of `AttributePart` together and implicitly relate them, create a specific `AttributePartGroup` object,
-or create a new class like `PartialAttributePart` which works together to set a single value using an `AttributePart`.
-
-### Option 1. Create Multiple `AttributePart`s Together
-
-In this approach, `AttributePart` gets a new static function which creates
-a list of `AttributePart`s which work together to set a value when the values are to be committed:
-
-```js
-const [firstName, lastName] = AttributePart.create(element, 'title', null, [null, ' ', null]);
-// Syntax to be improved. Here, a new AttributePart is created between each string.
-```
-
-* **Pros**: Simplicity.
-* **Cons**: Coming up with a nice syntax to create a sequence of AttributePart and string can be tricky.
-
-### Option 2. Introduce `AttributePartGroup`
-
-In this approach, we group multiple `AttributePart`s together by creating an explicit group:
-```js
-const firstName = new AttributePart();
-const lastName = new AttributePart();
-const group = AttributePartGroup(element, 'title');
-group.append(firstName, ' ', lastName);
-```
-
-This is morally equivalent to option 1 except there is an explicit grouping step.
-
-* **Pros**: Nicer syntax by the virtue of individual "partial" `AttributePart`'s existence at the time of grouping.
-    Code that assigns values to `AttributePart` only needs to know about `AttributePart`
-* **Cons**: More objects / complexity. `AttributePart` will have two modes.
-
-### Option 3. Introduce `PartialAttributePart`
-
-Unlike option 2, this creates `PartialAttributePart`s from `AttributePart`,
-meaning that `AttributePart` in option 3 plays the role of `AttributePartGroup` in option 2:
-
-```js
-const firstNamePartial = new PartialAttributePart();
-const lastNamePartial = new PartialAttributePart();
-const part = AttributePart(element, 'title');
-part.values = [firstNamePartial, ' ', lastNamePartial];
-```
-
-* **Pros**: Nicer syntax by the virtue of individual `PartialAttributePart`'s existence at the time of grouping.
-    `AttributePart` just knows one thing to do: to set the whole content attribute value.
-* **Cons**: More objects / complexity. Code that uses a template has to deal with two different kinds of objects:
-    `PartialAttributePart` and `AttributePart`.
-
-## Partial Child Updates
-
-Like partial attribute updates, when there are multiple points of interests
-under a single [parent](https://dom.spec.whatwg.org/#concept-tree-parent) [node](https://dom.spec.whatwg.org/#concept-node),
-and they're next to each other, nextextSibling / previousSibling / nodeIndex
-does not adequately describe a specific location in the DOM when other parts [insert](https://dom.spec.whatwg.org/#concept-node-insert)
-or [remove](https://dom.spec.whatwg.org/#concept-node-remove) [children](https://dom.spec.whatwg.org/#concept-tree-child).
-Again, the three options mentioned above apply as well as one more option:
-
-### Option 1. Create Multiple `ChildNodePart`s Together
-
-In this approach, `ChildNodePart` gets a new static function
-which creates a list of `ChildNodePart`s which work together to set a value when the values are to be committed:
-
-```js
-const [firstName, lastName] = ChildNodePart.create(element, null, null, [null, ' ', null]);
-```
-
-* **Pros**: Simplicity.
-* **Cons**: Coming up with a nice syntax to create a sequence of `ChildNodePart` and string can be tricky.
-
-### Option 2. Introduce `ChildNodePartGroup`
-
-In this approach, we group multiple `ChildNodePart`s together by creating an explicit group:
-
-```js
-const firstName = new ChildNodePart();
-const lastName = new ChildNodePart();
-const group = ChildNodePartGroup(element, null, null);
-group.append(firstName, ' ', lastName);
-```
-
-This is morally equivalent to option 1 except there is an explicit grouping step.
-
-* **Pros**: Nicer syntax by the virtue of individual "partial" `ChildNodePart`s existence at the time of grouping.
-    Code that sets new children to `ChildNodePart`s only needs to know about `ChildNodePart`.
-* **Cons**: More objects / complexity. `ChildNodePart` will have two modes.
-
-### Option 3. Introduce `PartialNodeChildPart`
-
-This creates `PartialNodeChildPart` from `ChildNodePart`:
-
-```js
-const firstNamePartial = new PartialNodeChildPart();
-const lastNamePartial = new PartialNodeChildPart();
-const part = NodeChildPart(element, null, null);
-part.values = [firstNamePartial, ' ', lastNamePartial];
-```
-
-* **Pros**: Nicer syntax by the virtue of individual `PartialChildNodePart`s existence at the time of grouping.
-* **Cons**: More objects / complexity.
-    Code that uses a template has to deal with two different kinds of objects: `PartialChildNodePart` and `ChildNodePart`.
-
-### Option 4. Allow `nextSibling` and `previousSibling` to point to another `ChildNodePart`
-
-We would update `ChildNodPart` interface as follows and allow `previousSibling` and `nextSibling` to point to another `ChildNodePart` as well as `Node`:
-
-```webidl
-interface ChildNodePart : Part {
-    constructor(Node node, (Node or ChildNodePart)? previousSibling, (Node or ChildNodePart)? nextSibling);
-    readonly attribute Node parentNode;
-    readonly attribute (Node or ChildNodePart)? previousSibling;
-    readonly attribute (Node or ChildNodePart)? nextSibling;
-};
-```
-
-Then we can insert two consecutive `NodeChildPart`s by relating them in the constructor as follows:
-
-```js
-const firstName = new NodeChildPart(element);
-const lastName = new NodeChildPart(element, firstName);
-element.append(firstName, lastName); // For illustration purposes, there is no space between the two parts.
-```
-
-Note that `lastName` takes `firstName` as the previous sibling but `firstName` doesn't `lastName` as the next sibling
-(since `lastName` doesn't exist at that point in time).
-This would mean that we'd have to do a bit of implicit updating of previous/next sibling of other parts in the constructor.
-
-An alternative is to add an explicit API to chain multiple parts togethers:
-```js
-const firstName = new NodeChildPart(element);
-const lastName = new NodeChildPart(element);
-ChildNodePart.chain(firstName, lastName);
-element.append(firstName, lastName); // For illustration purposes, there is no space between the two parts.
-```
-
-* **Pros**: API simplicity. Only `NodeChildPart` is involved but construction isn't as awkward as option 1.
-* **Cons**: "Chained" `NodeChildPart` must coordinate when applying mutations.
-
-## Updating JS Property / Invoking Setter
-
-Adding the support to set a [JavaScript property](https://tc39.es/ecma262/#sec-object-type) on,
-or invoking the [setter](https://tc39.es/ecma262/#table-accessor-property-attributes) of,
-a [DOM node](https://dom.spec.whatwg.org/#concept-node) poses an unique challenge
-but it has been [one of the most consistent feedback](https://github.com/w3c/webcomponents/issues/810).
-A naive approach can reduce or eliminate the benefit of batching multiple DOM mutations together
-since invoking JavaScript forces the browser engine to update all its internal states to a consistent state prior to any script execution.
-On the other hand, re-ordering so that all JavaScript related operations happen at the end
-can cause a [JavaScript setter](https://tc39.es/ecma262/#table-accessor-property-attributes)
-to override [content attributes](https://dom.spec.whatwg.org/#concept-attribute) which appear later in the markup,
-which would be a confusing behavior for users of a template engine.
-
-This proposal attempts to solve this issue by delaying JavaScript execution until all DOM mutations are done
-but interleaving [custom element callback reactions](https://html.spec.whatwg.org/multipage/custom-elements.html#callback-reaction) in-between setter calls.
-This ensures [custom element callback reaction](https://html.spec.whatwg.org/multipage/custom-elements.html#callback-reaction)
-for [attribute changes](https://dom.spec.whatwg.org/#handle-attribute-changes) and setter calls occur in the order they are scheduled.
-
-To achieve this observable behavior, when a *DOM part* of this type, let us call it `PropertyPart`,
-appears on an [element](https://dom.spec.whatwg.org/#concept-element),
-we insert a new kind of an item into the [element](https://dom.spec.whatwg.org/#concept-element)'s
-[custom element reaction queue](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-reaction-queue).
-This new kind of item, let us call it **property reaction**,
-is simply an arbitrary entry point back to the code which invokes
-the [JavaScript setter](https://tc39.es/ecma262/#table-accessor-property-attributes)
-unlike other items in the queue which involves some predefined method passed to
-[`customElements.define`](https://html.spec.whatwg.org/multipage/custom-elements.html#dom-customelementregistry-define).
-
-Consider two `AttributePart`s and `PropertyPart` which all work an [element](https://dom.spec.whatwg.org/#concept-element) `A`,
-and another set of `AttributePart` and `PropertyPart` for another [element](https://dom.spec.whatwg.org/#concept-element) `B`,
-and a sequence of updates as shown below where each A* and B* are `AttributePart`s and `PropertyPart`s for respective elements:
-
-```js
-BProp.value = 'foo';
-AAttr1.value = 'foo';
-BAttr.value = 'foo';
-AProp.value = 'foo';
-AAttr2.value = 'foo';
-```
-
-Recall that these assignments to *DOM parts* simply stage values to be set when the *DOM part group*s later commit these changes.
-It has a queue unique to each element of the "staged" *DOM parts* with pending mutations.
-In this case: `[AAttr1, AProp, AAttr2]` for `A` and `[BProp, BAttr]` for `B`.
-Suppose `A` appears before `B` in the *DOM part group* all these DOM parts belong.
-Then as the browser engine makes DOM mutations for `AAttr1` and `AAttr2` on `A`,
-it also schedules a *property reaction* for `AProp` between the two.
-It would then schedule a *property reaction* for `BProp` then makes DOM mutation for `BAttr`.
-
-If `A` is a [custom element](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element),
-then the following sequence of events will take place:
-
-* `attributeChangedCallback` for `AAttr1` gets invoked.
-*  *Property reaction* and therefore the corresponding [JavaScript setter](https://tc39.es/ecma262/#table-accessor-property-attributes) for `AProp` gets invoked.
-* `attributeChangedCallback` for AAttr1 gets invoked.
-
-The *property reaction* of `PropertyPart` simply invokes [`Set(O, P, V, Throw)`](https://tc39.es/ecma262/#sec-set-o-p-v-throw) on `A`.
-With this in mind, `PropertyPart`'s interface could simply be:
-
-```webidl
-interface PropertyPart : Part {
-    constructor(Node node, DOMString propertyName);
-    readonly attribute propertyName;
-}
-```
-
-Since the mechanism of invoking a *property reaction* is generic enough to execute arbitrary scripts,
-not just [`Set(O, P, V, Throw)`](https://tc39.es/ecma262/#sec-set-o-p-v-throw),
-we could generalize it to support arbitrary code execution like this:
-
-```webidl
-callback CustomPartCallback = undefined (Node node, CustomPart part);
-interface CustomPart : Part {
-    constructor(Node node, CustomPartCallback callback);
-}
-```
-
-## Batching: Template or Not
-
-In [the old proposal](https://github.com/rniwa/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#3-proposal),
-the [template element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element)
-was a natural aggregator of all the pending mutations and batch them together in a lump sum.
-`TemplatePart` being tied to a template element has been one of the most persistent complaints by web developers as well,
-and there have been multiple alternate proposals in this arena.
-
-We would like for `Part`-only API to still provide the ability to batch multiple mutations for the added performance gain.
-This will also avoid having to create two versions of API:
-one for declarative custom elements using a template with the performance benefit, and another separate per-`Part` mutation API.
-
-One alternative is to make the concept of DOM part group a real DOM [interface](https://heycam.github.io/webidl/#idl-interfaces):
-
-```webidl
-interface PartGroup {
-    constructor(sequence<Part> parts);
-    readonly attribute FrozenArray<Part> parts;
-    void commit();
-}
-```
-
-Note that if we allow a single `Part` to belong to multiple `PartGroup`s,
-the first `PartGroup` which commits the changes would apply the mutations.
-In effect, this allows non-[partitioned](https://en.wikipedia.org/wiki/Partition_of_a_set) grouping of `Part` objects to be committed together.
-
-There is also a question of how mutable parts should be,
-and whether a `PartGroup` can appear as a part of another `PartGroup` for nested template instances or not.
-It doesn't make much sense for the list of *DOM parts* associated with `PartGroup` to get mutated after
-we've started committing things but there certainly is a room for adding or removing *DOM parts* based on new input or state.
-
-If we made the relationship between *DOM parts* and `PartGroup` not dynamically mutable,
-users of this API could still create a new `PartGroup` each time such a mutation would have needed instead.
-
-### Batching Order
-
-What order should the *DOM part group* commit each *DOM parts*' new values?
-In the old proposal, the [tree order](https://dom.spec.whatwg.org/#concept-tree-order)
-at the time of parsing the template element's content was an obvious choice.
-
-This isn't possible in `Part`-only API because there isn't a single point in time when all *DOM parts* are created.
-We could re-evaluate each time a new *DOM part* is added to a *DOM part group* but that would incur a high runtime cost
-since it would likely require traversing all [node trees](https://dom.spec.whatwg.org/#concept-node-tree) referenced by each *DOM part*.
-Dynamically evaluating at the time of committing pending changes doesn't work either
-because some of the [nodes](https://dom.spec.whatwg.org/#concept-node) might not be
-a part of the same [node tree](https://dom.spec.whatwg.org/#concept-node-tree) until some of the pending changes are committed.
-
-The simplest choice is probably the order in which *DOM part* was inserted to a given *DOM part group*.
-Although there could be multiple *DOM parts* which reference the same element in different parts of the array,
-that doesn't necessarily pose an obvious issue other than a slight inefficiency in batching certain DOM operations.
-Because the template engine is the one which creates these `Part` objects,
-this is also probably not an issue in practice.
-In any case, we can batch mutations per [element](https://dom.spec.whatwg.org/#concept-element)
-like we do with [custom element reaction queue](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-reaction-queue) if necessary.
-
-### Cloning Parts
-
-Similarly, in [the old proposal](https://github.com/rniwa/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md#3-proposal),
-the [template element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element) was a natural source of template parts.
-The browser engine can cache the result of parsing the [template content](https://html.spec.whatwg.org/multipage/scripting.html#template-contents)
-and use that to efficiently generate template parts.
-
-To achieve a similar efficiency with the Part-only API, we need a way to clone a Node subtree with Parts associated with a given PartGroup:
-
-```webidl
-partial interface Node {
-    NodeWithParts cloneTree(optional CloneOptions options = {});
-};
-
-dictionary CloneOptions {
-    boolean deep = true;
-    Document? document;
-    PartGroup? partGroup;
-};
-
-dictionary NodeWithParts {
-    Node node;
-    PartGroup? partGroup;
-};
-```
+This proposal introduces the concept of a **DOM part**, which represents an unit
+of mutable state in a DOM tree. It could be a
+[content attribute](https://dom.spec.whatwg.org/#concept-attribute) of an
+[element](https://dom.spec.whatwg.org/#concept-element),
+[child](https://dom.spec.whatwg.org/#concept-tree-child) nodes of a
+[node](https://dom.spec.whatwg.org/#concept-node), or even a
+[JavaScript property](https://tc39.es/ecma262/#sec-object-type) of an element.
 
-Here, we're proposing a slightly nicer API by combining [`importNode`](https://dom.spec.whatwg.org/#dom-document-importnode)
-and [`cloneNode`](https://dom.spec.whatwg.org/#dom-node-clonenode)
-and making the [cloning](https://dom.spec.whatwg.org/#concept-node-clone) deep by default.
+There are a few component pieces to this proposal, so it is easiest to split it
+into multiple documents.
 
-There are some questions here as well.
-What happens to the current values of *DOM parts*?
-Do we allow *DOM parts* to have some non-initial values and do we clone those values as well?
-If so, what do we do with `PropertyPart` / `CustomPart`?
+1. [Imperative API to construct DOM parts](./DOM-Parts-Imperative.md)
+1. [Declarative API to construct DOM parts in `<template>`](./DOM-Parts-Declarative-Template.md)