IRC log of webcomponents on 2025-11-10

Timestamps are in UTC.

00:10:36 [RRSAgent]
RRSAgent has joined #webcomponents
00:10:40 [RRSAgent]
logging to https://www.w3.org/2025/11/10-webcomponents-irc
00:10:47 [Zakim]
RRSAgent, make logs Public
00:10:48 [Zakim]
please title this meeting ("meeting: ..."), astearns
00:11:08 [rniwa]
rniwa has joined #webcomponents
00:11:08 [Hoch]
Hoch has joined #webcomponents
00:11:08 [jamesn]
jamesn has joined #webcomponents
00:11:08 [kbabbitt]
kbabbitt has joined #webcomponents
00:11:08 [anne]
anne has joined #webcomponents
00:11:08 [JRJurman4]
JRJurman4 has joined #webcomponents
00:11:08 [owen]
owen has joined #webcomponents
00:11:08 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:11:08 [sorvell]
sorvell has joined #webcomponents
00:11:08 [justinf]
justinf has joined #webcomponents
00:11:08 [Kurt]
Kurt has joined #webcomponents
00:11:08 [westbrook]
westbrook has joined #webcomponents
00:11:08 [alisonmaher]
alisonmaher has joined #webcomponents
00:11:08 [keithamus]
keithamus has joined #webcomponents
00:11:08 [jcraig]
jcraig has joined #webcomponents
00:11:12 [emilio]
meeting: WCCG TPAC meeting
00:12:11 [rniwa]
rniwa has joined #webcomponents
00:12:11 [Hoch]
Hoch has joined #webcomponents
00:12:11 [jamesn]
jamesn has joined #webcomponents
00:12:11 [kbabbitt]
kbabbitt has joined #webcomponents
00:12:11 [anne]
anne has joined #webcomponents
00:12:11 [JRJurman4]
JRJurman4 has joined #webcomponents
00:12:11 [owen]
owen has joined #webcomponents
00:12:11 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:12:11 [sorvell]
sorvell has joined #webcomponents
00:12:11 [justinf]
justinf has joined #webcomponents
00:12:11 [Kurt]
Kurt has joined #webcomponents
00:12:11 [westbrook]
westbrook has joined #webcomponents
00:12:11 [alisonmaher]
alisonmaher has joined #webcomponents
00:12:11 [keithamus]
keithamus has joined #webcomponents
00:12:11 [jcraig]
jcraig has joined #webcomponents
00:13:32 [rniwa]
rniwa has joined #webcomponents
00:13:32 [Hoch]
Hoch has joined #webcomponents
00:13:32 [jamesn]
jamesn has joined #webcomponents
00:13:32 [kbabbitt]
kbabbitt has joined #webcomponents
00:13:32 [JRJurman4]
JRJurman4 has joined #webcomponents
00:13:32 [owen]
owen has joined #webcomponents
00:13:32 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:13:32 [sorvell]
sorvell has joined #webcomponents
00:13:32 [justinf]
justinf has joined #webcomponents
00:13:32 [Kurt]
Kurt has joined #webcomponents
00:13:32 [westbrook]
westbrook has joined #webcomponents
00:13:32 [alisonmaher]
alisonmaher has joined #webcomponents
00:13:32 [keithamus]
keithamus has joined #webcomponents
00:13:32 [jcraig]
jcraig has joined #webcomponents
00:14:40 [rniwa]
rniwa has joined #webcomponents
00:14:40 [Hoch]
Hoch has joined #webcomponents
00:14:40 [jamesn]
jamesn has joined #webcomponents
00:14:40 [kbabbitt]
kbabbitt has joined #webcomponents
00:14:40 [JRJurman4]
JRJurman4 has joined #webcomponents
00:14:40 [owen]
owen has joined #webcomponents
00:14:40 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:14:40 [sorvell]
sorvell has joined #webcomponents
00:14:40 [justinf]
justinf has joined #webcomponents
00:14:40 [Kurt]
Kurt has joined #webcomponents
00:14:40 [westbrook]
westbrook has joined #webcomponents
00:14:40 [alisonmaher]
alisonmaher has joined #webcomponents
00:14:40 [keithamus]
keithamus has joined #webcomponents
00:14:40 [jcraig]
jcraig has joined #webcomponents
00:15:54 [rniwa]
rniwa has joined #webcomponents
00:15:54 [Hoch]
Hoch has joined #webcomponents
00:15:54 [jamesn]
jamesn has joined #webcomponents
00:15:54 [kbabbitt]
kbabbitt has joined #webcomponents
00:15:54 [JRJurman4]
JRJurman4 has joined #webcomponents
00:15:54 [owen]
owen has joined #webcomponents
00:15:54 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:15:54 [sorvell]
sorvell has joined #webcomponents
00:15:54 [justinf]
justinf has joined #webcomponents
00:15:54 [Kurt]
Kurt has joined #webcomponents
00:15:54 [westbrook]
westbrook has joined #webcomponents
00:15:54 [alisonmaher]
alisonmaher has joined #webcomponents
00:15:54 [keithamus]
keithamus has joined #webcomponents
00:15:54 [jcraig]
jcraig has joined #webcomponents
00:17:22 [anne]
anne has joined #webcomponents
00:17:22 [rniwa]
rniwa has joined #webcomponents
00:17:22 [Hoch]
Hoch has joined #webcomponents
00:17:22 [jamesn]
jamesn has joined #webcomponents
00:17:22 [kbabbitt]
kbabbitt has joined #webcomponents
00:17:22 [JRJurman4]
JRJurman4 has joined #webcomponents
00:17:22 [owen]
owen has joined #webcomponents
00:17:22 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:17:22 [sorvell]
sorvell has joined #webcomponents
00:17:22 [justinf]
justinf has joined #webcomponents
00:17:22 [Kurt]
Kurt has joined #webcomponents
00:17:22 [westbrook]
westbrook has joined #webcomponents
00:17:22 [alisonmaher]
alisonmaher has joined #webcomponents
00:17:22 [keithamus]
keithamus has joined #webcomponents
00:17:22 [jcraig]
jcraig has joined #webcomponents
00:17:36 [lea]
lea has joined #webcomponents
00:17:53 [bkardell]
https://github.com/WICG/webcomponents/issues/1114
00:18:34 [emilio]
topic: Reference Target
00:19:04 [anne]
anne has joined #webcomponents
00:19:04 [rniwa]
rniwa has joined #webcomponents
00:19:04 [Hoch]
Hoch has joined #webcomponents
00:19:04 [jamesn]
jamesn has joined #webcomponents
00:19:04 [kbabbitt]
kbabbitt has joined #webcomponents
00:19:04 [JRJurman4]
JRJurman4 has joined #webcomponents
00:19:04 [owen]
owen has joined #webcomponents
00:19:04 [MichaelWarren]
MichaelWarren has joined #webcomponents
00:19:04 [sorvell]
sorvell has joined #webcomponents
00:19:04 [justinf]
justinf has joined #webcomponents
00:19:04 [Kurt]
Kurt has joined #webcomponents
00:19:04 [westbrook]
westbrook has joined #webcomponents
00:19:04 [alisonmaher]
alisonmaher has joined #webcomponents
00:19:04 [keithamus]
keithamus has joined #webcomponents
00:19:04 [jcraig]
jcraig has joined #webcomponents
00:20:12 [bkardell]
scribenick: bkardell
00:20:28 [bkardell]
alice:
00:20:36 [Jayson]
Jayson has joined #webcomponents
00:20:55 [bkardell]
alice: it's a small issue, it's about what happens if the reference target it invalid
00:20:58 [adamargyle0]
adamargyle0 has joined #webcomponents
00:21:01 [bkardell]
alice: what is the actual label.control here?
00:21:45 [bkardell]
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 [bkardell]
annevk: I think it would make sense if it was consistent
00:23:26 [bkardell]
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 [sorvell]
q+
00:24:49 [bkardell]
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]
saku9 has joined #webcomponents
00:25:54 [bkardell]
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]
sakito has joined #webcomponents
00:26:23 [Jxck]
Jxck has joined #webcomponents
00:26:45 [bkardell]
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 [bkardell]
Alice: but this would not do that
00:27:20 [bkardell]
annevk: we're agreeing on the result but for different reasons
00:28:43 [bkardell]
westbrook: If set a popover target element as a div that doesn't have popover attribute - does it return the element?
00:29:00 [bkardell]
emilio: yeah, it won't trigger the popover probably
00:29:29 [bkardell]
emilio: in general it only returns the generic get attr associated element right now
00:29:54 [ntim]
ntim has joined #webcomponents
00:30:07 [bkardell]
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 [bkardell]
annevk: I think it probably should return an svg element because we might want to do svg custom elements
00:30:35 [bkardell]
Alice: so I think it should return the element now
00:30:42 [sorvell]
q-
00:30:45 [justinf]
OT, but: please, please SVG custom elements
00:31:02 [bkardell]
emilio: I could go both ways but I think it makes sense
00:31:13 [bkardell]
Alice: I'm not seeing the value in doing it the other way
00:31:41 [bkardell]
emilio: especially the argument about "it's in the document but not initialized" seems pretty compelling as a reason
00:31:44 [Ollie]
Ollie has joined #Webcomponents
00:32:08 [sorvell]
q+
00:32:19 [bkardell]
Proposed Resolution: don't resolve the reference target when computing the value of the atto-associated element
00:32:41 [sorvell]
Are we using the speaker queue?
00:33:10 [bkardell]
annevk: ???
00:33:16 [westbrook]
Trying.
00:33:31 [lea]
q?
00:34:11 [emilio]
annevk: HTMLLabelElement.control takes the same input
00:34:21 [rniwa]
rniwa has joined #webcomponents
00:34:21 [emilio]
ack sorvell
00:34:21 [rniwa]
q?
00:34:35 [rniwa]
q+
00:34:44 [emilio]
q+
00:35:44 [bkardell]
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 [bkardell]
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 [bkardell]
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 [lea]
present+
00:38:36 [rniwa]
q-
00:38:38 [bkardell]
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 [frehner]
+1
00:38:43 [keithamus]
ack emilio
00:38:47 [sorvell]
I think that seems ok to me then.
00:39:26 [lea]
+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 [bkardell]
alice: (asking sorvel to clarify)
00:39:50 [bkardell]
sorvell: Emilio just convinced me... we should do the simple thing and not care about what is in the shadow root
00:39:59 [bkardell]
alice: I'm not sure where we landed on control...
00:40:10 [bkardell]
emilio: I think it would be inconsistent if we didn't do the same?
00:40:59 [bkardell]
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 [bkardell]
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 [bkardell]
annevk: Even if it isn't uprgraded
00:42:31 [bkardell]
Alice: So it will optimistically lie?
00:42:45 [bkardell]
westbrook: it's like what popover does
00:42:52 [bkardell]
Alice: but that's a getter and a setter
00:43:17 [bkardell]
annevk: it's been proposed and it would be very weird if for element returned one thing and control did not
00:44:07 [bkardell]
keithamus: we could know that it could be a custom element based on the tagname
00:44:23 [alice]
q+
00:44:44 [bkardell]
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 [keithamus]
https://github.com/whatwg/html/issues/11577
00:44:57 [astearns]
+1 rniwa
00:45:06 [alisonmaher]
alisonmaher has joined #webcomponents
00:45:10 [anne]
anne has joined #webcomponents
00:45:30 [bkardell]
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 [bkardell]
keithamus: is there a chromium use counter for control?
00:46:05 [bkardell]
westbrook: it seems we're 70% or more in favor of the resolution we started with
00:46:38 [sorvell]
q+
00:46:44 [bkardell]
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 [bkardell]
ack alice
00:47:08 [bkardell]
ack sorvell
00:47:27 [MichaelWarren]
q+
00:47:36 [bkardell]
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 [bkardell]
annevk: I like adding the set of labelleble element by just all custom elements
00:48:08 [MichaelWarren]
q-
00:48:11 [emilio]
q+
00:48:23 [bkardell]
Alice: so it is spec-wise labelleable if it has a dash
00:48:28 [bkardell]
rniwa: potentially labelable
00:48:47 [bkardell]
emilio: the check is already lying in a way
00:50:30 [bkardell]
emilio: I think it would be weird if you pointed it to div id works differently than my-div does
00:51:08 [bkardell]
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 [bkardell]
annevk: form was kind of over engineered
00:51:36 [bkardell]
Emilio: we should remove the label able check - if we are constrained the tag name check
00:51:38 [sorvell]
+1 to loosening the spec requirements around these things in general, if possible.
00:51:48 [bkardell]
annevk: It feels a little weird, but I'm open to it
00:52:01 [MichaelWarren]
+1 to removing the checks for consistency
00:52:03 [keithamus]
ack emilio
00:52:03 [emilio]
svk rmiq
00:53:08 [emilio]
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 [keithamus]
+1
00:53:22 [emilio]
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 [emilio]
subtopic: Reference Target Phase 2
00:54:14 [emilio]
https://github.com/WICG/webcomponents/issues/1111
00:54:32 [emilio]
alice: referencetarget explainer originally referred to two phases (1 and 2)
00:54:57 [emilio]
... phase 1 was the shadow root property that allowed you to redirect all attributes to a single element
00:55:08 [emilio]
... like fancy-input use case is the obvious one
00:55:21 [emilio]
... I want the host element to act as the element it's wrapping
00:55:42 [emilio]
... it's a common pattern for button / input / popover / ...
00:56:02 [emilio]
... phase 2 was the idea of a referencetarget map
00:56:13 [emilio]
... the idea that the reference would be forwarded from the host depending on the attribute itself
00:56:39 [emilio]
... so you'd have a catch-all referencetarget="input", then an aria-label to a different label
00:56:57 [emilio]
... so I tried to rephrase the referencetarget explainer in terms of the use cases
00:57:06 [emilio]
... phase 1 was pretty clear but phase 2 I'm less clear about
00:57:18 [emilio]
... the cases I could come up with is aria-active-descendant
00:57:28 [emilio]
... (for combobox-like things)
00:57:36 [ydaniv]
ydaniv has joined #webcomponents
00:57:42 [ydaniv]
present+
00:57:45 [emilio]
... so an input that has its active-descendant set to an option (like autocomplete option or what not)
00:57:58 [emilio]
... the other one is aria-labeled/described/etc-bty
00:58:02 [emilio]
s/bty/by
00:58:31 [emilio]
... 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 [emilio]
... so the question is are there other use cases other than those where referencing the host itself wouldn't work?
00:59:02 [JakeA]
JakeA has joined #webcomponents
00:59:09 [emilio]
westbrook: at one point we got an example with card components
00:59:20 [emilio]
alice: was that an aria-text situation?
00:59:24 [emilio]
westbrook: yes
00:59:54 [MichaelWarren]
+1 to table map
00:59:57 [emilio]
... 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 [emilio]
... so proposal to table it for now because lacking referencetarget prevents you from thinking on those terms
01:00:40 [sorvell]
+1
01:00:41 [emilio]
... completely open to disagreement but might be better to table for now in terms of where to spend the time on
01:00:58 [emilio]
rniwa: tabling this until there's more evidence of other use cases sounds good
01:02:03 [emilio]
westbrook: seems like the chromium implementation is close to shippable
01:02:09 [emilio]
alice: yeah the others are prototype
01:02:36 [emilio]
alice: would be good what other use cases arise
01:02:38 [Kurt]
Kurt has joined #webcomponents
01:02:53 [Kurt]
Kurt has joined #webcomponents
01:02:54 [emilio]
keithamus: I'm a bit cautious of the syntax here so happy to defer
01:02:55 [emilio]
q+
01:03:28 [emilio]
emilio: there's precedent for exportparts, syntax-wise
01:03:31 [emilio]
ack emilio
01:03:37 [emilio]
topic: @sheet
01:03:55 [Kurt]
https://docs.google.com/presentation/d/10SagxoHUY9JBlMK2dXej1atndwQdpVEz0YmmJ52dLBg/edit?usp=sharing
01:06:22 [mjackson]
mjackson has joined #webcomponents
01:06:36 [mjackson]
mjackson has left #webcomponents
01:07:35 [emilio]
Kurt: I made also a lot of changes to the explainer and also a spec PR too
01:08:14 [emilio]
... It's basically two attributes (type=module and specifier="foo")
01:08:18 [emilio]
... to the <style> element
01:08:42 [emilio]
... then it creates an importmap entry globally
01:09:08 [emilio]
... the others is <template shadowrootadoptedstylesheets=""> attribute
01:09:21 [emilio]
... with specifier, or a URL that's in the module
01:09:37 [lea]
q?
01:09:41 [emilio]
q+
01:10:19 [emilio]
... it's in experimental web platform features in chrome canary
01:10:44 [westbrook]
👏👏👏
01:11:04 [lea]
q+ to ask about CSS imports and import maps
01:12:17 [emilio]
Kurt: there's a bunch of details to figure out, timing details
01:12:19 [sorvell]
q+
01:12:26 [emilio]
... also lifetimes of the blobs and so on
01:12:44 [rniwa]
q?
01:12:49 [rniwa]
q+
01:13:01 [emilio]
... thursday noon japan time will be discussed with WHATWG
01:13:29 [justinf]
q+
01:14:06 [emilio]
... @sheet is a bit tabled for now, no resources to commit to it right now
01:14:23 [emilio]
... I think it can be useful, and a prototype in chromium
01:14:47 [emilio]
... if anyone wants to pick it up that'd be cool
01:15:41 [bkardell]
emilio: can you import a declarative css module from an @import - do we need extra syntax for that? it seems like something that would be interesting to do
01:15:50 [justinf]
A: no. @import doesn't work with modules yet
01:15:54 [bkardell]
Kurt: no- it currently throws an error...
01:16:41 [ydaniv]
q+
01:16:41 [nicolo-ribaudo7]
nicolo-ribaudo7 has joined #webcomponents
01:16:44 [bkardell]
emilio: not about @import inside the module, I was talking about can you actually reference an existing module from an inline @import. Like @import(...)
01:16:58 [bkardell]
justinf: are you talking about inside of css
01:17:02 [bkardell]
emilio: yes
01:17:47 [bkardell]
lea: in js we specify that imports have to be either fully formed or start with a dot - specifically so you can tell the difference. But in CSS even today it would be treated as a URL... It seems very weird tho to not
01:17:54 [bkardell]
emilio: we would have to add another function
01:18:52 [bkardell]
westbrook: If I have created a reference able declarative module called Justin, and later include an inline style tag and inside of that it says @import(Justin) would it work? That's not a css module, but it's referencing one - it seems like something we should;d be able to do
01:19:49 [bkardell]
justinf: the reason I am saying it is the same, this uses the module map. They are modules - they are the same things that you would import in the javascript module map. we've always wanted to enable that - if we need to add another function...
01:20:06 [bkardell]
Kurt: yeah, we would have to add a new function
01:20:17 [astearns]
@import module(justin) versus @importmodule
01:20:22 [sorvell]
`@import module(foo)`
01:20:42 [keithamus]
ack emilio
01:20:42 [keithamus]
ack lea
01:20:42 [Zakim]
lea, you wanted to ask about CSS imports and import maps
01:20:55 [bkardell]
emilio: if you add something to the module map which has already been referenced - CSS generally works more dynamically, but maybe it doesn't have to
01:21:16 [bkardell]
annevk: there are other things in HTML like fetch - should they be able to hook into the module map
01:21:25 [emilio]
lea: I think it's important architecturally to get this right
01:21:40 [emilio]
... to be able to use the specifier everywhere
01:21:51 [emilio]
... everywhere you can import a url from JS you can use the import
01:21:57 [emilio]
... I don't see it as a nice to have
01:22:14 [emilio]
sorvell: To directly respond, I agree but importmap totally goes with modules, not urls
01:22:41 [emilio]
... so I don't necessarily think @import having a different way to specify a module
01:22:45 [emilio]
... is problematic
01:22:50 [emilio]
lea: I think we agree on that
01:23:04 [emilio]
sorvell: it'd be nice to have but in general I dislike the ordering requirement and snapshotting requirement
01:23:11 [lea]
+1 sorvell, I totally missed the ordering requirement
01:23:16 [justinf]
+1
01:23:18 [ydaniv]
q-
01:23:21 [westbrook]
+1
01:23:23 [emilio]
... I could give you things in whatever order I wanted
01:23:28 [keithamus]
ack sorvell
01:23:29 [emilio]
... I think that'd match the CSS expectations
01:23:55 [lea]
absolutely, 100%. Pretty sure there's a TAG design principle about this actually
01:23:58 [emilio]
annevk: Also connection time must be wrong, because at connection the <style> is element
01:24:11 [sakito]
sakito has joined #webcomponents
01:24:53 [emilio]
Kurt: it's when the sheet is already parsed
01:25:18 [emilio]
sorvell: to me if you're going to use `<style>` it should behave like CSS
01:25:35 [emilio]
... otherwise let's use <script>
01:25:51 [emilio]
rniwa: so the import map is global, which one wins on conflicts?
01:26:00 [emilio]
Kurt: the first defined one
01:26:12 [emilio]
annevk: yeah the module map is per-global
01:26:25 [emilio]
justinf: it's actually critical for the design
01:26:39 [hyojin]
hyojin has joined #webcomponents
01:26:39 [lea]
q?
01:26:49 [lea]
q+
01:27:00 [emilio]
keithamus: does this allow you to override the stylesheet of a third-party component?
01:27:06 [emilio]
rniwa: yeah that seems a bit problematic
01:27:12 [nicolo-ribaudo7]
q+
01:27:22 [emilio]
justinf: they can just do that, put an import map and override everything
01:28:03 [emilio]
westbrook: same with CSS if you have custom functions and mixins
01:28:09 [emilio]
emilio: that's very odd
01:28:16 [emilio]
westbrook: but let's talk about that on thursday
01:28:34 [emilio]
Kurt: there's an inline-style CSP
01:28:38 [emilio]
... which is respected for <style>
01:28:48 [emilio]
... which does get respected
01:29:30 [emilio]
emilio: that solves the third-party component injects into your global map
01:29:35 [emilio]
... but not what keithamus was saying
01:29:55 [emilio]
keithamus: I think if you're in control of the component you could not use this feature
01:29:59 [emilio]
rniwa: yeah but that'd be a bit bad
01:30:12 [emilio]
justinf: the only components that would use it is the SSR system
01:30:36 [emilio]
rniwa: that's how you do it if the feature as proposed is implemented
01:30:49 [emilio]
... as the feature is currently proposed it allows random styles into the components
01:31:00 [emilio]
... seems like this creates a new feature
01:31:01 [westbrook]
q+
01:31:11 [emilio]
justinf: a component can just inject styles all over the place
01:31:21 [emilio]
... is there any new
01:31:28 [emilio]
annevk: It's the other way around
01:31:54 [emilio]
... which is theoretically possible by hooking .attachShadow() I guess
01:32:12 [emilio]
sorvell: I can do this from a component already
01:32:17 [emilio]
annevk: that's not the issue
01:32:32 [emilio]
keithamus: it's the opposite problem
01:32:33 [MichaelWarren]
q+
01:32:57 [emilio]
westbrook: let's say I sneak applepay.js in the component map
01:33:08 [emilio]
... from the page I can nerf the applepay component
01:33:21 [emilio]
keithamus: yeah you've completely erradicated the component in that regard
01:33:35 [emilio]
... you are inserting a google maps / apple pay component
01:33:44 [emilio]
... what level of control do you have over that?
01:33:59 [emilio]
sorvell: I can use an element in my custom-element that has been defined above
01:34:22 [emilio]
justinf: declarative shadow root already has this problem, closed shadow roots can be tweaked by markup
01:34:44 [emilio]
... these are features intended for that, it's going to be meant for everything
01:34:55 [emilio]
... you'd need an iframe to get extra protection
01:35:31 [emilio]
westbrook: one step further, it's not this feature, this begins to speak to a well organized path for customization, e.g. if I proactively use the module name is "very-cool-color-picker"
01:35:40 [rniwa]
q?
01:35:53 [emilio]
... there's a lot of possibility for that
01:35:55 [westbrook]
q-
01:36:00 [rniwa]
q-
01:36:10 [emilio]
lea: I think the concern is overriding it by accident
01:36:40 [ntim]
(where can i find the full agenda and relevant issues/docs?)
01:36:42 [emilio]
justinf: re. @sheet, I think deferring it makes sense
01:36:47 [westbrook]
https://docs.google.com/document/d/1KeqMzuPHzHXTGR2zXmOHQydMUgVm2Y8onZHVmygAQFc/edit?tab=t.0
01:36:55 [emilio]
ack justinf
01:36:59 [emilio]
ack lea
01:37:00 [keithamus]
q+
01:37:19 [emilio]
lea: is the namespace different between js and css?
01:37:30 [emilio]
Kurt: yes, module map is keyed by type
01:37:55 [sakito]
sakito has joined #webcomponents
01:38:02 [emilio]
lea: I wonder if a lot of the issues could be addressed by the browser not fetching the url multiple times
01:38:04 [emilio]
qq+
01:38:11 [sorvell]
changing loading behavior seems exceptionally hard
01:38:14 [emilio]
lea: and you get FOUC and so on
01:38:52 [bkardell]
emilio: browsers won't fetch the same url twice - the main issue with shadow Dom is that they do not block rendering on the shadow Dom sstylsheets being loaded
01:39:26 [bkardell]
emilio: that does seem fixable to me to be honest ... the main issue that I think Kurt is interested in fixing with @ sheet is that you can skip multiple fetches
01:39:36 [bkardell]
lea: I remember there was some kind of issue where you get glitches
01:40:05 [bkardell]
emilio: the general render blocking ability is based on link tags in the head, mainly...
01:40:25 [bkardell]
emilio: to be fair that can be worked around by the component itself - you can add an onload handler and just do that yourself
01:40:35 [bkardell]
justinf: but this whole feature is for before that
01:40:49 [bkardell]
emilio: you can definitely hide the host until the style loads
01:40:57 [bkardell]
justinf: that defeats the whole purpose of ssr
01:41:13 [bkardell]
emilio: totally unrelated to ssr - I agree it doesn't solve that
01:41:18 [westbrook]
ack emilio
01:41:18 [Zakim]
emilio, you wanted to react to lea
01:41:31 [Jxck]
no short break ?
01:41:42 [anne]
anne has joined #webcomponents
01:42:02 [westbrook]
I was going to ask about a short break after this topic.
01:42:16 [emilio]
nicolo-ribaudo7: Global namespaces might be useful, but is there a desire to make it local to the component somehow?
01:42:30 [westbrook]
ack nicolo-ribaudo
01:42:35 [emilio]
justinf: the entire purpose of this feature is the global ns
01:42:49 [emilio]
... otherwise you can't share styles across shadow roots
01:43:08 [emilio]
... to me without the global namespace this is not useful
01:43:25 [emilio]
Kurt: you can fake it by using the namespace identifier
01:43:30 [emilio]
... hacky but not great
01:43:55 [emilio]
nicolo-ribaudo7: on the JS case we're trying to define multiple modules from the same file
01:44:06 [emilio]
westbrook: that's very close to what @sheet is intended to do
01:44:18 [westbrook]
ack MichaelWarren
01:44:22 [sorvell]
q+
01:44:43 [emilio]
MichaelWarren: I was making a comment related to westbrook's earlier intervention, opt-in customizability seems nice
01:44:58 [justinf]
This is the wrong feature for customizing someone else's shadow root styles
01:45:11 [bkardell]
justinf: but it does that, right?
01:45:13 [emilio]
... It'd be good for a hint for name conflicts
01:45:18 [bkardell]
justinf: that's what people were saying
01:45:29 [emilio]
Kurt: seems like a good idea to warn on naming conflicts
01:45:31 [justinf]
bkardell: it does it in the same sense that service workers let you customize a libraries JS
01:45:45 [emilio]
keithamus: can we go back to specifiers vs urls?
01:46:03 [emilio]
... so specifiers on shadowrootadoptedstylesheet="" awaits?
01:46:38 [emilio]
Kurt: no you don't get styles, the adopted stylesheets being sync guarantees the order and soon
01:46:51 [emilio]
... if you need async behavior you can use the scriptable
01:47:26 [emilio]
westbrook: is it possible to use a placeholder?
01:47:42 [westbrook]
q?
01:47:45 [emilio]
keithamus: maybe it could register an empty stylesheet and then the module specifier would replaceSync() on the existing sheet?
01:47:53 [emilio]
... for the url case does it fetch?
01:48:02 [emilio]
Kurt: no just looks at the module map
01:48:14 [emilio]
keithamus: Is that problematic for authors?
01:48:27 [emilio]
... because console warnings aside it's a silent failure
01:48:31 [emilio]
... so feels a bit dangerous
01:48:35 [emilio]
q+
01:48:42 [emilio]
Kurt: these are all kinda tricky
01:48:50 [emilio]
... we either do several non-great options
01:49:20 [emilio]
... then first-one-wins works weirdly but seems fixable
01:49:34 [emilio]
... other than that it seems you'd get a FOUC
01:49:41 [hayato]
hayato has joined #webcomponents
01:49:41 [keithamus]
ack keithamus
01:49:41 [rniwa]
q+
01:49:59 [emilio]
justinf: For the main intended use case an SSR system would never emit a wrong specifier
01:50:16 [emilio]
... we'd generate synthetic specifiers for empirically created constructable stylesheet objects
01:50:27 [emilio]
... we'll create a reference, emit it...
01:50:41 [emilio]
... the secondary use case would be to try to share module contents within SSR and inline content
01:50:50 [emilio]
... e.g you SSR a page and then a script
01:51:10 [emilio]
... in that case if the JS loaded before the SSR then you emit in your page
01:51:14 [emilio]
... a bit of a niche use case
01:51:26 [emilio]
... but would be cool if it works
01:51:27 [westbrook]
q?
01:51:30 [emilio]
ack sorvell
01:51:54 [emilio]
sorvell: There might be a 60/70% capabilities overlap with mixins
01:52:08 [justinf]
I don't understand how they overlap at all
01:52:12 [emilio]
... I think they're amazing
01:52:17 [justinf]
this feature is for inlining shared CSS modules
01:52:18 [emilio]
... to do a lot of similar type of customization
01:54:14 [bkardell]
emilio: the js module map - the whole define it later so that it works could be done with the existing ... imagine you do this in js - you would have a global window.stylsheet map - you would lazily create them until someone does replaceSync on them - that also unlocks using @import in these modules... the main problem with the current @import - each @import has its own stylesheet, but if they use a module they should clearly not use
01:54:14 [bkardell]
those kind of semantics
01:54:18 [westbrook]
ack emilio
01:54:46 [bkardell]
... especially if we add a different syntax - I think we don't have those issues, it's just essentially a constructible stylesheet... that would let us sidestep
01:55:21 [bkardell]
emilio: we could disallow non-module imports - that gets some of the way there. that may be a good model to work off of
01:55:36 [bkardell]
keithamus: would you just have to set a flag if you've done replacing once?
01:55:50 [justinf]
unblocking @import would be huge
01:56:01 [bkardell]
emilio: that might be a useful mental and spec model for how it works - it works the same way as you would implement in js, which is nice
01:56:34 [emilio]
rniwa: Was going to point out the same issue that emilio just proposed solving
01:56:43 [emilio]
keithamus: @import doesn't work now
01:56:51 [justinf]
The @import decision was just to defer them. That's what they throw for now
01:56:59 [emilio]
rniwa: It'd be ideal to fix it
01:57:16 [emilio]
justinf: yeah we made them throw just for that, but yeah the issue is the semantics of @import not matching JS modules
01:57:47 [emilio]
keithamus: seems like a path forward could be we implement @import module() then remote @import
01:57:56 [westbrook]
q?
01:57:58 [emilio]
... doesn't seem like a blocker for this functionality I guess
01:58:04 [emilio]
rniwa: yeah as long as it's forward compatible
01:58:07 [rniwa]
ack rniwaq
01:58:10 [rniwa]
ack rniwa
01:58:16 [emilio]
Kurt: yeah if we have some @import module()...
01:58:36 [emilio]
... we could expose exported sheets
01:58:49 [emilio]
... but yeah this doesn't prevent us from this or the existing CSS modules
01:58:59 [emilio]
keithamus: Do you think you got enough to go off of?
01:59:05 [emilio]
Kurt: yeah this was great
01:59:19 [emilio]
... lot of folks have contributed to this
01:59:25 [schenney]
schenney has joined #webcomponents
02:00:40 [JRJurman4]
<Taking a 5 minute break>
02:10:25 [sorvell]
To quickly illustrate the point about @mixin:
02:10:25 [sorvell]
<style>@mixin --font-inherit() { input, button, textarea, select { font: inherit; }}</style>
02:10:25 [sorvell]
<div><template shadowrootmode="open"><style>:host { @apply --font-inherit(); }</style>...</template></div>
02:11:26 [sakito]
sakito has joined #webcomponents
02:12:55 [kbabbitt]
kbabbitt has joined #webcomponents
02:12:59 [justinf]
template slides: https://docs.google.com/presentation/d/1r0AXWbP8RadIBuIFl-hC3O8G6YhTlguxKyluDIWil7g/edit?usp=sharing
02:13:19 [ydaniv]
ydaniv has joined #webcomponents
02:13:27 [anne]
anne has joined #webcomponents
02:13:45 [alisonmaher]
alisonmaher has joined #webcomponents
02:13:56 [rniwa]
rniwa has joined #webcomponents
02:14:13 [westbrook]
westbrook has joined #webcomponents
02:14:34 [westbrook]
https://docs.google.com/document/d/1KeqMzuPHzHXTGR2zXmOHQydMUgVm2Y8onZHVmygAQFc/edit?tab=t.0
02:18:49 [Kurt]
Kurt has joined #webcomponents
02:19:13 [rniwa]
q?
02:19:59 [saku]
saku has joined #webcomponents
02:21:06 [Jxck]
Jxck has joined #webcomponents
02:21:31 [emilio]
topic: Templates
02:21:56 [emilio]
slides: https://docs.google.com/presentation/d/10SagxoHUY9JBlMK2dXej1atndwQdpVEz0YmmJ52dLBg/edit
02:21:59 [emilio]
q+
02:22:21 [emilio]
justinf: [goes over the slides]
02:29:37 [MichaelWarren]
q+
02:29:44 [rniwa]
q+
02:30:11 [bkardell]
q+
02:30:46 [sorvell]
q+
02:31:36 [bkardell]
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 [bkardell]
... do they run on rAF?
02:31:58 [bkardell]
... I am assuming you want that by default, but you need to hook it up somewhere
02:32:16 [bkardell]
.. then what happens when I move it around or something - should I update the order or..?
02:33:18 [bkardell]
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 [bkardell]
... 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 [bkardell]
... 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]
theparkagen has joined #webcomponents
02:34:32 [westbrook]
q?
02:35:11 [bkardell]
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 [bkardell]
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 [bkardell]
... out of that all composition and control flow just fall out
02:36:26 [bkardell]
... if you flip back and forth on some tertiary you will rerender
02:36:34 [westbrook]
How might timing relate to https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EventPhases/explainer.md
02:37:08 [westbrook]
q?
02:37:17 [bkardell]
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 [sorvell]
q-
02:38:01 [ydaniv]
q+
02:38:04 [bkardell]
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 [bkardell]
justinf: I don't think it is confusing, it is the main thing today
02:38:53 [bkardell]
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 [emilio]
ack emilio
02:39:16 [bkardell]
justinf: there are ways to bind a node into a spot or refs ...(?? didn't get it, sorry)
02:39:44 [anne]
anne has joined #webcomponents
02:39:57 [adamargyle]
adamargyle has joined #webcomponents
02:40:16 [sorvell]
wrt scheduling, we already have the custom element reaction queue that might be a helpful model, at least for reference
02:40:17 [emilio]
MichaelWarren: The render() method would be in HTMLElement, but in the example would be ShadowRoot?
02:40:35 [saku]
saku has joined #webcomponents
02:40:36 [anne]
RRSAgent, draft minutes
02:40:37 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/11/10-webcomponents-minutes.html anne
02:40:47 [sakito]
sakito has joined #webcomponents
02:40:56 [westbrook]
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 [anne]
RRSAgent, make logs public
02:41:07 [emilio]
... it's very attractive to have a single function to hook for SSR
02:41:34 [emilio]
justinf: you are correct that the reason why lit can do ssr is because it just calls render()
02:41:39 [westbrook]
q?
02:41:42 [emilio]
... this could be a way to have a semi-universal ssr
02:41:46 [westbrook]
ack MichaelWarren
02:42:05 [emilio]
MichaelWarren: if we have a templating engine it'd be good to have a standardized feature set
02:42:19 [emilio]
... because frameworks that are running in servers need something else
02:42:39 [emilio]
justinf: another thing SSR engines would do is patching to patch the render() method
02:42:55 [emilio]
... this can help users of SSR a ton
02:43:18 [emilio]
rniwa: I think we should probably try to make this approachable
02:43:34 [emilio]
... I get that to get something comparable to what frameworks are doing we need all of it
02:43:40 [rniwa]
ack rniwa
02:43:50 [emilio]
... I think we need to make this smaller
02:44:09 [emilio]
justinf: I intentionally bypassed a lot of the HTML syntax
02:44:19 [emilio]
... questions that showed up for DOM Parts
02:44:28 [astearns]
+1 to finding a minimally useful first step
02:44:35 [emilio]
... maybe we could try to make this more of a map than a concrete proposal
02:44:36 [emilio]
+1
02:44:38 [bkardell]
q-
02:44:42 [emilio]
ack ydaniv
02:44:59 [westbrook]
q?
02:45:02 [saku]
saku has joined #webcomponents
02:45:06 [emilio]
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 [emilio]
... one of the more important things for me is to be able to maintain state
02:45:19 [emilio]
... kind of like moveBefore()
02:45:29 [emilio]
... so if we could make that work somehow
02:45:43 [emilio]
... if this could render dom but maintain my states that'd be a great winner
02:45:45 [nicolo-ribaudo]
nicolo-ribaudo has joined #webcomponents
02:46:05 [emilio]
justinf: I think this would be useful to have in an issue
02:46:29 [emilio]
... I think it'd be useful to use moveBefore() when possible
02:46:29 [emilio]
... we should talk about ti
02:46:29 [emilio]
s/ti/it
02:46:42 [trusktr]
trusktr has joined #webcomponents
02:47:33 [emilio]
justinf: One thing I'd like is to get a co-champion that could work on this
02:47:39 [trusktr]
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 [emilio]
trusktr: The TemplateResult could be passed dom, and schedule can use requestAnimationFrame(), DOM Parts can already be decoupled
02:49:07 [emilio]
justinf: parts are more of an spec concept rather than a public API
02:49:13 [emilio]
... you need to explain the behavior
02:49:29 [emilio]
trusktr: DOM parts about framework authors and reactivity systems
02:49:36 [emilio]
... they need that access to wire things together
02:49:46 [emilio]
... the typical user doesn't care about how the DOM is updated
02:49:53 [emilio]
anne: You still need to specify how its done
02:50:04 [emilio]
... the public API is usually the simpler bit
02:50:12 [emilio]
rniwa: yeah the processing model is the simplest part
02:50:17 [denis]
denis has joined #webcomponents
02:50:20 [emilio]
... foregoing parts would remove some issues
02:50:24 [emilio]
... the main complexity is there
02:50:35 [emilio]
... at the end of the day even if it's a black box it needs to be spec'd
02:50:57 [emilio]
trusktr: right but then there's only the question of the order, internally it'd be a setAttribute() call
02:51:11 [emilio]
rniwa: yeah but still needs to be well defined because MutationObserver can observe
02:51:32 [emilio]
justinf: yeah there's also the need to extend this
02:51:50 [emilio]
... I really want to make this usable by framework authors
02:51:50 [anne]
s/yeah the processing model is the simplest part/yeah the processing model is the hardest part/
02:51:59 [emilio]
... either existing or others, and the DOM Parts API is critical for that
02:52:38 [westbrook]
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md
02:52:43 [emilio]
topic: HTML modules
02:52:43 [westbrook]
https://github.com/WICG/webcomponents/issues/1059
02:52:50 [westbrook]
https://github.com/WICG/webcomponents/issues/645
02:52:51 [emilio]
https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md
02:54:23 [emilio]
Jayson: tldr is that we think this is still too early for standardizing HTML modules
02:54:42 [emilio]
... I think HTML modules are different from HTML includes
02:55:00 [emilio]
... People kinda understand it as HTML import
02:55:11 [emilio]
... we need to solve that before but that's a separate topic
02:55:20 [emilio]
... some customer problems we run into
02:55:48 [emilio]
... 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 [emilio]
... reusing HTML in multiple places
02:56:30 [emilio]
... All these are actually HTML include, not HTML modules
02:57:05 [emilio]
... 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 [rniwa]
q?
02:57:40 [emilio]
... HTML module similarly we have html with and without scripts, style, template, custom element definitions, scoped custom element registry
02:57:48 [keithamus]
q+
02:58:32 [sorvell]
q+
02:59:12 [emilio]
For modules they want to make the contents dynamic
02:59:36 [emilio]
... the dynamic part can range for content attributes / event handlers / etc
03:00:03 [emilio]
... coming back to HTML modules, even if we standardized them right now it wouldn't solve the more common problems
03:00:32 [emilio]
... e.g. modularizing a template is not possible r/n
03:00:59 [emilio]
... so most of what customers actually ask for is html include
03:01:31 [emilio]
... there's also an existing declarative partial update proposal
03:01:43 [daiki]
daiki has joined #webcomponents
03:01:44 [emilio]
... that might be able to address some of the problems
03:01:48 [sorvell]
q-
03:02:04 [ydaniv]
ydaniv has joined #webcomponents
03:02:22 [emilio]
... I would be curious to look into how that proposal could interact with html modules
03:02:52 [rniwa]
q+
03:03:21 [emilio]
... 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 [emilio]
... can be useful for ergonomics too but that should not be the main motivation
03:04:06 [emilio]
... 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 [justinf]
q+
03:04:27 [emilio]
... I think there are use cases that we haven't explored so if you have thoughts feel free to reach out
03:04:35 [westbrook]
q?
03:04:36 [emilio]
... or if moz or webkit have more ideas in mind
03:04:41 [emilio]
... thanks
03:04:48 [Kurt]
Kurt has joined #webcomponents
03:05:20 [emilio]
keithamus: thanks for going in to the presentation of why we shouldn't do this, I think it was very interesting
03:05:27 [emilio]
... one of the motivating cases about compression
03:05:37 [emilio]
... devs don't want to repeat a blob of HTML and over the wire cost
03:05:45 [emilio]
... I don't think that's a problem that we should be solved
03:05:50 [emilio]
... gzip is very good at this
03:06:42 [emilio]
... so this repetitive HTML in the DOM tree probably should not be something we solve for
03:06:59 [westbrook]
q?
03:07:06 [keithamus]
ack rniwa
03:07:07 [emilio]
... most servers support gzipping arbitrary content without much cost and shared compression dictionaries
03:07:12 [keithamus]
ack keithamus
03:07:15 [keithamus]
qq+ rniwa
03:07:16 [trusktr]
trusktr has joined #webcomponents
03:07:16 [justinf]
keithamus: many of these repeated chucks have slight variations, so they need some sort of HTML template
03:07:28 [justinf]
but this isn't a HTML Modules feature
03:07:46 [emilio]
anne: Not sure HTML modules would get us there but it could also help with memory usage
03:07:58 [emilio]
... we are not trying to deduplicate actual dom nodes
03:08:04 [lea]
q+
03:08:09 [trusktr]
The main goal that I feel causes the concept of HTML Modules to exist is the wanting for Declarative Custom Elements
03:08:43 [bkardell]
emilio: there are already several things that can be deduplicated and shared
03:08:45 [ydaniv]
q+
03:09:09 [emilio]
anne: Yeah was just wonder if there would be some optimization possible in the engine for that kind of pattern
03:10:20 [emilio]
justinf: I think that's a bit different from html modules
03:10:50 [emilio]
rniwa: I tend to agree that it's probably early for HTML includes, we want declarative custom elements first, and HTML import without that feature is really convoluted
03:11:16 [westbrook]
q+
03:11:18 [emilio]
... because we need to design it so that it's compatible with it but we still don't have a model for that
03:11:29 [rniwa]
ack rniwa
03:11:29 [Zakim]
rniwa, you wanted to react to keithamus
03:11:36 [emilio]
Jayson: agreed, we need those capabilities
03:12:04 [emilio]
justinf: declarative custom elements is something where the only agreement is that we need imports for
03:12:50 [emilio]
... so you import the template and you use import that from JS, so if we had HTML modules it could unleash an explosion of these declarative elements with vue and polymer-like systems to inform the declarative custom elements design
03:13:10 [emilio]
rniwa: I think that'd be backwards, we don't want to standardize something to allow experimentation
03:13:19 [justinf]
https://heximal.dev/
03:13:31 [emilio]
justinf: it's a container format right? I have a whole system that I built which is kinda polymer on top of lit or somesuch
03:13:46 [emilio]
... it's cool but I don't want to work on it because there's no way to load these into the page
03:14:00 [emilio]
... otherwise the only way to load these into the main page
03:14:10 [lea]
+100 to justinf, have faced the same issues myself in the past, several times
03:14:15 [emilio]
... putting HTML into the module graph would be huge, vue could use it
03:14:23 [emilio]
... as an ergonomic container format
03:14:37 [emilio]
anne: You say just but I think we've figured out that it's not "just"
03:15:03 [emilio]
justinf: not sure, you should be able to have a declaration and import it and give it a name
03:15:19 [emilio]
... as opposed to being aware of their custom element definitions inside and so on
03:15:37 [emilio]
anne: The whole thing about what the container format looks like / does and not is very tricky
03:15:45 [emilio]
... you need this model for detached parts
03:15:53 [emilio]
... and it was hard to figure out
03:16:14 [emilio]
... you might end up making choices that don't interact well with declarative custom elements
03:16:33 [anne]
anne has joined #webcomponents
03:16:43 [anne]
RRSAgent, draft minutes
03:16:45 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/11/10-webcomponents-minutes.html anne
03:17:01 [emilio]
justinf: I think a lot of the requirements we have for native declarative custom elements are the same for userland, you need this ?? dom and connect to be called
03:17:12 [emilio]
... so you need the element that defines the element to be able to execute
03:17:22 [sorvell]
q+
03:17:22 [westbrook]
q?
03:17:23 [keithamus]
ack justinf
03:17:30 [emilio]
... I think we have a lot of other competing priorities but I think they'd be very useful
03:18:11 [emilio]
lea: regarding gzip and the preliminary state-of-html results show that html reuse and templating are the top priorities
03:18:21 [emilio]
... it's clear that gzip is not enough
03:18:31 [emilio]
... and that there's a need for better primitives here
03:18:48 [emilio]
... reusing a footer across pages is different than importing html into a custom element
03:19:22 [westbrook]
emilio: gzip is one argument that is less powerful, but the other arguments are not excused for it.
03:19:42 [emilio]
keithamus: Yeah just want to mention that the over-the-wire cost is not a problem to solve here
03:19:48 [emilio]
... might not even just be a dx
03:20:02 [emilio]
... even in the examples you pointed out the use cases are wildly different
03:20:16 [emilio]
... wasn't implying gzip solves all these problems
03:20:34 [emilio]
... just that over-the-wire cost
03:20:43 [emilio]
... is not something that we should solve here
03:21:28 [emilio]
anne: not sure that gzip solves reusing a footer across documents and such
03:21:30 [Kurt]
Kurt has joined #webcomponents
03:21:42 [emilio]
keithamus: shared compression dictionaries work for that tho
03:21:53 [emilio]
justinf: but yeah that again is html include not module
03:22:01 [westbrook]
q?
03:22:01 [emilio]
rniwa: yeah this feature is very easy to scope-creep
03:22:09 [lea]
s/html reuse and templating are the top priorities/html reuse and templating are at the top of content-related pain points/
03:22:16 [emilio]
keithamus: we need to both gather use cases but also the why
03:22:50 [emilio]
... because the over-the-wire cost is not a valid response, having slightl variations on the same piece of content is, but fairly different
03:23:00 [emilio]
ydaniv: there's a precedent on SVG (<use>)
03:23:06 [sorvell]
q-
03:23:16 [justinf]
we're still talking about HTML Includes, not HTML Modules though...
03:23:17 [emilio]
ydaniv: people can already abuse <use> and <foreignObject> and embedding HTML
03:23:26 [justinf]
<use> is an include, not a module
03:23:36 [emilio]
... lots of other problems but we're talking about a lot of extra capability
03:23:37 [lea]
ydaniv: my kooky proposal I just mentioned: https://github.com/whatwg/html/issues/11463 😅
03:23:39 [emilio]
... people use the <use> element a lot
03:23:45 [emilio]
... we know how it works
03:23:47 [emilio]
q+
03:24:18 [trusktr]
trusktr has joined #webcomponents
03:24:33 [justinf]
Here's a bunch of HTML Module use cases I put together for Jayson that would only need to import/export and use userland features internally: https://gist.github.com/justinfagnani/33c83d8b886e3ed2c362911263e40080
03:24:34 [Jxck]
Jxck has joined #webcomponents
03:25:00 [rniwa]
q?
03:25:06 [emilio]
ack lea
03:25:07 [emilio]
ack ydaniv
03:25:10 [sorvell]
the value, if there is any right now, is about populating the module graph with a reference-able resource of a particular type.. in this case html/dom
03:25:21 [justinf]
+1
03:25:41 [emilio]
emilio: <use> is different in SVG1 and SVG2, not sure the semantics are what you want (doesn't expose the cloned node to the regular DOM)
03:25:52 [emilio]
keithamus: justinf mentioned also that this is includes not modules
03:26:44 [emilio]
westbrook: what about getting a group about getting a group to discuss declarative custom elements and html modules?
03:26:56 [justinf]
here's my personal map of how these features depend on each other: https://www.mermaidchart.com/play?utm_source=mermaid_js&utm_medium=editor_selection&utm_campaign=playground#pako:eNqNVE1vnDAQ_SsWlXqz-nHoRw6VCssmkbJqtETKoduDA5NiyWBkk6Zp1f9eGxuvAXuX5bDgefPmzXhm_iYlryC5SB4Zfy5rInp0sz-0SP0q3uBOHcjvh2TzbYdu9fsh-YEw_uKMuH6pBOkpbz0UMgQFCEoY_TOY0Rt0NUI1yW
03:26:56 [justinf]
vUQ9Mx0gMmHbXOd_YIfb29ViBDI-nPljCtojBvowYBpOzpL8DAoIG2xw9EAi4ZkRq8t9aru91NbgBWV6pgKNMwI8TxjIq0-5a2gC8FUX-V9RsZnUzpNPq5TLU5ThWoAiVOl0Cd133DJgE3R6ONp5UHYsmyhuqJgRiLJgBQMR4uiuNiGO-AsOE-o9JsM0TtC_fySfaqO-ylhFPLBgyy93LMbaBuuM5EOw4V2JlP13nxUIaDtkzfnSwF7XoMvztuevh6OFeV0ucoN-cjqx94Vqhld63TUUrppZIVxclMJuBAwSbuyzuRNan4M1ZjGXQvBjNS7XImuOpSKXVnXUILgjB0Dw-jBN50
03:26:56 [justinf]
vNVjVBT7oIhZGc6Uabo6zrTIOBLeCgnE9_JYG9skPN14nnVO4wb9tHi3yE4LXrKt1u3IuPrmwnaN_VixIQ-WQfYvDI67Hj1Sxi5epekm36YhhCfVQLNP-Yfssw-dLMMYn93q1p6_S_P8o28_NX4xzsBui6YT32extNzeXUU6n4UYq794oqDgSoui_TGIYWJjswZ_3DXxWsmxSttt_jZ9v65KK3rrzPSccLOjEW244SJUaQVIqajmpdBP8u8_QRkpfA
03:27:05 [justinf]
yikes. sorry for the long url
03:27:44 [emilio]
westbrook: would be good to have some focused sessions around some of these problems
03:28:01 [emilio]
anne: Having a scoped focus would make it reasonable
03:28:39 [emilio]
rniwa: yeah declarative custom elements can scope creep very easily
03:29:06 [emilio]
justinf: also a lot of what people presume about this (it's faster, less size) might not hold true
03:29:14 [justinf]
we need: https://github.com/whatwg/html/issues/7367
03:29:24 [justinf]
scriptEl.exports
03:29:35 [emilio]
keithamus: yeah we need to figure out how having a custom element without script is useful
03:29:42 [emilio]
annevk: You have the shadow tree
03:30:05 [emilio]
keithamus: we have a lot of script, just in a different language
03:30:16 [emilio]
rniwa: if you have a template engine then that would give you a JS-free modality
03:30:35 [emilio]
justinf: just having expressions would allow injection
03:30:42 [emilio]
keithamus: Is that something we need to resolve first
03:30:49 [lea]
q?
03:30:52 [lea]
q+
03:30:53 [emilio]
... so if we can't use declarative custom elements because script or templating
03:31:02 [emilio]
... we could solve these before solving for declarative custom elements
03:31:05 [trusktr]
trusktr has joined #webcomponents
03:31:10 [emilio]
justinf: that's why I want to do templates
03:31:29 [emilio]
rniwa: to me solving template should be a good path forward for solving declarative custom elements
03:31:46 [emilio]
... but declarative custom elements could be explored without that
03:32:38 [emilio]
keithamus: yeah not sure how with the current functionality would make a declarative custom element useful
03:32:48 [emilio]
... or associate it with script after it's been instantiated
03:32:54 [emilio]
anne: yeah we're likely to need that too
03:33:07 [emilio]
... didn't XBL have inline script
03:33:24 [emilio]
justinf: also prototype patching, script.exports
03:33:52 [emilio]
lea: wanted to say that for declarative custom elements I see two directions / goals
03:34:01 [emilio]
... one is simpler custom elements for basic things
03:34:08 [emilio]
... and also as a serialization target for SSR
03:34:32 [emilio]
... if the goal is simple things easy there's you need props / expressions and slots
03:34:38 [emilio]
... then you don't need scripting / expression
03:34:46 [emilio]
... as for ssr then we need a more complex API
03:34:47 [justinf]
another plug for Heximal as an example DCE system: https://heximal.dev/#components
03:35:01 [emilio]
keithamus: on your first point, simple custom elements, I don't think such a thing exists
03:35:29 [emilio]
... actually implementing a custom element with the current feature set wouldn't be possible that isn't trivial to do with existing elements, we'd have less than a handful of use cases
03:35:40 [emilio]
lea: that might be right but if we can get 90%?
03:35:49 [emilio]
... what about specifying the delta to the definition?
03:36:23 [emilio]
keithamus: that goes back to the question of how you associate script with the definition
03:36:44 [Jayson]
The slide earlier: https://docs.google.com/presentation/d/1eKio8ZvoeBqMe0Ao161hE-RaGGRagYTZ28KKL6xOkAg/edit?usp=sharing
03:37:39 [sorvell]
we need an... intelligent design.
03:38:20 [trusktr]
trusktr has joined #webcomponents
03:38:27 [trusktr]
F
03:38:28 [trusktr]
f
03:38:28 [trusktr]
f
03:39:01 [trusktr]
Sorry, Edge bug, blocks the input on iOS
03:39:01 [kbabbitt]
kbabbitt has left #webcomponents
03:39:15 [trusktr]
That's where optional JS helps. I think having HtML Templating before DCE would make DCE much more desirable at that point
04:47:40 [astearns]
zakim, end meeting
04:47:40 [Zakim]
As of this point the attendees have been keithamus, lea, ydaniv
04:47:41 [Zakim]
RRSAgent, please draft minutes
04:47:43 [RRSAgent]
I have made the request to generate https://www.w3.org/2025/11/10-webcomponents-minutes.html Zakim
04:47:50 [Zakim]
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
04:47:50 [Zakim]
Zakim has left #webcomponents
05:16:59 [jridgewell]
jridgewell has joined #webcomponents
05:45:22 [anne]
anne has joined #webcomponents
07:20:53 [zrhoffman]
zrhoffman has joined #webcomponents
07:34:02 [denis]
denis has left #webcomponents
08:02:14 [oriol]
oriol has joined #webcomponents