Re: [WICG/webcomponents] Spring 2023 DOM Parts F2F (Issue #999)

@tbondwilkinson , thanks for the clear explanation on the child node range issue.

I'm sure I don't yet fully understand the processing instruction proposal, and that will quickly become apparent with my examples below, but the way I see our options is this:

Suppose we do use {{}} as out authoring tool.

And suppose our template looks like this:

```html
<template>Hello, {{name}}</template>
```

And say the host object is:

```JSON
{"name": "Adam"}
```

The server could generate:

```html
Hello, Adam
```

which would leave us unable to reverse engineer the output and update the name property, nor infer what the original template looked like.  Hence the need for some markers, which could include a "book-ended", "non-flat" child processing instruction:

A:

```html
Hello, <?child-node prop="name"?>Adam</?child-node?>
```

or a book-ended, non flat empty templates:

B:

```html
Hello <template prop=name start/>Adam<template end/>
```

or a "non-book-ended", "flat" representation with empty templates:

C:

```html
Hello <template prop=name node-count=1 level=0/>Adam
```

or a "non-book-ended", "flat" representation with processing instructions:

D:

```html
Hello <?child-node prop=name node-count=1 level=0 ?>Adam
```

I'm suggesting C and D *might* perform a little better, especially with many nodes, because it cuts the number of nodes in half (roughly).

Although I agree with full access to JS and sufficient grunt work, it is possible to extract out the same information with all of these, I'm suggesting that I have more options to do it more simply when I compare B with A.  With B I can query using CSS (in addition to XPath), and XSLT instructions *might* be simpler, because I'm not sure "attributes" inside the processing instruction come pre-parsed?  Same goes with JS manipulation. If the performance is the same, doesn't that give empty templates the edge as far as what we should prefer?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/999#issuecomment-1515989934
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/999/1515989934@github.com>