Explain the relationship of DOM Parts to XHTML

[hsivonen]

How is the DOM Parts syntax expected to relate to XHTML generally, the notion that the HTML and XHTML serializations of HTML are so close that it's not only feasible to migrate between them but also to pursue a single byte stream having the same meaning as both ("polyglot"), and the notion that the mapping between markup and DOM for XML exists on its own independently of HTML?

( https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts-Declarative-Template.md does not currently explain that currently in the Chromium prototype the proposed DOM Parts syntax is syntactic sugar for creating comment nodes. There is a correspondence between comment nodes and markup syntax for XML independently of HTML.)

That is, how does DOM Parts relate to the DOM Consistency Design Principle?

[bathos]

[...] proposed DOM Parts syntax is syntactic sugar for creating comment nodes

Do you have a link to where that’s happening? And do you know whether that’s really the behavior being proposed (or if it’s e.g. just a temporary detail of a partial proof-of-concept?)

[hsivonen]

[...] proposed DOM Parts syntax is syntactic sugar for creating comment nodes

Do you have a link to where that’s happening?

See the meeting minutes about Chromium using comment nodes at least for prototyping.

[iteriani]

iirc, the comments made it easy to create anchor points (before/after) for https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts-Imperative.md#proposal, but this was before I realized the first argument for ChildNodePart was the parent. I previously thought it wouldn't apply since NodePart's first argument should be the single node.

That being said, it may be worth it to consider a different node type so that we can serialize back and forth more consistently.

[hsivonen]

It's worth noting that processing instructions are a node type that already exists for XML and is unused for HTML.

If the syntax starting with {{ and ending with }} it started with <? and ended with ?>, what would be worse and what would be better?

[mfreed7]

It's worth noting that processing instructions are a node type that already exists for XML and is unused for HTML.

If the syntax starting with {{ and ending with }} it started with <? and ended with ?>, what would be worse and what would be better?

That was the original concept - see tbondwilkinson/dom-parts#5. But there are issues:

1. It's an odd syntax, and for HTML the equivalent comments would need to work also (e.g. <!--?whatever?-->).
2. It doesn't work for attribute parts in any kind of ergonomic way.
3. <div {{}}> is just so much nicer than <?node-part?><div>, etc.

[justinfagnani]

One of the reasons to not use < is to allow parts where those characters are not allowed, such as unquoted attribute values and inside an opening tag. Using < would require a different syntax for those.

Here are the places we would like to allow parts:

Location	Example
Child node with no content	<div>{{}}</div>
Child node with content	<div>{{#}}<p>default content</p>{{/}}</div>
Unquoted attribute value	<div foo={{}}>
Quoted attribute value	<div foo="{{}} and {{}}">
Element	<div {{}}>

There is a related requirement that I would like to preserve, which is that you can make a valid parts-containing template HTML string from author-provided template strings without having to parse the author-provided strings. This is possible if we can join the author-provided template strings with a single joiner string.

This makes building a declarative HTML template system in JS very easy:

const html = (strings, ...values) => {html: strings.join('{{}}'), strings, values};

const example = html`<div ${behaviorA()} foo=${valueB}>${children}</div>`;
example.html; // <div {{}} foo={{}}>{{}}</div>