Re: [WICG/webcomponents] [dom-parts] Declarative syntax for creating DOM Parts (Issue #1003)

>FYI the syntax for ending \<template\> nodes is \</template\> not \<template end/\>.

Thanks, @tbondwilkinson , for your helpful explanation, and apologies for my lack of clarity.  I *think* my lack of clarity is my bad, as I think both you and @justinfagnani  may have read that the same way, which was not my intention.

Most especially, thanks for presenting your promising sounding ideas for an important advance forward for the web.

Given my track record, I doubt my clarifications below will help, but giving it a college try anyway.  Thanks for your patience!

I intended:

```html
<template prop=name start/>
```

to be shorthand for the proper HTML 5 syntax:

```html
<template prop=name start></template>
```

The purpose of the start and end attributes in my attempt for a 1-1 correspondence, was to provide a similar way as the processing instructions would provide as far as indicating where the range started and ended.  I didn't intend to imply that the browser currently recognizes those attributes in any way but thanks for the thoughtful tip :-).

I was literally proposing  a one-for-one swap of processing instruction comments with empty template elements (open/closed tags, with nothing inside, which I was hinting maybe the platform could allow self-closing template tags like it does for div's), we replace each and every processing instruction with precisely one self closing / empty template tags such as above.  You asked for alternatives, and that's the only alternative I could think of which wouldn't affect what the browser renders (and which works in the table element).  I like @EisenbergEffect 's suggestion that we be bolder and look at deeper changes to the browser if it makes sense.  I was perhaps being too timid in assuming that the alternatives had to involve minimal changes to how the browser currently renders.

Now if the processing instructions are meant, as part of this proposal, to add any additional information, other than simply saying "behold, a tag that you should turn into a part", like which field name from the host the data is coming from,  we could use the full power of HTML and provide that metadata as attributes (if we use self-closing or at least empty template tags with nothing inside in a one-for-one swap with each processing instruction), queryable by developers using css/xslt when hydrating the data out from server rendered content, and possibly other mischief like reconstructing the original template, and [search engines](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/itemprop) could also use that (standardized) notation to help index the content of web pages. 

Your comment above suggests that it *is* applicable to your proposal to include metadata in the processing instruction, but as I [read more](https://eisenbergeffect.medium.com/web-components-2023-spring-update-60c7873adf98) about the proposal, I'm not sure it would be, so maybe I'm reading too much into your proposal?  Meaning maybe the advantages I see of using a template element are moot, if we don't include such metadata in the instructions.  I guess I'm a little confused about that point.

Perhaps none of the uses cases I suggest above have been adopted (or even considered?) by the big frameworks, so I understand that as a result, my suggestion is a non-starter.  Again, those use cases are:

1.  Hydrating/extracting the data from the server-rendered HTML, so that we don't require a separate download of the data, which would need to be parsed and aligned with the corresponding HTML nodes.
2.  Reverse engineering the HTML to infer the template used to generate the HTML.
3.  Providing search engines the ability to correlate information displayed to the user with data attributes like they can do with microdata (itemprop attributes).

Both you (I think) and @justinfagnani  have indicated confidence that the cost of a single text node significantly exceeds the cost of a single empty / self-closing inert template HTML Element with nothing inside, thus it would impose a heavier load on the browser.  That was my suspicion, but a quick performance test I did indicated similar performance metrics, but I'm not enough of an expert (and lack the patience) to do a thorough analysis of the costs.  However, I think you and @justinfagnani  understand the inner workings of the browser enough to confidently predict that there is a significant performance gap, so I will leave that there.  I should note that at various points in the history of the web, there have been introduced tags/attributes that do help provide metadata, which surely comes at some cost to performance, so the question lingers in my mind, even if there is a cost to performance, if those benefits could outweigh the costs, but I'm clearly in a minority of one on this issue, so will leave it there.

As for the usefulness of the count, I remember now that my final intentions of using it were to help determine whether some content between an empty template element used to convey an opening section (similar to the opening processing instruction) and the closing open/closed/self-closing template tag indicating  where that section ends, if any of the content inside may have "given birth" to addition nodes, meaning a re-running of the binding needs to take place due to a suspicion of staleness.

I *think* if performance is of paramount, and if my suspicions are correct, that even processing instructions impose a small, linear cost, so that the more there are, the worse the performance, that it should be possible to "share" inner processing instructions, so that they serve both as the end of the previous section, and the beginning of the next.  Only the first and last nodes of a for-each loop would require beginning (and ending) comment nodes.  But again, probably not something the big frameworks have tried, so probably a non-starter to consider (I have no idea what they've tried and found wanting).

Getting into the intricacies of how the level could be used is probably not worth the effort to explain, as I think I was addressing use cases that appear to be of little interest to anyone else.

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

Message ID: <WICG/webcomponents/issues/1003/1532236386@github.com>