- From: Noam Rosenthal <notifications@github.com>
- Date: Wed, 19 Nov 2025 06:22:41 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1116/3552970942@github.com>
noamr left a comment (WICG/webcomponents#1116) @sorvell > > I don't think we're there yet, but I'd like to see us continue to explore further. > > I do. The point of this proposal is to be a targeted small addition to solve a specific problem that templating systems typically need: locating a range of interest. Comments and treewalkers are an existing way to do this. Given that, there's no new capabitility being suggested here and instead it's _all_ about performance. This is accurate. @EisenbergEffect > [@noamr](https://github.com/noamr) I thought it would be good to see another real example of what frameworks do, to help frame this conversation. Absolutely, thanks for that! My comment was to clarify some points about how it relates to the proposal. This framing is really helpful. > Yes, it boils down to element locators and "range" locators. So, what might be helpful is a single API that will give us me both. > I _think_ this is trending in the right direction, assuming the performance can be handled (actually quite a big assumption when competing against compiler optimizations), but I also think we need to explore more: > > * An API that finds all markers (both elements and comments) > * A standard way of embedding metadata (something like the OP's key/value suggestion) that the browser can parse and make available on demand. > * Nested/grouped ranges > > Since I have an existing framework that works and _is very fast_, and because that's true of a significant segment of the community, a proposal like this has to be strong enough for library authors to justify re-writing their compilers and runtimes and betting their businesses and community future on it. I don't think we're there yet, but I'd like to see us continue to explore further. Sure, that makes sense. The "very fast" aspect is key here - this proposal is an optimization for something that can already done (but inefficiently, by walking the tree). Where I am coming from to this proposal is the current work on [out of order streaming](https://github.com/whatwg/html/issues/11542). In that proposal, a `<template>` element can become a "patch" that modifies existing DOM using the `contentname` attribute. With addressable comments, we can add metadata to comments that gives them the same `contentname`, and patches can declaratively apply to them as well. So, I do agree about having some metadata in those comments - but I think we need to be selective about the kind of metadata the comment should expose (in the web platform level): - A simple key/value attribute syntax, so that userland doesn't have to string-parse - Something that makes it efficiently addressable (id/contentname) - Anything else required for patching (e.g. `contentrevision`) - Some way to bind two comments as an addressable "range" On top of that, we can think of templating features that apply *both* to elements and to non-element ranges, like: - managing attributes - ID rewriting - etc I think that if we had addressable comments with the above metadata (more or less), we could think of all the other templating features on top; while trying to think of them together makes the whole thing feel a bit too large in scope. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1116#issuecomment-3552970942 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1116/3552970942@github.com>
Received on Wednesday, 19 November 2025 14:22:45 UTC