IRC log of webcomponents on 2025-03-26

Timestamps are in UTC.

10:20:34 [RRSAgent]
RRSAgent has joined #webcomponents
10:20:38 [RRSAgent]
logging to https://www.w3.org/2025/03/26-webcomponents-irc
10:20:39 [breakout-bot]
RRSAgent, do not leave
10:20:40 [breakout-bot]
RRSAgent, this meeting spans midnight
10:20:40 [breakout-bot]
RRSAgent, make logs public
10:20:41 [breakout-bot]
Meeting: Scoped custom element registry
10:20:41 [breakout-bot]
Chair: Ryosuke Niwa
10:20:41 [breakout-bot]
Agenda: https://github.com/w3c/breakouts-day-2025/issues/18
10:20:41 [Zakim]
Zakim has joined #webcomponents
10:20:42 [breakout-bot]
Zakim, clear agenda
10:20:42 [Zakim]
agenda cleared
10:20:42 [breakout-bot]
Zakim, agenda+ Pick a scribe
10:20:44 [Zakim]
agendum 1 added
10:20:44 [breakout-bot]
Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
10:20:44 [Zakim]
agendum 2 added
10:20:44 [breakout-bot]
Zakim, agenda+ Goal of this session
10:20:45 [Zakim]
agendum 3 added
10:20:45 [breakout-bot]
Zakim, agenda+ Discussion
10:20:45 [Zakim]
agendum 4 added
10:20:46 [breakout-bot]
Zakim, agenda+ Next steps / where discussion continues
10:20:47 [Zakim]
agendum 5 added
10:20:47 [breakout-bot]
Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting
10:20:47 [Zakim]
agendum 6 added
10:20:47 [breakout-bot]
breakout-bot has left #webcomponents
10:27:40 [tidoust]
tidoust has joined #webcomponents
13:47:13 [bkardell_]
bkardell_ has joined #webcomponents
13:53:10 [keithamus]
keithamus has joined #webcomponents
13:53:10 [jcraig]
jcraig has joined #webcomponents
14:07:56 [annevk]
annevk has joined #webcomponents
14:58:42 [rniwa]
rniwa has joined #webcomponents
16:00:21 [oriol]
oriol has joined #webcomponents
16:06:31 [spectranaut_]
spectranaut_ has joined #webcomponents
16:24:28 [lea]
lea has joined #webcomponents
20:57:07 [xiaoqian]
xiaoqian has joined #webcomponents
21:04:46 [rniwa]
rniwa has joined #webcomponents
21:04:52 [rniwa]
rniwa has changed the topic to: DOM Parts
21:05:40 [masonf]
masonf has joined #webcomponents
21:05:45 [masonf]
scribenick: masonf
21:05:46 [simon]
simon has joined #webcomponents
21:05:52 [masonf]
present+
21:06:18 [rniwa]
present+
21:06:18 [xiaoqian]
zakim, start meeting
21:06:18 [Zakim]
RRSAgent, make logs Public
21:06:20 [Zakim]
please title this meeting ("meeting: ..."), xiaoqian
21:06:28 [xiaoqian]
meeting: DOM Parts
21:06:29 [smaug]
present+
21:06:33 [masonf]
present+
21:06:39 [masonf]
scribenick: masonf
21:06:59 [masonf]
rniwa: this is about DOM Parts. We worked with Google on this. Point to specific location in the DOM to update it easily.
21:07:20 [masonf]
rniwa: people use comment nodes as markers to do this, and use regular mutation stuff to mutate them. Need to maintain the comments, etc.
21:07:31 [masonf]
rniwa: performance benefit maybe. Based on Mason's experiment, no.
21:07:54 [xiaoqian]
present+ xiaoqian, dandclark, smaug, rniwa, Monhamed_Mansour
21:08:36 [masonf]
masonf: it depends. Some benchmarks it wins, some it loses, by 10-20%.
21:08:54 [masonf]
rniwa: are there other benefits? Might still be worth adding. Or best leave to userland.
21:09:19 [masonf]
rniwa: issue filed in DOM (link?) about document fragments whose nodes do not get removed when inserted
21:09:31 [masonf]
rniwa: like a wrapper documentfragment that stays in the tree
21:09:52 [masonf]
rniwa: similar to DOM parts, they're isomorphic. Different semantics, but same concepts and use cases.
21:10:27 [masonf]
rniwa: it came up that maintaining start/end comment nodes can be tricky. Those could be removed. DOM Parts - stays in the DOM tree.
21:10:42 [masonf]
rniwa: still ergonomic benefit.
21:11:53 [masonf]
masonf: we need to figure out how much to do. Losing some things (like maintaining references) was slower.
21:12:02 [masonf]
rniwa: different use cases need different featuresets
21:12:08 [masonf]
rniwa: though that makes it more complicated.
21:12:17 [masonf]
rniwa: Olli was concerned about complexity already.
21:12:34 [masonf]
rniwa: maybe there's a simple proposal that we can implement
21:12:53 [masonf]
smaug: the other documentfragment proposal might be simpler?
21:13:14 [masonf]
rniwa: proposal has a polyfill, so it is concrete to some extent
21:13:20 [masonf]
smaug: some open issues
21:13:57 [masonf]
masonf: a new node that looks like display:content
21:13:59 [masonf]
rniwa: also doesn't get seen by querySelector
21:14:15 [masonf]
rniwa: and doesn't affect rendering
21:14:40 [masonf]
rniwa: insert and remove nodes - same capacity
21:15:10 [masonf]
smaug: that might complicate things - new node type isn't really there but is there. But shadow dom - does it slot? Etc.
21:15:31 [masonf]
rniwa: we did consider this when we thought of DOM Parts. We came to the conclusion that the complexity is harder than it seems.
21:16:07 [masonf]
rniwa: once you try to nail down all the details, it might be more complicated than DOM Parts. Might be can of worms.
21:17:11 [masonf]
rniwa: new node type - selectors only work with elements, not Nodes, so maybe that's easy. Direct selectors parent>child might be tough.
21:17:20 [masonf]
rniwa - what about nesting these things
21:17:49 [masonf]
smaug: likely surprising performance consequences
21:18:13 [masonf]
rniwa: both approaches have downsides, particularly performance.
21:19:07 [masonf]
mmansour: for dom parts, placing variables inside. Let's say we want for loops and when conditions?
21:19:30 [masonf]
mmansour: todo app, put the template for that into the DOM - replace the variables. But let's say you want a todo list - many items.
21:19:45 [masonf]
mmansour: nested DOM Parts? Append each one?
21:20:31 [masonf]
mmansour: I'm building a web component framework - SSR in any language - isomorphic apps. Template parts works nicely. Define templates on serving time, on hydration - to add new item, take template from main document, add variables, done.
21:20:42 [masonf]
mmansour: for development, we need for loops and conditions.
21:21:32 [masonf]
masonf: JS object as state, arrays of strings, add those to DOM Parts
21:21:46 [masonf]
rniwa: this might be more template instantiation more than DOM Parts
21:22:14 [masonf]
rniwa: browser engine has native template engine - in the future. This (DOM Parts) is just a piece of that.
21:22:30 [masonf]
rniwa: template instantiation is hard, so break into pieces we can build
21:22:40 [masonf]
mmansour: because it's opinionated? Is it the syntax?
21:22:59 [masonf]
rniwa: that plus it's complicated. Need to do looping/conditionals, standardizing that plus customization is tough.
21:23:41 [masonf]
mmansour: I'll share proposal we (Edge) have with a WebUI framework. Treats HTML/JS/CSS as main foundations, rather than React.
21:24:10 [masonf]
mmansour: built in rust, looks through web components, generates entire declarative shadow DOM. Can be any language. Render entire website at once.
21:24:29 [masonf]
mmansour: tough part - we have to do JS manipulation to do for loops and conditionals.
21:24:49 [masonf]
mmansour: we believe react and angular are making the web slower, and if we use the platform, it'll be faster.
21:25:17 [masonf]
smaug: DOM Parts aren't better in terms of performance.
21:26:08 [masonf]
mmansour: I'll build a template for for loops, but that'll make it harder for the user. This is my template for todo list, a list of template parts, need to develop in a different way.
21:26:40 [masonf]
rniwa: is there still something implementable?
21:26:59 [masonf]
smaug: as of now, it doesn't look promising for anything
21:28:03 [masonf]
smaug: this would complicate things
21:29:51 [masonf]
masonf: maybe someone else can make it fast
21:30:09 [masonf]
masonf: I don't want my perf feedback to be the thing that kills this API
21:30:25 [masonf]
rniwa: maybe if the author feedback is good - if this helps the developer experience, maybe worth it.
21:30:39 [masonf]
rniwa: if this really is a building block toward template instantiation
21:30:59 [masonf]
rniwa: just like custom elements provided a way to define components, we could do the same thing for templates.
21:31:23 [masonf]
masonf: is this a building block toward template instantiation?
21:31:53 [masonf]
rniwa: we tried to make it that, yeah. But if there isn't value to DOM Parts by itself, maybe we can just skip ahead to template instantiation.
21:32:06 [masonf]
smaug: if it's template instantiation that people want, then maybe
21:32:49 [masonf]
masonf: some frameworks have components but don't use templates
21:33:17 [masonf]
rniwa: in DOM parts there seems to be a kernel of something useful. Ability to have a comment-like object that marks positions. Frameworks might like it.
21:33:27 [masonf]
rniwa: would that be beneficial to add to browsers?
21:33:39 [masonf]
rniwa: adds a bunch of complexity, but no performance gain, maybe not worth it.
21:34:42 [masonf]
rniwa: there are a ton of people on issue 736 - maybe shows interest in this concept.
21:35:09 [masonf]
rniwa: something useful. Not clear what people need exactly. Ask people on 736 - what are you looking for?
21:35:30 [masonf]
masonf: you might get lots of feedback.
21:36:17 [masonf]
taylore: question about DOM Parts - for ease of implementation - is it worth it? Just for organization purposes? Does it make the developer experience better?
21:36:53 [masonf]
taylore: maybe ship it but it won't improve performance. But we can use it as a building block. Provides another mechanism for developers to use.
21:37:25 [masonf]
rniwa: we've added things that improve ergonomics but not performance in the past. E.g. querySelector()
21:37:54 [masonf]
rniwa: need to balance the cost also
21:38:53 [masonf]
masonf: queryselector might be a good model - it got optimized over time. Maybe that'll happen for DOM Parts.
21:39:18 [masonf]
rniwa: for 736 - if we add DOM Parts or special documentfragment, will it get used in a lot of frameworks? If yes, let's pursue. If not, we shouldn't do this.
21:40:33 [masonf]
masonf: maybe don't ask generally on 736, but since we've decided DOM Parts and the special document fragment are similar complexity, just ask on 736 if they like DOM Parts as-is?
21:40:41 [masonf]
rniwa: we need more framework authors to get involved.
21:40:49 [masonf]
rniwa: maybe that's a good idea to ask on 736
21:41:00 [masonf]
smaug: ask what DOM operations are slow currently, maybe
21:41:06 [masonf]
smaug: then also ergonomics
21:41:42 [masonf]
rniwa: latest discussion on 736 was maybe formalize comment node hack. Identify comment nodes in a certain format and manipulate those.
21:42:18 [masonf]
smaug: API implementation might be simpler
21:43:06 [masonf]
masonf: the API isn't that complicated, keeping track of nodes is the hard part. So that sounds the same maybe?
21:43:39 [masonf]
rniwa: next step: go to 736 and ask about DOM Parts. Would people use it? Why not? Or why not but you would use the documentfragment thing?
21:43:48 [masonf]
rniwa: what's the difference - that's the interesting question
21:44:05 [masonf]
rniwa: it's easy to hand-wave a solution, but the devil is in the details
21:44:21 [masonf]
masonf: I agree
21:44:40 [masonf]
rniwa: I'll try to come up with a proposed question and share the question before asking
21:45:15 [masonf]
taylore: existing frameworks - if we do DOM Parts, frameworks will adopt that and abandon their existing implementations.
21:45:49 [masonf]
masonf: don't change the developer-facing side, but change the guts
21:45:59 [masonf]
rniwa: maybe more interoperable components could be built thought
21:46:03 [masonf]
s/thought/though
21:46:36 [masonf]
taylore: helpful because you might be able to build more things like mmansour - interoperable components
21:46:57 [masonf]
rniwa: I agree.
21:47:11 [masonf]
smaug: but the native parts implementation must be faster. They won't use if it isn't faster.
21:47:33 [masonf]
rniwa: for framework authors there needs to be a benefit. Just a different thing won't fly.
21:47:45 [masonf]
rniwa: we'll have to see
21:47:52 [masonf]
mmansour: is it slower because of looping through
21:49:37 [masonf]
rniwa: we have all JS knowledge, so it should be able to be faster
21:49:54 [masonf]
mmansour: queryselector the nodes and replace the content
21:51:23 [masonf]
{discussion about performance}
21:52:03 [masonf]
{discussion about lack of attendance here}
21:52:19 [masonf]
mmansour: to ask developers: if you have DOM Parts, and you're compiling templates, could you make it faster?
21:52:45 [masonf]
rniwa: if you're building on the server, you're doing a bunch of work anyway
21:53:05 [masonf]
mmansour: it'll be similar for template instantiation.
21:53:11 [masonf]
rniwa: maybe good segway
21:54:03 [masonf]
mmansour: the FAST framework (similar to Lit) - declarative templates. To support hydration for SSR web components, can't depend on JS templating. Do declarative templating, with "repeat" and "when" conditionals and loops.
21:54:50 [masonf]
mmansour: walking through template tag to see where the special conditions are. Do a build step - produce a JS representation, and maybe template parts help. Walk character by character to parse the template string.
21:55:32 [masonf]
rniwa: if you have to do that client-side, DOM Parts helps. Avoid tree walks. But if you're server-side compiling, benefits diminish.
21:55:57 [masonf]
mmansour: I'll ping the FAST people
21:56:07 [masonf]
5 minute break
21:57:00 [xiaoqian]
RRSAgent, make minutes
21:57:02 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/03/26-webcomponents-minutes.html xiaoqian
22:00:41 [rniwa]
rniwa has changed the topic to: Template Instantiation
22:01:02 [rniwa]
RRSAgent: start meeting
22:01:02 [RRSAgent]
I'm logging. I don't understand 'start meeting', rniwa. Try /msg RRSAgent help
22:02:18 [rniwa]
Zakim, start meeting
22:02:18 [Zakim]
RRSAgent, make logs Public
22:02:19 [Zakim]
please title this meeting ("meeting: ..."), rniwa
22:02:39 [rniwa]
meeting: Template Instantiation
22:04:02 [masonf]
rniwa: this is the ultimate crown jewel - create templates and make the result more usable and mutable via easy JA
22:04:06 [masonf]
s/JA/JS
22:04:19 [masonf]
rniwa: a while ago we (Apple) made a proposal
22:04:31 [rniwa]
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md
22:05:04 [masonf]
rniwa: it's been a while. Would be good to come back to it soon. Template engine use case seems clear.
22:05:28 [masonf]
rniwa: want to replace content and update content. Bidirectional bindings. DOM to JS and back
22:05:32 [Jamie]
Jamie has joined #webcomponents
22:05:42 [masonf]
rniwa: allow for loops and conditionals in template engines
22:06:08 [masonf]
rniwa: original proposal was to make a template processor. Hook for the library author to hook into template engine in the browser and customize behavior.
22:06:15 [masonf]
rniwa: callbacks for template clone, etc.
22:06:50 [masonf]
rniwa: that stuff seems still useful because the semantics need to be delegates to the template engine, because that would be overkill and too opinionated.
22:07:02 [masonf]
rniwa: questions?
22:07:26 [masonf]
mmansour: two ways to do that. 1 is do everything declaratively in the DOM. 2 is build time produce JS representation of template. 2 is react.
22:07:32 [masonf]
mmansour: which one is faster?
22:07:58 [masonf]
mmansour: assume startup performance isn't an issue. Now you need to add another item to the DOM, like a banner. Which is faster?
22:08:10 [masonf]
mmansour: is precompiled JS always faster?
22:08:27 [masonf]
rniwa: we haven't done perofrmance testing extensively.
22:08:47 [masonf]
{the answer might be here? https://github.com/krausest/js-framework-benchmark)
22:09:23 [masonf]
rniwa: when you make a big list, you have a lot of repetition. You need to repeat all of the <li> elements.
22:09:43 [masonf]
rniwa: potential benefit: you could say I just want 10 <li>'s and only transfer one of them.
22:10:35 [masonf]
mmansour: I've prototyped this kind of thing. Yes, if you build a web component with 1000 items. Yes, the template is repeated 1000 times. You're assuming you're using slots for things like the name, etc. You're dependant on slots.
22:10:56 [masonf]
mmansour: slots are only element based. You can't slot things like an attribute.
22:11:21 [masonf]
mmansour: broken for my use case. I want 1000 components, and need to replace the attributes for each.
22:11:28 [masonf]
rniwa: attributePart is exactly that
22:11:54 [masonf]
rniwa: drive update from JS. Because attributes are exposed as a JS property, that's do-able.
22:12:28 [masonf]
rniwa: all updates come from JS object. You can update attribute or content value.
22:12:40 [masonf]
mmansour: how without JS?
22:12:57 [masonf]
rniwa: you're relying on object attributes - what you're using to render the component.
22:13:18 [masonf]
mmansour: if you're SSRing 1000 contacts. You want each one to have a tel attribute. How do you render that?
22:13:32 [masonf]
rniwa: embed a JSON object and render from the JSON
22:13:52 [masonf]
rniwa: can be implemented in the browser, so avoid a flash
22:14:09 [masonf]
mmansour: isn't there a cost to switching to/from JS?
22:14:27 [masonf]
rniwa: want a blob of JSON, then a bunch of templates that all use that single JSON to generate the DOM tree
22:14:41 [masonf]
mmansour: that's the proposal?
22:14:44 [masonf]
rniwa: yes
22:15:08 [masonf]
rniwa: initial proposal maybe doesn't have all of that, but that's where we want to go.
22:15:22 [masonf]
rniwa: one feedback from Mozilla was that it was too complex. That's why we wanted DOM Parts first.
22:15:49 [masonf]
rniwa: because DOM Parts wasn't necessarily a performance win, maybe come back to this
22:15:56 [masonf]
rniwa: might be a win
22:16:57 [masonf]
mmansour: I do like what you said. One thing: <slot>s if you render a header slot, then a bunch of HTML and then another default slot. When you render the page. It'll render the template and slots without the children, then the children.
22:17:11 [masonf]
mmansour: if you use slots a lot, that's bad.
22:17:42 [masonf]
Slots are streamable - replace the slot and it changes. Slots - no attributes - just entire elements can be replaced.
22:18:06 [masonf]
mmansour: managing slots was good, except for no attribute support.
22:18:34 [masonf]
mmansour: but I like the JSON at the start, templates at the end approach. I don't know how lists work. One for every element item.
22:18:47 [masonf]
rniwa: lists we didn't tackle in the proposal yet. Rest was complicated enough.
22:19:10 [masonf]
rniwa: the browser can tackle the list. Then we just have a blob of data and some templates and the browser constructs the DOM tree.
22:19:29 [masonf]
rniwa: should be a performance win
22:19:54 [masonf]
mmansour: what about experimentation. Swap one button out for another button component, without reloading the page.
22:20:13 [masonf]
rniwa: dynamic reloading? For that, scoped custom element registries is best
22:20:25 [masonf]
mmansour: refresh the template in real time?
22:20:40 [masonf]
rniwa: yeah, just replace the template and the JSON populates the templates automatically
22:20:57 [masonf]
mmansour: good for developer hot refresh use cases
22:21:06 [masonf]
rniwa: much faster than diffing virtual DOM also
22:21:29 [masonf]
mmansour: ship it
22:21:38 [masonf]
rniwa: in a perfect world, great
22:21:44 [masonf]
mmansour: svg support?
22:22:23 [masonf]
rniwa: in theory yes. One template with N instances, each referring back to the original.
22:23:01 [masonf]
mmansour: SVGs get heavyweight everytually. You can use <use>, but can't do that cross-root.
22:23:20 [masonf]
mmansour: would you get a new copy of the SVG?
22:23:28 [masonf]
rniwa: yes, duplicate the tree, so not shared.
22:23:55 [masonf]
rniwa: but automatic. So if you update the top level template, the rest propagates automatically.
22:24:37 [masonf]
rniwa: maybe we go back to the drawing board that we can build directly, without going through DOM Parts first.
22:25:03 [masonf]
dandclark: I agree finding smaller pieces is a good idea, but I'm not sure which part
22:26:08 [masonf]
masonf: DOM Parts is lower level, so it doesn't have most of this stuff.
22:26:37 [masonf]
mmansour: I'd love to have this
22:27:09 [masonf]
mmansour: what can you strip out of the proposal to make it shippable?
22:27:09 [rniwa]
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md
22:27:19 [masonf]
rniwa: go to section 3.1
22:27:38 [masonf]
templateInstance, and an update function
22:27:59 [masonf]
rniwa: keep calling update to update the DOM tree, from the JS object. Automatically replace mustache syntax with JS content.
22:28:18 [masonf]
mmansour: I used a dotted syntax for my framework
22:28:51 [masonf]
mmansour: this is flattened JSON structure, right? What if you have a large user object, user.name - do we support structures?
22:29:10 [masonf]
rniwa: that's the intent. Not in the proposal. But chaining support is natural.
22:29:19 [masonf]
rniwa: if you go to 3.2, there are template parts, and custom callbacks
22:29:49 [masonf]
mmansour: maybe that's something that can be chopped out. Not needed for SSR.
22:30:15 [masonf]
mmansour: for SSR we just need to hydrate and remove duplicate nodes
22:30:34 [masonf]
rniwa: section 3.3 is conditionals and loops.
22:30:45 [masonf]
mmansour: you used handlebars
22:31:02 [masonf]
rniwa: go to just before section 4 - use the directive attribute,
22:31:49 [masonf]
mmansour: I just used template called for, etc. What about explicit tags like <for each>
22:32:28 [masonf]
mmansour: lots of tooling with ASTs - if you see a non-tag character, syntax highlighting breaks, etc.
22:32:43 [masonf]
rniwa: nice to bring it to the platform, IDEs will get updated so this gets recognized.
22:33:01 [masonf]
rniwa: ergonomic benefit of bringing this to the web
22:33:15 [masonf]
mmansour: no includes any more, just use components
22:33:31 [masonf]
mmansour: in handlebars, you include template. Web components don't need that.
22:34:37 [masonf]
rniwa: we want to tackle this because we think it'll benefit the platform.
22:35:09 [masonf]
mmansour: 3.2 can be cut. 3.3 just needs more clarity on what's needed. 4 is how it works.
22:35:39 [masonf]
mmansour: template parts with conditions and instances. Dan, can you implement that?
22:36:20 [masonf]
mmansour: I wonder what happens with React - they won't use this. FAST, Lit, regular developers who don't use frameworks - they will
22:36:33 [masonf]
rniwa: if there is a performance win, others might use it also, as a compile target.
22:36:55 [masonf]
rniwa: once you have looping and conditionals, server side rendering will be much better than anything today.
22:37:43 [masonf]
mmansour: at build time in Rust, we create a native handler that renders the entire page. On the runtime side, it'll call that function. It's just a bunch of functions concatenated, with holes in the middle for data
22:38:48 [masonf]
rniwa: yep, that's what we were going for - this might change the web in a good way. Let the platform do the work.
22:39:33 [masonf]
mmansour: I trust the web platform fro rendering and interactivity, but not good at waiting for JS to load
22:40:08 [masonf]
dandclark: we've been involved, but not currently trying to drive it
22:40:23 [masonf]
rniwa: we made the proposal, but haven't put effort into it really. Doing other things.
22:40:40 [masonf]
rniwa: we're now interested in putting effort into this area.
22:40:50 [masonf]
mmansour: I can help also, I'm passionate about this stuff.
22:41:24 [masonf]
rniwa: there seems to be some goodness here that might be worth doing.
22:41:34 [masonf]
rniwa: we need to understand the benefits also.
22:42:22 [masonf]
masonf: rniwa maybe implement it?
22:42:33 [masonf]
rniwa: there's a polyfill somewhere, perhaps dig that up and update it?
22:42:41 [masonf]
rniwa: prototyping would be a good idea
22:43:56 [masonf]
rniwa: every framework invents templating, why isn't this in the browser?
22:44:10 [masonf]
mmansour: next thing people will ask is data bindings
22:44:47 [masonf]
mmansour: after that, reflection - getting API schema from web components
22:45:28 [masonf]
rniwa: once we implement, more things will come out, naturally.
22:50:47 [masonf]
{discussion of scoped custom element registries}
22:55:01 [xiaoqian]
RRSAgent, make minutes
22:55:02 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/03/26-webcomponents-minutes.html xiaoqian
04:55:30 [fantasai]
fantasai has left #webcomponents
09:40:51 [tidoust]
RRSAgent, bye
09:40:51 [RRSAgent]
I see no action items