Webcomponents: Template/part proposals - Naming for DOM Parts API

[yuzhe-han]

In our virtual F2F breakout discussion for DOM Parts API, naming for the new APIs, Part, could cause confusion with CSS Shadow Parts.

Current Proposal: DOM Parts

interface Part {...};
interface NodePart : Part {...};
interface AttributePart : NodePart {...};
interface ChildNodePart : NodePart {...};
interface PropertyPart : NodePart {...};
interface CustomPart : NodePart{...};
interface PartGroup {...};

Naming alternatives to the Parts API :

1. Location can be an alternative to Part since they point to locations in the DOM where mutation can happen.
   The API becomes:

interface Location {...};
interface NodeLocation : Location {...};
interface AttributeLocation : NodeLocation {...};
...

1. Another common term used to indicate a placeholder for future data is binding.
   Frameworks like Angular and Vue uses binding to mark a place in an element where application data is inserted.

interface Binding {...};
interface NodeBinding : Binding {...};
interface AttributeBinding : NodeBinding {...};
...

What do you guys think?

@EisenbergEffect @caridy @JanMiksovsky @rniwa @hober @justinfagnani @mfreed7

[domenic]

Drive by: Attribute -> Attr would be nice for consistency and conciseness :)

[annevk]

Location already exists (see HTML). Binding doesn't have a lot of precedent other than IDL, but seems a bit confusing to me personally.

Did you consider "marker" or "insertion point" or some such?

[rniwa]

Location already exists (see HTML). Binding doesn't have a lot of precedent other than IDL, but seems a bit confusing to me personally.

Did you consider "marker" or "insertion point" or some such?

point might be a good terminology to use here given we already have boundary points for Range.

Maybe mutation points or manipulation points? Perhaps replacement points?

[annevk]

I like mutation points. Ties it right back to mutation observers and the mutation algorithms in general.

[EisenbergEffect]

Perhaps something like AttrMutator, ChildNodeMutator, PropertyMutator. Maybe LifecycleMutator for the custom callback scenario?

[justinfagnani]

Reference is name that somewhat naturally falls out of what the object is. I often talk about Parts as being cloneable references into the DOM.

[kenchris]

Maybe keep it short like WeakRef.: DOMRef

[annevk]

NodeRef, but yes, that is kinda nice too.

[yuzhe-han]

I like the concept of Reference too. The shortened version, NodeRef, AttrRef, PropertyRef sounds appealing.