00:10:36 RRSAgent has joined #webcomponents 00:10:40 logging to https://www.w3.org/2025/11/10-webcomponents-irc 00:10:47 RRSAgent, make logs Public 00:10:48 please title this meeting ("meeting: ..."), astearns 00:11:08 rniwa has joined #webcomponents 00:11:08 Hoch has joined #webcomponents 00:11:08 jamesn has joined #webcomponents 00:11:08 kbabbitt has joined #webcomponents 00:11:08 anne has joined #webcomponents 00:11:08 JRJurman4 has joined #webcomponents 00:11:08 owen has joined #webcomponents 00:11:08 MichaelWarren has joined #webcomponents 00:11:08 sorvell has joined #webcomponents 00:11:08 justinf has joined #webcomponents 00:11:08 Kurt has joined #webcomponents 00:11:08 westbrook has joined #webcomponents 00:11:08 alisonmaher has joined #webcomponents 00:11:08 keithamus has joined #webcomponents 00:11:08 jcraig has joined #webcomponents 00:11:12 meeting: WCCG TPAC meeting 00:12:11 rniwa has joined #webcomponents 00:12:11 Hoch has joined #webcomponents 00:12:11 jamesn has joined #webcomponents 00:12:11 kbabbitt has joined #webcomponents 00:12:11 anne has joined #webcomponents 00:12:11 JRJurman4 has joined #webcomponents 00:12:11 owen has joined #webcomponents 00:12:11 MichaelWarren has joined #webcomponents 00:12:11 sorvell has joined #webcomponents 00:12:11 justinf has joined #webcomponents 00:12:11 Kurt has joined #webcomponents 00:12:11 westbrook has joined #webcomponents 00:12:11 alisonmaher has joined #webcomponents 00:12:11 keithamus has joined #webcomponents 00:12:11 jcraig has joined #webcomponents 00:13:32 rniwa has joined #webcomponents 00:13:32 Hoch has joined #webcomponents 00:13:32 jamesn has joined #webcomponents 00:13:32 kbabbitt has joined #webcomponents 00:13:32 JRJurman4 has joined #webcomponents 00:13:32 owen has joined #webcomponents 00:13:32 MichaelWarren has joined #webcomponents 00:13:32 sorvell has joined #webcomponents 00:13:32 justinf has joined #webcomponents 00:13:32 Kurt has joined #webcomponents 00:13:32 westbrook has joined #webcomponents 00:13:32 alisonmaher has joined #webcomponents 00:13:32 keithamus has joined #webcomponents 00:13:32 jcraig has joined #webcomponents 00:14:40 rniwa has joined #webcomponents 00:14:40 Hoch has joined #webcomponents 00:14:40 jamesn has joined #webcomponents 00:14:40 kbabbitt has joined #webcomponents 00:14:40 JRJurman4 has joined #webcomponents 00:14:40 owen has joined #webcomponents 00:14:40 MichaelWarren has joined #webcomponents 00:14:40 sorvell has joined #webcomponents 00:14:40 justinf has joined #webcomponents 00:14:40 Kurt has joined #webcomponents 00:14:40 westbrook has joined #webcomponents 00:14:40 alisonmaher has joined #webcomponents 00:14:40 keithamus has joined #webcomponents 00:14:40 jcraig has joined #webcomponents 00:15:54 rniwa has joined #webcomponents 00:15:54 Hoch has joined #webcomponents 00:15:54 jamesn has joined #webcomponents 00:15:54 kbabbitt has joined #webcomponents 00:15:54 JRJurman4 has joined #webcomponents 00:15:54 owen has joined #webcomponents 00:15:54 MichaelWarren has joined #webcomponents 00:15:54 sorvell has joined #webcomponents 00:15:54 justinf has joined #webcomponents 00:15:54 Kurt has joined #webcomponents 00:15:54 westbrook has joined #webcomponents 00:15:54 alisonmaher has joined #webcomponents 00:15:54 keithamus has joined #webcomponents 00:15:54 jcraig has joined #webcomponents 00:17:22 anne has joined #webcomponents 00:17:22 rniwa has joined #webcomponents 00:17:22 Hoch has joined #webcomponents 00:17:22 jamesn has joined #webcomponents 00:17:22 kbabbitt has joined #webcomponents 00:17:22 JRJurman4 has joined #webcomponents 00:17:22 owen has joined #webcomponents 00:17:22 MichaelWarren has joined #webcomponents 00:17:22 sorvell has joined #webcomponents 00:17:22 justinf has joined #webcomponents 00:17:22 Kurt has joined #webcomponents 00:17:22 westbrook has joined #webcomponents 00:17:22 alisonmaher has joined #webcomponents 00:17:22 keithamus has joined #webcomponents 00:17:22 jcraig has joined #webcomponents 00:17:36 lea has joined #webcomponents 00:17:53 https://github.com/WICG/webcomponents/issues/1114 00:18:34 topic: Reference Target 00:19:04 anne has joined #webcomponents 00:19:04 rniwa has joined #webcomponents 00:19:04 Hoch has joined #webcomponents 00:19:04 jamesn has joined #webcomponents 00:19:04 kbabbitt has joined #webcomponents 00:19:04 JRJurman4 has joined #webcomponents 00:19:04 owen has joined #webcomponents 00:19:04 MichaelWarren has joined #webcomponents 00:19:04 sorvell has joined #webcomponents 00:19:04 justinf has joined #webcomponents 00:19:04 Kurt has joined #webcomponents 00:19:04 westbrook has joined #webcomponents 00:19:04 alisonmaher has joined #webcomponents 00:19:04 keithamus has joined #webcomponents 00:19:04 jcraig has joined #webcomponents 00:20:12 scribenick: bkardell 00:20:28 alice: 00:20:36 Jayson has joined #webcomponents 00:20:55 alice: it's a small issue, it's about what happens if the reference target it invalid 00:20:58 adamargyle0 has joined #webcomponents 00:21:01 alice: what is the actual label.control here? 00:21:45 Alice: This example has a broken reference target, so it returns and logs null... There seemed to be consensus that that makes sense -- if you have comments? 00:22:01 annevk: I think it would make sense if it was consistent 00:23:26 Alice: right now as written, and I believe as implemented in the 3 engines, this logs null. I am no longer sure that that is right because ... there is linked issue - whatwg html 11577 where we were talking about adding more of idl getter/setter attributes - for htmlFor, etc 00:24:47 q+ 00:24:49 Alice: there was discussion in that issue which caused me to rethink this. That combined with some comments keithamus made -- it's kinda funky that we have to do this resolution of the reference target and then recursively resolve this and retarget back up... it's awkward in the spec language and implementation 00:25:30 saku9 has joined #webcomponents 00:25:54 alice: it's not clear what value that adds. Given that it is a getter and a setter - button.popovertarget = 'my popover' there is a oddness that you are not getting that back because it's invalid... it is more like a content attribute than the end point of an algorithm 00:26:19 sakito has joined #webcomponents 00:26:23 Jxck has joined #webcomponents 00:26:45 anqevk: that is not very compelling to me. The thing that made me change my mind was because of the lifetime of custom elements - you might set the idl attribute to an element that isn't yet initialized - the getter would return null, but then after it is initialized it would return something else 00:26:58 Alice: but this would not do that 00:27:20 annevk: we're agreeing on the result but for different reasons 00:28:43 westbrook: If set a popover target element as a div that doesn't have popover attribute - does it return the element? 00:29:00 emilio: yeah, it won't trigger the popover probably 00:29:29 emilio: in general it only returns the generic get attr associated element right now 00:29:54 ntim has joined #webcomponents 00:30:07 emilio: there's another question about whether it should return null if it could never be a popover - like if it is not an HTML element... 00:30:25 annevk: I think it probably should return an svg element because we might want to do svg custom elements 00:30:35 Alice: so I think it should return the element now 00:30:42 q- 00:30:45 OT, but: please, please SVG custom elements 00:31:02 emilio: I could go both ways but I think it makes sense 00:31:13 Alice: I'm not seeing the value in doing it the other way 00:31:41 emilio: especially the argument about "it's in the document but not initialized" seems pretty compelling as a reason 00:31:44 Ollie has joined #Webcomponents 00:32:08 q+ 00:32:19 Proposed Resolution: don't resolve the reference target when computing the value of the atto-associated element 00:32:41 Are we using the speaker queue? 00:33:10 annevk: ??? 00:33:16 Trying. 00:33:31 q? 00:34:11 annevk: HTMLLabelElement.control takes the same input 00:34:21 rniwa has joined #webcomponents 00:34:21 ack sorvell 00:34:21 q? 00:34:35 q+ 00:34:44 q+ 00:35:44 sorvell: my concern is a developer expectation with these things returning a value and that value serving the purpose that is expected. If I have a label control I expect that that is a thing that is label able. If I have a popup I expect that it has popup behavior. I worry about this violating that - it's not totally concrete but "user expectation" is a reason I would think might be useful for returning null. Lifecycle doesn't 00:35:44 concern me - it is common in web components. The dynamism is just something we have to deal with. I don't have a _super_ strong opinion - just a sense that developers expect it 00:37:19 rniwa: we want shadow root to stay consistent. you want to construct the shadow root lazily in some cases - we don't want the behavior and methods to be entirely different if it is connected or not - you want to have a separation of concerns between the IDL attribute and the shadow Dom status 00:38:33 present+ 00:38:36 q- 00:38:38 emilio: whether the element exists or not or is displayed- - htmlelement.control doesn't check if it is displayed. It will already return you its host. I don't think returning the internal element is an option, so I think it is probably more consient to not care about what the shadow root state is in any way. 00:38:42 +1 00:38:43 ack emilio 00:38:47 I think that seems ok to me then. 00:39:26 +1. No strong opinion either way, but I would find it surprising to have a shadow root element returned (or null if said shadow DOM element doesn't exist) since this is part of the element's public API 00:39:26 alice: (asking sorvel to clarify) 00:39:50 sorvell: Emilio just convinced me... we should do the simple thing and not care about what is in the shadow root 00:39:59 alice: I'm not sure where we landed on control... 00:40:10 emilio: I think it would be inconsistent if we didn't do the same? 00:40:59 annevk: control checks - it returns whatever label would click on... but now we're kind of changing how some of that works. I feel like now that we're rethink that, that should evolve along the same way 00:42:08 Alice: my thought on that is that if you have a fancy-input, you have a thing that wraps and input element - that is acting as an input - as a label able element.. the label is labeling the fancy-input by way of the input that it wraps. That's why I think label.control should return the fancy-input 00:42:24 annevk: Even if it isn't uprgraded 00:42:31 Alice: So it will optimistically lie? 00:42:45 westbrook: it's like what popover does 00:42:52 Alice: but that's a getter and a setter 00:43:17 annevk: it's been proposed and it would be very weird if for element returned one thing and control did not 00:44:07 keithamus: we could know that it could be a custom element based on the tagname 00:44:23 q+ 00:44:44 rniwa: it's conceivable that these getter only things gain a setter - we don't want to block ourselves in the future, so being consistent between them makes sense 00:44:52 https://github.com/whatwg/html/issues/11577 00:44:57 +1 rniwa 00:45:06 alisonmaher has joined #webcomponents 00:45:10 anne has joined #webcomponents 00:45:30 alice: it's conceivable these things get a setter, but it is completely within our control whether we do that or not 00:45:41 keithamus: is there a chromium use counter for control? 00:46:05 westbrook: it seems we're 70% or more in favor of the resolution we started with 00:46:38 q+ 00:46:44 alice: I don't have strong feelings about it, except I would like control to work the way it does now in checking whether the currently labeled element is labelable 00:46:52 ack alice 00:47:08 ack sorvell 00:47:27 q+ 00:47:36 sorvell: we should be consistent ... we should just assume if you've made the connection it's going to be satisfied at some point. 00:48:02 annevk: I like adding the set of labelleble element by just all custom elements 00:48:08 q- 00:48:11 q+ 00:48:23 Alice: so it is spec-wise labelleable if it has a dash 00:48:28 rniwa: potentially labelable 00:48:47 emilio: the check is already lying in a way 00:50:30 emilio: I think it would be weird if you pointed it to div id works differently than my-div does 00:51:08 emilio: if we get into Compat problems, I guess the tag name check is the less bad of the alternatives, but it is very unlikely that we hit any Compat issues with it. Maybe someone checking for form being null? 00:51:16 annevk: form was kind of over engineered 00:51:36 Emilio: we should remove the label able check - if we are constrained the tag name check 00:51:38 +1 to loosening the spec requirements around these things in general, if possible. 00:51:48 annevk: It feels a little weird, but I'm open to it 00:52:01 +1 to removing the checks for consistency 00:52:03 ack emilio 00:52:03 svk rmiq 00:53:08 PROPOSED: Loosen the type checks in HTMLLabelElement.control and .form if not compat constrained. Otherwise consider all potentially-custom-elements as labelable / potentially-a-form 00:53:22 +1 00:53:22 RESOLVED: Loosen the type checks in HTMLLabelElement.control and .form if not compat constrained. Otherwise consider all potentially-custom-elements as labelable / potentially-a-form 00:54:13 subtopic: Reference Target Phase 2 00:54:14 https://github.com/WICG/webcomponents/issues/1111 00:54:32 alice: referencetarget explainer originally referred to two phases (1 and 2) 00:54:57 ... phase 1 was the shadow root property that allowed you to redirect all attributes to a single element 00:55:08 ... like fancy-input use case is the obvious one 00:55:21 ... I want the host element to act as the element it's wrapping 00:55:42 ... it's a common pattern for button / input / popover / ... 00:56:02 ... phase 2 was the idea of a referencetarget map 00:56:13 ... the idea that the reference would be forwarded from the host depending on the attribute itself 00:56:39 ... so you'd have a catch-all referencetarget="input", then an aria-label to a different label 00:56:57 ... so I tried to rephrase the referencetarget explainer in terms of the use cases 00:57:06 ... phase 1 was pretty clear but phase 2 I'm less clear about 00:57:18 ... the cases I could come up with is aria-active-descendant 00:57:28 ... (for combobox-like things) 00:57:36 ydaniv has joined #webcomponents 00:57:42 present+ 00:57:45 ... so an input that has its active-descendant set to an option (like autocomplete option or what not) 00:57:58 ... the other one is aria-labeled/described/etc-bty 00:58:02 s/bty/by 00:58:31 ... so you're referring to the host and there's some content within the shadow root which you don't want to contribute to the name when it's referring to something else 00:58:48 ... so the question is are there other use cases other than those where referencing the host itself wouldn't work? 00:59:02 JakeA has joined #webcomponents 00:59:09 westbrook: at one point we got an example with card components 00:59:20 alice: was that an aria-text situation? 00:59:24 westbrook: yes 00:59:54 +1 to table map 00:59:57 ... but as a consumer of this, I think once we have referencetarget at large we'll start getting the map use cases 01:00:19 ... so proposal to table it for now because lacking referencetarget prevents you from thinking on those terms 01:00:40 +1 01:00:41 ... completely open to disagreement but might be better to table for now in terms of where to spend the time on 01:00:58 rniwa: tabling this until there's more evidence of other use cases sounds good 01:02:03 westbrook: seems like the chromium implementation is close to shippable 01:02:09 alice: yeah the others are prototype 01:02:36 alice: would be good what other use cases arise 01:02:38 Kurt has joined #webcomponents 01:02:53 Kurt has joined #webcomponents 01:02:54 keithamus: I'm a bit cautious of the syntax here so happy to defer 01:02:55 q+ 01:03:28 emilio: there's precedent for exportparts, syntax-wise 01:03:31 ack emilio 01:03:37 topic: @sheet 01:03:55 https://docs.google.com/presentation/d/10SagxoHUY9JBlMK2dXej1atndwQdpVEz0YmmJ52dLBg/edit?usp=sharing 01:06:22 mjackson has joined #webcomponents 01:06:36 mjackson has left #webcomponents 01:07:35 Kurt: I made also a lot of changes to the explainer and also a spec PR too 01:08:14 ... It's basically two attributes (type=module and specifier="foo") 01:08:18 ... to the 02:10:25

02:11:26 sakito has joined #webcomponents 02:12:55 kbabbitt has joined #webcomponents 02:12:59 template slides: https://docs.google.com/presentation/d/1r0AXWbP8RadIBuIFl-hC3O8G6YhTlguxKyluDIWil7g/edit?usp=sharing 02:13:19 ydaniv has joined #webcomponents 02:13:27 anne has joined #webcomponents 02:13:45 alisonmaher has joined #webcomponents 02:13:56 rniwa has joined #webcomponents 02:14:13 westbrook has joined #webcomponents 02:14:34 https://docs.google.com/document/d/1KeqMzuPHzHXTGR2zXmOHQydMUgVm2Y8onZHVmygAQFc/edit?tab=t.0 02:18:49 Kurt has joined #webcomponents 02:19:13 q? 02:19:59 saku has joined #webcomponents 02:21:06 Jxck has joined #webcomponents 02:21:31 topic: Templates 02:21:56 slides: https://docs.google.com/presentation/d/10SagxoHUY9JBlMK2dXej1atndwQdpVEz0YmmJ52dLBg/edit 02:21:59 q+ 02:22:21 justinf: [goes over the slides] 02:29:37 q+ 02:29:44 q+ 02:30:11 q+ 02:30:46 q+ 02:31:36 emilio: I think some of the scheduling stuff probably needs a fair bit of work to at least define relevant cases... the big question is when are these tasks run? 02:31:44 ... do they run on rAF? 02:31:58 ... I am assuming you want that by default, but you need to hook it up somewhere 02:32:16 .. then what happens when I move it around or something - should I update the order or..? 02:33:18 justinf: you don't want a child to render each time - you render asynchronous, so you can assume by the next micro task. The asunchornicity confuses a lot of people 02:33:47 ... nested tasks would get put on the queue and get executed in order so you can observe in the very next line that something was set 02:34:19 ... it's a new kind of timing - it's way earlier than animation frame or micro task. Way back I think we used to talk about nano task - this might be like that. Native elements can already do this 02:34:19 theparkagen has joined #webcomponents 02:34:32 q? 02:35:11 emilio: I am a bit concerned about standardizing the precise mutations that happen with these. If you have nested things and conditionals - are we creating a new subtree when that value flips? I think depending on the use case you might have different ideas 02:36:00 justinf: there is a particular model here which is that for a child part - where composition and nesting comes in - it checks to see whether it has already stamped out that template already, and if it has it can recurse and update those values 02:36:12 ... out of that all composition and control flow just fall out 02:36:26 ... if you flip back and forth on some tertiary you will rerender 02:36:34 How might timing relate to https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EventPhases/explainer.md 02:37:08 q? 02:37:17 emilio: isn't that a little confusing for developers - if they want an error message if it is valid, the tree changes - the original Dom from that condition isn't the same... there are ways around that I guess, you can talk about class or something 02:38:01 q- 02:38:01 q+ 02:38:04 justinf: this is the predominant model of web development - even though the things like react talk about diffing, if you you switch to a completely different v-dom fragment there's a really good chance you're going to replace that whole subdom 02:38:25 justinf: I don't think it is confusing, it is the main thing today 02:38:53 emilio: I guess it forces you to go fully to that model where your event listeners too are in there because otherwise your listeners can get destroyed too 02:39:13 ack emilio 02:39:16 justinf: there are ways to bind a node into a spot or refs ...(?? didn't get it, sorry) 02:39:44 anne has joined #webcomponents 02:39:57 adamargyle has joined #webcomponents 02:40:16 wrt scheduling, we already have the custom element reaction queue that might be a helpful model, at least for reference 02:40:17 MichaelWarren: The render() method would be in HTMLElement, but in the example would be ShadowRoot? 02:40:35 saku has joined #webcomponents 02:40:36 RRSAgent, draft minutes 02:40:37 I have made the request to generate https://www.w3.org/2025/11/10-webcomponents-minutes.html anne 02:40:47 sakito has joined #webcomponents 02:40:56 justinf: refs, imperatively created elements, etc would support some level of imperative event binding that didn't loose the binding when DOM fragments might change under the binding code unexpectedly. 02:40:58 RRSAgent, make logs public 02:41:07 ... it's very attractive to have a single function to hook for SSR 02:41:34 justinf: you are correct that the reason why lit can do ssr is because it just calls render() 02:41:39 q? 02:41:42 ... this could be a way to have a semi-universal ssr 02:41:46 ack MichaelWarren 02:42:05 MichaelWarren: if we have a templating engine it'd be good to have a standardized feature set 02:42:19 ... because frameworks that are running in servers need something else 02:42:39 justinf: another thing SSR engines would do is patching to patch the render() method 02:42:55 ... this can help users of SSR a ton 02:43:18 rniwa: I think we should probably try to make this approachable 02:43:34 ... I get that to get something comparable to what frameworks are doing we need all of it 02:43:40 ack rniwa 02:43:50 ... I think we need to make this smaller 02:44:09 justinf: I intentionally bypassed a lot of the HTML syntax 02:44:19 ... questions that showed up for DOM Parts 02:44:28 +1 to finding a minimally useful first step 02:44:35 ... maybe we could try to make this more of a map than a concrete proposal 02:44:36 +1 02:44:38 q- 02:44:42 ack ydaniv 02:44:59 q? 02:45:02 saku has joined #webcomponents 02:45:06 ydaniv: one of the biggest problems of JS templating today is something that I opened an issue with WHATWG is that they replace DOM and reduce user agency 02:45:14 ... one of the more important things for me is to be able to maintain state 02:45:19 ... kind of like moveBefore() 02:45:29 ... so if we could make that work somehow 02:45:43 ... if this could render dom but maintain my states that'd be a great winner 02:45:45 nicolo-ribaudo has joined #webcomponents 02:46:05 justinf: I think this would be useful to have in an issue 02:46:29 ... I think it'd be useful to use moveBefore() when possible 02:46:29 ... we should talk about ti 02:46:29 s/ti/it 02:46:42 trusktr has joined #webcomponents 02:47:33 justinf: One thing I'd like is to get a co-champion that could work on this 02:47:39 Hello! I had hand raised in the call. I wasn't able to join here until now. We for sure don't need Dom parts or scheduling up front to have templating. 02:48:55 trusktr: The TemplateResult could be passed dom, and schedule can use requestAnimationFrame(), DOM Parts can already be decoupled 02:49:07 justinf: parts are more of an spec concept rather than a public API 02:49:13 ... you need to explain the behavior 02:49:29 trusktr: DOM parts about framework authors and reactivity systems 02:49:36 ... they need that access to wire things together 02:49:46 ... the typical user doesn't care about how the DOM is updated 02:49:53 anne: You still need to specify how its done 02:50:04 ... the public API is usually the simpler bit 02:50:12 rniwa: yeah the processing model is the simplest part 02:50:17 denis has joined #webcomponents 02:50:20 ... foregoing parts would remove some issues 02:50:24 ... the main complexity is there 02:50:35 ... at the end of the day even if it's a black box it needs to be spec'd 02:50:57 trusktr: right but then there's only the question of the order, internally it'd be a setAttribute() call 02:51:11 rniwa: yeah but still needs to be well defined because MutationObserver can observe 02:51:32 justinf: yeah there's also the need to extend this 02:51:50 ... I really want to make this usable by framework authors 02:51:50 s/yeah the processing model is the simplest part/yeah the processing model is the hardest part/ 02:51:59 ... either existing or others, and the DOM Parts API is critical for that 02:52:38 https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md 02:52:43 topic: HTML modules 02:52:43 https://github.com/WICG/webcomponents/issues/1059 02:52:50 https://github.com/WICG/webcomponents/issues/645 02:52:51 https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md 02:54:23 Jayson: tldr is that we think this is still too early for standardizing HTML modules 02:54:42 ... I think HTML modules are different from HTML includes 02:55:00 ... People kinda understand it as HTML import 02:55:11 ... we need to solve that before but that's a separate topic 02:55:20 ... some customer problems we run into 02:55:48 ... the problems is repetitive HTML chunks in the DOM tree (can I define it once and just reference it through the doc) 02:56:18 ... reusing HTML in multiple places 02:56:30 ... All these are actually HTML include, not HTML modules 02:57:05 ... in our opinion HTML module should be a system that can import / export resources defined in HTML, that works fine with ES modules 02:57:40 q? 02:57:40 ... HTML module similarly we have html with and without scripts, style, template, custom element definitions, scoped custom element registry 02:57:48 q+ 02:58:32 q+ 02:59:12 For modules they want to make the contents dynamic 02:59:36 ... the dynamic part can range for content attributes / event handlers / etc 03:00:03 ... coming back to HTML modules, even if we standardized them right now it wouldn't solve the more common problems 03:00:32 ... e.g. modularizing a template is not possible r/n 03:00:59 ... so most of what customers actually ask for is html include 03:01:31 ... there's also an existing declarative partial update proposal 03:01:43 daiki has joined #webcomponents 03:01:44 ... that might be able to address some of the problems 03:01:48 q- 03:02:04 ydaniv has joined #webcomponents 03:02:22 ... I would be curious to look into how that proposal could interact with html modules 03:02:52 q+ 03:03:21 ... so our conclusion is that html modules is relatively low priority with all the other specially declarative capabilities that we are lacking 03:03:43 ... can be useful for ergonomics too but that should not be the main motivation 03:04:06 ... I believe in a few years when we have templates we could come back for HTML module to move this forward in an easier way 03:04:19 q+ 03:04:27 ... I think there are use cases that we haven't explored so if you have thoughts feel free to reach out 03:04:35 q? 03:04:36