14:49:47 <RRSAgent> RRSAgent has joined #webcomponents
14:49:51 <RRSAgent> logging to https://www.w3.org/2024/09/25-webcomponents-irc
14:49:51 <tpac-breakout-bot> RRSAgent, do not leave
14:49:52 <tpac-breakout-bot> RRSAgent, make logs public
14:49:53 <tpac-breakout-bot> Meeting: Scoped custom element registry
14:49:53 <tpac-breakout-bot> Chair: Ryosuke Niwa
14:49:53 <tpac-breakout-bot> Agenda: https://github.com/w3c/tpac2024-breakouts/issues/26
14:49:53 <Zakim> Zakim has joined #webcomponents
14:49:54 <tpac-breakout-bot> Zakim, clear agenda
14:49:54 <Zakim> agenda cleared
14:49:54 <tpac-breakout-bot> Zakim, agenda+ Pick a scribe
14:49:55 <Zakim> agendum 1 added
14:49:55 <tpac-breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
14:49:56 <Zakim> agendum 2 added
14:49:56 <tpac-breakout-bot> Zakim, agenda+ Goal of this session
14:49:58 <Zakim> agendum 3 added
14:49:58 <tpac-breakout-bot> Zakim, agenda+ Discussion
14:49:58 <Zakim> agendum 4 added
14:49:58 <tpac-breakout-bot> Zakim, agenda+ Next steps / where discussion continues
14:49:59 <Zakim> agendum 5 added
14:50:00 <tpac-breakout-bot> tpac-breakout-bot has left #webcomponents
15:49:47 <bkardell_> bkardell_ has joined #webcomponents
16:29:11 <obuckley> obuckley has joined #webcomponents
16:42:13 <lea> lea has joined #webcomponents
17:02:59 <oriol> oriol has joined #webcomponents
17:21:48 <westbrook> westbrook has joined #webcomponents
17:31:22 <JRJurman> JRJurman has joined #webcomponents
17:32:31 <masonf> masonf has joined #webcomponents
17:32:35 <sanketj> sanketj has joined #webcomponents
17:32:35 <masonf> present+
17:32:36 <keithamus> keithamus has joined #webcomponents
17:32:41 <sanketj> present+
17:32:42 <keithamus> q?
17:32:43 <Di> Di has joined #webcomponents
17:32:44 <keithamus> present+
17:32:47 <JRJurman> present+
17:32:50 <rniwa> rniwa has joined #webcomponents
17:32:55 <jarhar> jarhar has joined #webcomponents
17:33:28 <justinf> justinf has joined #webcomponents
17:33:52 <kzms2> kzms2 has joined #webcomponents
17:33:58 <westbrook> present+
17:33:58 <masonf> scribenick: jarhar
17:34:02 <astearns> https://github.com/w3c/tpac2024-breakouts/issues/26
17:34:45 <jarhar> justinf: we had 3 open questions last time and we settled all of them
17:35:06 <jarhar> steve: have a registry on the apis for creating elements that are disconnected
17:35:18 <jarhar> steve: sethtml can have an option bag which can specify a registry
17:35:37 <jarhar> steve: that was resolved to be the simplest at the f2f, and its capture in the issue on this
17:35:58 <jarhar> masonf: to clarify: the proposal is that innerhtml will use the global registry, but sethtml/sethtmlunsafe will have an additional argument to use a registry
17:36:01 <sorvell> sorvell has joined #webcomponents
17:36:17 <jarhar> sorvell: my sense is that while its not ideal it makes the feature reasonable
17:36:27 <jarhar> rniwa: sethtml and sethtmlunsafe - we want to add the argument to both of them
17:36:29 <jarhar> sorvell: ideally yeah
17:36:54 <masonf> presumably parseHtml and parseHtmlUnsafe() also?
17:37:00 <jarhar> justinf: related: how to get registry for disconnected tree but also for a library ...
17:37:07 <jarhar> justinf: they could have similar solutions or different
17:37:20 <jarhar> sorvell: that is captured. i tried to make a summary of the issues in the breakout session github issue at the bottom
17:37:27 <jarhar> sorvell: rob made an issue for that and i had a separate issue for that
17:37:52 <jarhar> sorvell: my recollection at the last f2f was that we had discussed that those could be follow ons as long as we solve this disconnected issues which was needed for an mvp
17:38:14 <jarhar> sorvell: the two proposals around framework integration were trying to make that more seamless
17:38:16 <masonf> q?
17:38:26 <jarhar> sorvell: theres the steps to find the custom element registry. look for a root or use the global
17:38:43 <jarhar> sorvell: robs idea was that you could make a function wrapper - any time inside this callback, use this registry that im giving you
17:39:29 <jarhar> sorvell: my proposal was different - you could define a custom element - the problem is that in this disconnected state you can customize if youre in the global registry. you can define an element and only upgrade this element dont customize when its created. it wouldnt customize when its created. it would only customize when its connected to the
17:39:29 <jarhar> root that has the registry that you want, which is how upgrades work
17:39:57 <jarhar> sorvell: both of them are too hard to try to get through to get this landed. both of them could be done as a follow on to do better framework integration. in the meantime they can work around it
17:40:24 <keithamus> q?
17:40:25 <keithamus> q+
17:40:28 <jarhar> sorvell: this is the lit communitys most requested thing, i would love to see us get the mvp specified and on the road to impl
17:40:35 <jarhar> rniwa: could you qualify the problem statement?
17:41:18 <justinf> q+
17:41:27 <jarhar> sorvell: react and frameworks dont use special api to create dom, which you will have to use. to get those frameworks to use a new api to create dom it will be hard. to make this as seamless as we can for them to get this stuff for free that would be great. they dont use shadowdom, but you can make a react element or a framework element that stamps
17:41:27 <jarhar> into shadowdom
17:41:52 <jarhar> sorvell: we should do framework integration as a followon
17:42:26 <astearns> ack keithamus
17:42:32 <jarhar> keithamus: i dont think we should be specifying features to work aroudn existing limitations of frameworks. we should write patches for those frameworks or ask them to. the idea of executing a block of code by ... it would create more problems than it solves
17:42:35 <rniwa> q+
17:42:46 <jarhar> keithamus: the most ergonomic way to do this is to hang apis off of getrootnode and ask them to use that instead of document
17:43:04 <jarhar> sorvell: thats a solid argument. that discussion should not block the core feature
17:43:04 <masonf> ack justin
17:44:11 <jarhar> justinf: i disagree with keith. theres a long history in the web components space of saying this is the new reality and - its taken 10 years for react to support custom elements with attributes and properties. we need to build bridges to those destinations. maybe react will never move away from document.createelement. being able to say im going to
17:44:11 <jarhar> call this library and this library calls document.createelement
17:44:14 <masonf> ack rniwa
17:44:36 <jarhar> rniwa: this isnt really a framework integration as much as its making the framework use your registry. you want to force it to integrate
17:45:38 <jarhar> keithamus: force is the word. i respect the argument that frameworks can be very slow to adopt these features, but if we introduce code that forces a situation, we might see the opposite effect where theyre quick to work around it. we're making a hostile situation in their code. the expectations of how their code is being executed is changing
17:45:38 <jarhar> because outside is forcing it, and frameworks try to address this, and it will have the opposite effect that we want.
17:46:01 <jarhar> justinf: isnt the global registry forcing them to use custom elements? were changing which definitions to use. theyre already unaware of the registry anyway
17:46:01 <masonf> q+
17:46:24 <jarhar> rniwa: lets say were going to do this thing in this function that uses document.createelement. what happens when someone uses innerhtml on it after?
17:46:39 <jarhar> justinf: if that was attached to the shadowroot then the current steps work. otherwise its an open question, what to do about detached trees
17:46:48 <justinf> q+
17:47:11 <jarhar> keithamus: its your point around timing. if youre saying that during the lifetime of a function we're using this registry. if they do a single await or settimeout then suddenly we changed the pointer of the scoped registry and you have an intermediate set of
17:47:36 <jarhar> justinf: the react patch is to patch the owner on prototype and not be a document but use a scoped registry. its sync and fragile but its what you have to do to get react to work
17:47:46 <jarhar> keithamus: make that a proper part of the spec including the fragility
17:47:57 <sorvell> q+
17:48:17 <rniwa> ack masonf
17:48:47 <jarhar> masonf: im sympathetic to keith, lets not write an api for frameworks but lets make it good. justins point is a good one, the global registry is already happening and frameworks dont know. a similar api effect would be document.defaultregistry and set it to what you want and then run your code. its similar to the global registry, were just changing
17:48:47 <jarhar> how custom elements work
17:48:53 <jarhar> keithamus: you can mitigate timing issues
17:49:23 <jarhar> rniwa: isnt the whole point of scoped registries that you want multiple scoped registries? presumably different parts of the document are trying to use different scoped registries.
17:49:24 <masonf> q?
17:49:38 <jarhar> justinf: its a workaround when youre rendering into a shadowroot but the framework isnt aware of that
17:50:07 <masonf> ack justin
17:50:08 <jarhar> justinf: it could be used for micro frontned architectures. i have an element defined and i want to use it but i cant because it appears at the top of the document. if theres a way to create an element and force it to use a particular registry that would be useful
17:50:32 <jarhar> justinf: i want to take a step back. we have two open questions and we have zerod in on one of them. i dont know if people agree that the disconnected trees one is more important
17:50:51 <jarhar> rniwa: this uses different registry hinges on what we do with a disconnected tree, they are very related
17:50:58 <jarhar> justinf: how do people feel about that?
17:51:26 <jarhar> keithamus: if we have the same suite of apis on shadowroots then we avoid the problem of disconnected trees. people will have to use getrootnode
17:51:41 <jarhar> justinf: the spec does include putting a subset of element creation apis
17:51:52 <jarhar> justinf: if people started using that
17:51:58 <jarhar> sorvell: theres still a problem of innerhtml
17:52:01 <masonf> ack sorvell
17:52:29 <jarhar> sorvell: the core issue is innerhtmling which shadowroot innerhtml which doesnt work in the prototype yet. sethtml should work at the least
17:52:41 <justinf> q+
17:52:43 <westbrook> Referencing: https://issues.chromium.org/issues/336984024
17:52:50 <jarhar> sorvell: if we have sethtml and we have a solution that does match this idea of - it is not a framework related solution we need a way of creating dom in a registry on an element
17:52:57 <jarhar> keithamus: thats where i think having everything on a root node solves that
17:53:04 <jarhar> sorvell: how does it solve inner html?
17:53:07 <masonf> ack justinf
17:53:31 <jarhar> justinf: the lookup registry steps use the global registry. there was concern about the memory overhead of having a pointer on a node
17:53:38 <jarhar> justinf: i wonder if we can hang a rare data...
17:53:46 <jarhar> sorvell: at the last f2f the implementors said no
17:54:05 <jarhar> justinf: the lookup a registry steps look to see if theres a registry on the root node
17:54:05 <sanketj> q+
17:54:28 <jarhar> keithamus: innerhtml is deprecated, sethtml and gethtml should be used, they have an options bag and you can pass in a registry. does that solve the issue?
17:54:56 <jarhar> sorvell: it solves the i need to do some inner html on this disconnected node. option bag is on element. if you dont know the registry
17:55:24 <jarhar> keithamus: if you did shadowroot.createelement, it would be disconnected and wouldnt be inside the shadowroot. if you did sethtml you already have a registry but tractable. is the registry a public part of the shadowroot?
17:55:37 <jarhar> justinf: does someone know the right registry to pass? if you create an element with a scoped registry and hand it off?
17:55:54 <jarhar> keithamus: thats always the same problem. you still have to have a reference to the registry at some point
17:56:04 <jarhar> justinf: if the root node knows its registry
17:56:10 <jarhar> justinf: for a disconnected tree
17:56:25 <jarhar> sorvell: it could function like owner document. once you put it in a new document it changes
17:56:32 <jarhar> sorvell: that would probably be better, but implementors said no already
17:56:37 <jarhar> sorvell: so this is the next best thing
17:56:37 <masonf> q?
17:56:42 <masonf> ack sanketj
17:56:44 <jarhar> sanketj: could you elaborate on the implementors saying no?
17:57:03 <jarhar> keithamus: elements dont have a pointer to the scoped registry because the default lregistry is going to be the specified one
17:57:14 <jarhar> keithamus: adding a pointer to every element would be a lot
17:57:26 <jarhar> rniwa: it would not be rare though
17:58:01 <jarhar> keithamus: createelement would have to return some sort of boxed value. if its an element then you have a box which says this is the custom element and this is the registry and unpacking it would be a bunch of extra work
17:58:22 <jarhar> justinf: if you do create element without a registry it would use the global registry. if you do it in a shadowroot then it would set it
17:58:38 <jarhar> masonf: if you attached it to a tree it could delete that rare thing
17:58:47 <jarhar> sorvell: if you disconnect you have to put it back
17:58:55 <rniwa> q?
17:59:09 <jarhar> sanketj: i thought steve was saying tha tthe registry should live on the document or root and you have this to do the lookup, and that was the thing that was implementor objected about
17:59:24 <jarhar> justinf: the objection was to have a new pointer that every element has to have
17:59:55 <jarhar> sorvell: i think that the sethtml having an arguments bag is enough to move forward on this. its not ideal but i think its a ocmpropose thats reasonable and gets this feature off the ground.
18:00:12 <jarhar> sorvell: this is incredibly problematic for a lot of use cases, and if we can solve it then its awesome
18:01:27 <justinf> q+
18:01:31 <jarhar> jeff: im one of those people. ?? you lose out on some of those features like innerhtml or createelement. this whole system with registries sounds like its going to be cumbersome and how do i create a library that people can use? i really tried to use native elements instead of frameworks but i still hit that wall. if theres still going to be a wall
18:01:31 <jarhar> that im going to hit, especially with slots
18:01:52 <jarhar> rniwa: we are at time. we need to take the discussion offline
18:02:31 <jarhar> masonf: can somebody post the issue? i feel like we got close to adding an options bag to setinnerhtml
18:02:44 <sanketj> https://github.com/WICG/webcomponents/issues/1040
18:03:16 <sorvell> https://github.com/WICG/webcomponents/issues/1040#issuecomment-2093725017
18:03:20 <jarhar> justinf: i can create a pr and we can argue about whether to merge it
18:04:08 <masonf> topic: sdfsdf
18:04:10 <masonf> title: Sdfsdf
18:07:17 <jarhar> jarhar has joined #webcomponents
18:09:44 <dandclark> dandclark has joined #webcomponents
18:11:58 <masonf> masonf has joined #webcomponents
18:12:10 <alisonmaher> alisonmaher has joined #webcomponents
18:13:54 <alice> alice has joined #webcomponents
18:14:05 <masonf> present+
18:14:15 <alice> present+
18:14:53 <sanketj> present+
18:14:54 <westbrook> present+
18:15:13 <alisonmaher> present+
18:15:22 <JRJurman> present+
18:15:25 <sorvell> present+
18:15:30 <Di> Di has joined #webcomponents
18:16:50 <dandclark> https://1drv.ms/p/s!AtmAxiCADIM8nq09hubFJwqEsUqBDg?e=gmm2J1
18:17:00 <dandclark> present+
18:17:02 <ZoeBijl> ZoeBijl has joined #webcomponents
18:17:04 <gregwhitworth> gregwhitworth has joined #webcomponents
18:17:08 <ZoeBijl> Present+
18:17:10 <Jamie> Jamie has joined #webcomponents
18:17:16 <gregwhitworth> present+
18:17:27 <bkardell_> present+
18:17:34 <jarhar> topic: https://github.com/w3c/tpac2024-breakouts/issues/30
18:17:35 <masonf> scribenick: sanketj
18:17:44 <jocelyntran3> jocelyntran3 has joined #webcomponents
18:17:44 <kzms2> present+
18:17:59 <jyasskin> jyasskin has joined #webcomponents
18:18:03 <jyasskin> present+
18:18:18 <jocelyntran3> present+
18:18:18 <sanketj> dandclark: presenting  https://1drv.ms/p/s!AtmAxiCADIM8nq09hubFJwqEsUqBDg?e=gmm2J1
18:18:18 <aaronlev> aaronlev has joined #webcomponents
18:18:18 <rniwa> rniwa has joined #webcomponents
18:18:25 <xiaochengh> xiaochengh has joined #webcomponents
18:18:27 <Di> Di has changed the topic to: Breakout: webcomponents & ARIA - Catalina 3 - 11:15-12:15
18:18:32 <rniwa> rniwa has changed the topic to: "Custom elements and ARIA"
18:18:36 <siye> siye has joined #webcomponents
18:18:37 <Michael_Warren0> Michael_Warren0 has joined #webcomponents
18:19:05 <spectranaut_> spectranaut_ has joined #webcomponents
18:19:07 <sanketj> dandclark: Shadow roots provide encapsulation, but sometimes ID-based refs needed to cross shadow DOM, ex. ARIA
18:19:19 <sanketj> dandclark: Without totally exposing IDs and breaking encapsulation
18:19:56 <sanketj> ...: Reflected ARIA properties work for references out of shadow, but not into
18:20:11 <sanketj> ...: Focused on other direction today - unsolved problem
18:20:16 <jyasskin> Am I reading right that the first direction only works with Javascript enabled?
18:20:29 <sarah> sarah has joined #webcomponents
18:20:31 <sanketj> ...: No way to associate label outside shadow with input inside shadow
18:21:27 <sanketj> ...: Proposal is to add a property on the shadow DOM called referenceTarget to forward external ID references into shadow DOM
18:21:43 <rniwa> q+
18:21:53 <sanketj> ...: shadowrootreferencetarget for declarative shadow DOM
18:22:32 <sanketj> ...: Want this to work generally for all ID-based attrs, ie. aria, form, popovertarget, for, etc.
18:22:42 <sanketj> ...: aria-owns is an exception, reparents parts of accessibility tree, hard to get right
18:23:00 <sanketj> ...: so aria-owns excluded, no use case found for this either
18:23:18 <sanketj> ...: Would like to hear if there is a reason to support aria-owns
18:23:22 <Michael_Warren0> ive never even heard of aria-owns :)
18:23:35 <sanketj> ...: Properties are reflected in the DOM, but cannot leak shadow contents
18:23:37 <lea> present+
18:23:40 <lea> q?
18:23:42 <lea> q+
18:23:55 <sanketj> ...: Quering properties in DOM will just get the host element's info
18:24:09 <sanketj> ...: Works with nested shadow tree, can pass through to deeper shadows
18:24:24 <sanketj> ...: Prototyped in Blink already
18:24:24 <ethanjv> ethanjv has joined #webcomponents
18:25:03 <sanketj> ...: Forward looking, think about expanding to multiple ref forwarding via a ReferenceTargetMap
18:25:17 <sanketj> ...: Different attributes needed to target different elements
18:25:26 <sanketj> ...: Can name each property individually
18:25:37 <sanketj> ...: Will have both declarative and imperative versions
18:26:04 <sanketj> ...: ReferenceTargetMap and ReferenceTarget can be used together
18:26:33 <sanketj> ...: There is an open issue about reflection of properties with invariants
18:26:47 <sanketj> ...: form attr reflects form relationship, ex. a button associating with a form in shadow DOM
18:27:26 <sanketj> ...: need to reflect attr without leaking shadow contents
18:27:36 <jcraig> jcraig has joined #webcomponents
18:27:56 <sanketj> ...: One solution is to have property to reflect the host element (loosen invariant)
18:28:00 <bkardell_> null seems bad
18:28:03 <masonf> q?
18:28:05 <sanketj> ...: Another issue is association with invalid id
18:28:06 <masonf> q+
18:28:07 <sanketj> ...:
18:28:15 <sanketj> ...: No associated created, how to reflect that?
18:28:25 <sanketj> ...: One option is to return null, since no relationship
18:28:40 <sanketj> ...: But that is kind of leaking info about breakage in the shadow DOM
18:28:41 <sorvell> q+
18:28:47 <sanketj> ...: Other option is to always reflect the host.
18:29:08 <aaronlev> q+
18:29:21 <sorvell> Put this in formAssociated custom elements and provide a way to set the form the element is providing
18:29:25 <sanketj> ...: Looking for feedback on problem, solution, specific issues, etc.
18:29:30 <keithamus> q?
18:29:30 <masonf> q?
18:29:44 <lea> q-
18:29:45 <lea> q+
18:29:48 <jyasskin> q+ jyasskin to ask about CSS alignment
18:29:52 <masonf> ack justinf
18:29:58 <masonf> ack rniwa
18:30:13 <sanketj> rniwa: One interesting thing with this feature is that there is a parallel to delegatesfocus
18:30:22 <sanketj> ...: That also forwards reference inside shadow tree
18:30:48 <sanketj> ...: There was a proposal for each attribute to have a target variant.
18:30:54 <sanketj> ...: Any reason for not doing that?
18:31:14 <jarhar> q?
18:31:25 <sanketj> dandclark: Ben might know, but seems like dev ergonomics and future looking are good reasons
18:31:35 <sanketj> ...: Maybe others have more context
18:31:49 <CurtBellew> CurtBellew has joined #webcomponents
18:31:54 <sanketj> alice: That's right. Want there to be a default forwarding option.
18:32:20 <sanketj> ...: Ex: the label/input example is a good one
18:32:54 <kschmi> kschmi has joined #webcomponents
18:33:00 <sanketj> keith: having microsyntax of id-to-map is novel and might be better to avoid
18:33:01 <gregwhitworth> rniwa are you referring to cross-root aria? https://github.com/leobalter/cross-root-aria-delegation/blob/main/explainer.md
18:33:08 <sanketj> s/keith/rniwa
18:33:23 <sanketj> westbrook: microsyntax can help prevent explosion of attributes
18:33:43 <sanketj> ...: lots of new attributes being brought in
18:34:07 <jyasskin> There's the `data-` -> `dataset` precedent. Could do `shadowrootreferencetarget-aria-controls=foo`
18:34:17 <sanketj> masonf: exception would be listing them all
18:34:21 <bkardell_> +1 to what masonf said
18:34:34 <sanketj> ...: like that you only list one where the target is different from fallback
18:34:34 <lea> q-
18:34:38 <sanketj> rniwa: agree with mason
18:34:56 <TylerWilcock> TylerWilcock has joined #webcomponents
18:35:03 <masonf> q?
18:35:17 <rniwa> q?
18:35:27 <sanketj> dandclark: imperative side of reftargetmap allows you set separate properties for each of them, but listing only those differing from fallback for declarative one seems like a good thing
18:35:40 <sanketj> rniwa: maybe update delegatesfocus too in the same way
18:35:54 <sanketj> masonf: like this overall, but tricky to make sure we don't expose the shadow root
18:36:00 <sanketj> ...: more of an implementation concern
18:36:23 <masonf> q?
18:36:26 <sanketj> ...: for form property, would be compatible to switch to a different property, but not if used in wrong ways
18:36:28 <masonf> ack masonf
18:36:31 <masonf> ack sorvell
18:37:16 <sanketj> sorvell: element could provide real form inside
18:37:36 <sanketj> ...: if there was something the element could opt into, that would solve it
18:37:47 <sanketj> ...: want a real form since this is a form API
18:38:04 <sanketj> ...: correct me if i'm wrong, but we shouldn't block the core feature on this
18:38:04 <masonf> ack aaronlev
18:38:07 <sanketj> masonf: +1
18:38:35 <sanketj> aaronlev: noticed a pattern of creating a custom element and putting an aria label on it
18:38:46 <sanketj> ...: when widget is used, attr is copied
18:39:00 <sanketj> ...: problem is that there are two separate object in AX tree, can cause double speaking
18:39:27 <jamesn> q?
18:39:29 <sanketj> ...: worried that this is problematic since very hard to fix once component has starting doing this
18:39:35 <lea> q?
18:39:37 <sorvell> q+
18:39:38 <aaronlev> https://github.com/w3c/aria/issues/2303
18:39:46 <lea> q+
18:39:57 <sanketj> ...: filed above issue to give component authors to put role: none
18:40:11 <masonf> q?
18:40:13 <sanketj> ...: will allow removing element to be removed from AX tree
18:40:16 <masonf> ack jyasskin
18:40:16 <Zakim> jyasskin, you wanted to ask about CSS alignment
18:40:22 <Michael_Warren0> definitely a real issue, but imo thats separate from idref
18:40:22 <sanketj> +1 to what jyasskin
18:40:27 <sanketj> said
18:40:29 <Michael_Warren0> aria-labels arent idrefs etc
18:40:54 <sanketj> jyasskin: ref target seems inconsistent with how CSS exposes parts
18:41:01 <sanketj> ...: why?
18:41:15 <sanketj> keith: was proposed that way previously, don't remember why we moved to this
18:41:20 <sanketj> alice: that was more verbose
18:41:30 <aaronlev> Can we add my issue to a future agenda since I basically just don't want it to be dropped
18:41:32 <sarah> sarah has joined #webcomponents
18:41:34 <sanketj> masonf: this is more generic, other approach needs to know more about component
18:41:41 <aaronlev> I guess i can just file an issue in web components
18:42:02 <westbrook> q+
18:42:05 <sanketj> rniwa: in the case where you want to forward all refs to one element, much more verbose
18:42:08 <rniwa> q?
18:42:13 <masonf> ack sorvell
18:42:30 <Michael_Warren0> +1 I would argue that label -> input is a lot of the implementation that would be used
18:42:41 <sanketj> sorvell: Seen pattern of moving instead of copying
18:42:50 <sanketj> ...: Point is we need to get this feature landed
18:43:02 <masonf> ack lea
18:43:02 <sanketj> lea: Much better than prev solutions
18:43:29 <sanketj> ...: in response to Aaron, what you said highlights a big pain point, need to find a solution
18:43:55 <sanketj> ...: not just about ARIA, for native elements, need to copy properties, etc.
18:44:07 <sanketj> ...: wanted to ask if reftarget can be read outside the shadow DOM somehow
18:44:07 <westbrook> Level 2 converastion: https://github.com/WICG/webcomponents/issues/1068
18:44:28 <keithamus> q+
18:44:35 <sanketj> ...: would provide a natural solution to the 2nd open issue, will get host normally
18:44:48 <sanketj> ...: would also be nice for authors to define their own id ref down the line
18:44:51 <sanketj> ...: much much later
18:44:57 <sanketj> ...: shouldn't make that impossible though
18:45:13 <sanketj> ...: map needs to be able to ref the element itself, may need to specify the host as the reftarget
18:45:37 <Michael_Warren0> if the host is the reference target, wouldnt that just be adding an ID onto the host which is already doable?
18:45:45 <sanketj> dandclark: if reftargetmap doesn't specify reftarget explicitly, will fallback to the host
18:46:02 <masonf> ack westbrook
18:46:09 <sanketj> ...: for open shadow root, reftarget reflects actual thing in shadow tree
18:46:19 <sanketj> ...: obviously doesn't work for closed shadows
18:46:47 <sanketj> westbrook: web components CG has been reporting since 2021 that this is one of the top issues that needs to be addressed
18:47:13 <sanketj> ...: want to make sure that feature expansion doesn't block progress
18:47:41 <gregwhitworth> +1 to westbrook
18:47:44 <sanketj> ...: still good to think about level 2 and get agreement from implementors about direction
18:48:01 <sanketj> masonf: agree we are going in the right direction
18:48:06 <sanketj> smaug: me too
18:48:19 <sanketj> masonf: is reftarget is v1 and reftargetmap v2?
18:48:20 <Michael_Warren0> +1 phased approach
18:48:25 <sanketj> dandclark: yes
18:48:26 <masonf> q?
18:48:45 <lea> q+
18:48:48 <sanketj> rniwa: need to check on support
18:48:53 <sanketj> westbrook: when?
18:49:05 <sanketj> rniwa: will try to get an answer ASAP
18:49:07 <masonf> ack keith
18:49:25 <sanketj> keith: for form, submit bubble isn't composed
18:49:38 <sanketj> ...: is form already exposed via other means?
18:49:47 <sanketj> ...: if not, returning host element is fine
18:50:12 <sorvell> I don't think submit is composed, but not sure.
18:50:19 <sanketj> ...: for open shadows, if submit happens outside form, can get the form?
18:50:39 <sanketj> dandclark: don't want it to be different between open vs closed, but interesting thought
18:50:51 <sanketj> sorvell: is submit really composed?
18:51:03 <masonf> ack lea
18:51:06 <sanketj> [keith is looking]
18:51:11 <sarah> q+
18:51:27 <sanketj> lea: if reftarget ships in level 1 and reftargetmap in level 2, what are semantics of level 1?
18:51:37 <sanketj> ...: worried it won't cover any use cases
18:51:53 <sanketj> masonf: still useful when forwarding different things to different elements
18:52:19 <sanketj> rniwa: reftargetmap solves this problem
18:52:23 <sanketj> lea: but ships in l2
18:52:41 <sanketj> dandclark: reftargetmap broader solution, but reftarget still addresses simpler cases
18:52:46 <aaronlev> I filed https://github.com/WICG/webcomponents/issues/1073 for my issue about duplicated properties
18:52:49 <sanketj> ...: will eventually need l2
18:52:55 <masonf> q?
18:53:04 <sanketj> masonf: would be useful for minimal leaf nodes
18:53:19 <sanketj> westbrook: we think 80-90% of use cases to be covered
18:53:37 <sanketj> ...: perhaps authors are not making more complicated things because not possible
18:53:51 <masonf> ack sarah
18:53:52 <sanketj> ...: maybe after reftarget/reftargetmap, we'll see more of those
18:54:08 <Michael_Warren0> https://lit.dev/playground/ submit event is not composed
18:54:24 <sanketj> sarah: have a component where we can mark one element as target, works well
18:54:46 <sanketj> ...:is it possible to have a default role for custom element with reftarget/reftargetmap defined?
18:54:47 <Michael_Warren0> per a playground I just did haha
18:54:59 <keithamus> Yeah it's not composed. Click events are so if you had the button inside the form you could still get the composedpath
18:55:00 <sanketj> dandclark: feasible, need to understand about need
18:55:22 <sanketj> ...: see this as a transparent pass through shadow DOM boundary
18:55:39 <Michael_Warren0> bah, sorry for the bad link haha
18:55:59 <sarah> q?
18:56:35 <sanketj> sarah: idea is that aria-label, etc. apply to outer element but you want it applied to the inner element
18:56:46 <sanketj> ...: really want to forward everything to the shadow node
18:57:03 <sanketj> ...: would be nicer to implicitly forward rather than explicitly forwarding everything
18:57:15 <sanketj> ...: may encourage right patterns for authors
18:57:29 <sanketj> ..: proposal is to have a different default AAM mapping
18:57:39 <sanketj> alice: implicit role none?
18:57:44 <sanketj> rniwa: can be overriden?
18:57:48 <sanketj> sarah: yes and yes
18:58:05 <sanketj> dandclark: would only be if you supplied reftarget but not reftargetmap?
18:58:07 <sanketj> sarah: yes
18:58:12 <masonf> q?
18:58:15 <sanketj> ...: current default role is generic
18:58:23 <sanketj> dandclark: will follow up with sarah
18:58:27 <rniwa> q+
18:58:31 <sanketj> ...: would be possible
18:58:32 <masonf> ack rniwa
18:58:42 <sanketj> rniwa: Webkit supportive of proposal
18:59:09 <bkardell_> 🥳
18:59:11 <sanketj> lea: Support from Mozilla?
18:59:13 <westbrook> q+
18:59:13 <Michael_Warren0> woo! ship it!
18:59:17 <JRJurman> q+
18:59:22 <sanketj> everyone: Olli said yes earlier.
18:59:37 <lea> 🚀
19:00:03 <sorvell> q+
19:00:16 <sarah> sarah has joined #webcomponents
19:00:25 <sanketj> rniwa: should we move the list of attributes onto the shadow root instead of the map?
19:00:36 <sanketj> ...: would resemble delegatesfocus
19:00:46 <sanketj> lea: maybe rename delegatesfocus?
19:01:22 <sanketj> alice: I think delegatesfocus is doing something different. Picking focus based on direction.
19:01:31 <lea> delegatesReferences?
19:01:38 <masonf> ack westbrook
19:01:42 <lea> delegatesIds? delegatesTo?
19:02:00 <rniwa> rniwa: I think it might be better to have individual attributes instead of a map with a micro syntax to be consistent with delegatesFocus.
19:02:04 <sanketj> westbrook: do we have a spec writer on board? that would be helpful
19:02:24 <sanketj> dandclark: i'll do it, unless others want to be onboard
19:02:34 <rniwa> q?
19:02:37 <sanketj> keith: i'll do it with Dan
19:02:41 <masonf> ack jrjurman
19:02:51 <sanketj> alice: i'll help Dan and Keith work on the spec
19:03:23 <sanketj> jesse: when custom element wraps an input, can we just inherit the role onto the host?
19:03:31 <sanketj> keith: shadow roots are transparent
19:03:42 <sanketj> ...: want the opposite, role should be none or generic
19:03:53 <masonf> ack sorvell
19:04:01 <sanketj> masonf: yeah, would cause two nested elements with same role
19:04:15 <sanketj> sorvell: can we avoid long, verbose attribute names?
19:04:22 <lea> q?
19:04:22 <sanketj> ...: can we revisit something like data-?
19:04:24 <keithamus> q+
19:04:25 <Michael_Warren0> q+
19:04:31 <sanketj> ...: no concrete proposal though
19:04:33 <masonf> ack keith
19:04:52 <sanketj> keith: don't mind on the attribute names, but microsyntax is worse than attributes
19:05:19 <lea> qq+ to say +1 for shorter attributes, but we need to avoid hyphens so we can have the option of custom attributes open
19:05:23 <sanketj> ...: easy to bundle attrs using templating libraries
19:06:20 <sanketj> sorvell: isn't that what happens with export parts?
19:06:28 <sanketj> rniwa: semantics very different
19:06:38 <masonf> ack lea
19:06:38 <Zakim> lea, you wanted to react to keithamus to say +1 for shorter attributes, but we need to avoid hyphens so we can have the option of custom attributes open
19:06:39 <sanketj> ...: may be an argument for not doing microsyntax
19:06:55 <masonf> q?
19:06:56 <sanketj> lea: custom attributes should still be explored
19:07:07 <masonf> ack Michael
19:07:33 <sanketj> Michael_Warren: shorter attrs would be nice, especially people that hand write shadow DOM
19:07:38 <sanketj> ...: not everyone uses a build tool
19:07:45 <masonf> q?
19:08:04 <lea> +1 to "not everyone uses a build tool"
19:08:28 <sanketj> dandclark: Next step is to write the spec, continue to work on prototype, potentially consider OT in Blink
19:08:40 <sanketj> masonf: Can we come back to the form question? Since we didn't get an answer.
19:08:55 <sanketj> dandclark: Also the question about broken ref.
19:09:02 <sanketj> masonf: Should just return the host?
19:09:09 <sanketj> lea: yes
19:09:41 <sanketj> lea: AX tree would also fallback to host, right/
19:09:42 <masonf> q?
19:09:42 <sanketj> ?
19:09:48 <sanketj> dandclark: yes
19:09:55 <Michael_Warren0> q+
19:10:10 <sanketj> keith: would be good to try this on a test bench
19:10:25 <sanketj> ...: hard to come up with the expected answer
19:10:29 <masonf> ack Michael
19:10:36 <sanketj> ...: weak argument though
19:11:00 <alice> q+ to go back to the <form> question if we have tiem
19:11:16 <sanketj> Michael_Warren: Someone said id ref different than other ARIA references. How different are the implementations?
19:11:50 <sanketj> dandclark: reftarget as proposed is not limited to ARIA
19:11:58 <sanketj> ...: supports all id based lookups
19:12:34 <sanketj> masonf: string based ones could technically be adapted too
19:12:46 <sanketj> rniwa: are we adjusting svg use too?
19:12:50 <sanketj> lea: uses href, not id
19:13:14 <sanketj> rniwa: resolved to change semantics, does use id for things with that SVG tree
19:13:23 <sanketj> dandclark: not adjusted those
19:13:37 <sanketj> rniwa: may need to review where id lookup is done
19:13:46 <masonf> q?
19:13:55 <rniwa> q?
19:14:02 <masonf> ack alice
19:14:02 <Zakim> alice, you wanted to go back to the <form> question if we have tiem
19:14:32 <sanketj> alice: RE form question: Not sure about issues from leaking, but tells info about host, which means it can 'act' as an element you are targeting
19:14:35 <sanketj> keith: what about .form today on an element?
19:14:45 <sanketj> ...: that's undefined, right?
19:15:11 <sanketj> dandclark: yeah, might be compat since it returns null today and now invalid ref would cause it to return the host
19:16:47 <sanketj> keith: Restating... .form returns null if element not form participant, but if reftarget always fallbacks to host, then .form will always fallback to the host element and look like a form participant
19:17:10 <sanketj> dandclark: Maybe a good principal is that reftarget won't change property reflections or other internal associations
19:17:43 <xiaochengh> q+
19:17:54 <sanketj> ...: For aria properties, would just change those internal associations, but not the property reflections
19:18:21 <sanketj> keith: No way to use form property on custom element, right?
19:18:49 <masonf> ack xiaochengh
19:19:08 <sanketj> xiaochengh: Maybe shouldn't push reftargetmap to level 2?
19:19:30 <sanketj> lea: That's a lot more complex. Forwarding everything to one element is simpler and addresses a lot of use cases.
19:19:45 <sanketj> xiaochengh: Risky. Ex: How do we address form?
19:20:31 <sanketj> masonf: Maybe we try to address all properties first and strive for reftarget only in level 1.
20:10:33 <rniwa> rniwa has joined #webcomponents
20:10:53 <rniwa> rniwa has changed the topic to: "Open styleable shadow tree and theming"
20:15:35 <JRJurman> JRJurman has joined #webcomponents
20:16:25 <JRJurman> present+
20:16:35 <rniwa> present+
20:17:42 <masonf> masonf has joined #webcomponents
20:17:47 <masonf> present+
20:17:56 <sorvell> present+
20:18:01 <jarhar> jarhar has joined #webcomponents
20:18:49 <kizu6> kizu6 has joined #webcomponents
20:19:05 <kschmi> kschmi has joined #webcomponents
20:19:13 <kbabbitt> kbabbitt has joined #webcomponents
20:19:20 <kbabbitt> present+
20:19:24 <miriam> miriam has joined #webcomponents
20:19:29 <TabAtkins> TabAtkins has joined #webcomponents
20:19:46 <sorvell> https://github.com/w3c/tpac2024-breakouts/issues/27#issuecomment-2366847629
20:19:53 <miriam> present+
20:19:53 <ray-schwartz> ray-schwartz has joined #webcomponents
20:20:02 <kizu6> present+
20:20:04 <giacomo-petri> giacomo-petri has joined #webcomponents
20:20:12 <robglidden> robglidden has joined #webcomponents
20:20:21 <oriol> present+
20:20:22 <sorvell> q+
20:20:47 <masonf> ack sorvell
20:21:09 <justinf> justinf has joined #webcomponents
20:21:20 <justinf> q+
20:21:51 <alisonmaher> alisonmaher has joined #webcomponents
20:21:59 <alisonmaher> present+
20:22:19 <dandclark> present+
20:22:24 <dandclark> scribenick: dandclark
20:22:49 <dandclark> sorvell: Let's focus discussion on theming if we can, goals for how to do that. My 2c is we have two tools, custom props and parts
20:22:52 <fantasai> fantasai has joined #webcomponents
20:23:06 <dandclark> ...: Custom props apply narrowly and deeply , parts apply to any prop but shallowly
20:23:17 <dandclark> ...: Can we explore how to make parts apply deeply across the tree
20:23:26 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-webcomponents-minutes.html fantasai
20:23:41 <emilio> emilio has joined #webcomponents
20:23:41 <emilio> present+
20:23:41 <dandclark> ...: We have export parts which are broken. No traction on issue. Simple fix is to expose via wildcards
20:23:46 <dandclark> ...: Have exponential @@@, have levels of shadow roots
20:23:49 <fantasai> s/...:/.../g
20:23:49 <westbrook> https://github.com/w3c/tpac2024-breakouts/issues/27#issuecomment-2366847629
20:23:50 <keithamus> https://github.com/WICG/webcomponents/issues/1051
20:24:12 <RRSAgent> I have made the request to generate https://www.w3.org/2024/09/25-webcomponents-minutes.html fantasai
20:24:31 <dandclark> ...Open styleable should be very specific tool to facilitae migrating old stylesheets
20:24:33 <masonf> q?
20:24:39 <dandclark> ...Can discuss all of this in detail if we get there
20:24:49 <masonf> ack justin
20:24:54 <dandclark> justinf: Want to reiterate, discuss theming outside open styleable
20:25:16 <sorvell> q
20:25:21 <sorvell> q+
20:25:28 <dandclark> ...Want to take step back. We had ::parts selector and ::theme selector. Have idea on ::theme I'd like to talk about
20:25:31 <masonf> q+
20:25:38 <dandclark> ...Have two tools, one is deep, want to find something in between
20:25:52 <dandclark> ...Theme was blocked because people didn't want part attribute to imply something could be themed
20:25:57 <masonf> ack sorvell
20:26:25 <dandclark> sorvell: I want to plant early seed -- I highly doubt we'll get that far today on defining theme thing. Lots of related issues. Want to see CSSWG get more involved
20:26:41 <dandclark> ...Especially because discussing how to match things across compose tree, how combinators work
20:27:02 <dandclark> masonf: The way you started as we should work on open styleable because it's easier.
20:27:03 <rniwa> q+
20:27:11 <dandclark> justinf: They're different topics
20:27:14 <rniwa> ack masonf
20:27:29 <dandclark> ...Theming is adding hew capability for deep theming across shadows
20:27:43 <dandclark> sorvell: Open styling is simple proposal blossoms into different issues.
20:27:56 <dandclark> masonf: There's like 10 different use cases from I have a shadow and want to style
20:28:10 <dandclark> justinf: Need a solution that works for existing sheets.
20:28:30 <dandclark> masonf: I've heard use case of I have existing styles, and I have global styles that I want to apply to a button
20:29:03 <masonf> ack rniwa
20:29:28 <dandclark> rniwa: Stepping back, we are trying to solve problem of you have a stylesheet in main doc, and want some part to apply to shadow.
20:29:44 <sorvell> q+
20:29:46 <dandclark> ...People arguing these are sufficiently different to need 2 solutions. Do people agree?
20:29:49 <masonf> ack sorvell
20:30:08 <dandclark> sorvell: yes. Open styleable blows away any type of encapsulation because everything is targetable. Theming API doesnt.
20:30:14 <Michael_Warren0> q+
20:30:24 <dandclark> rniwa: Depends on what you mean by open shadow tree. Depends on semantics of what we define
20:30:36 <dandclark> masonf: Can hit use cases if you can control with an option
20:30:48 <dandclark> sorvell: Every shadow applying to shadow is very brittle
20:30:58 <dandclark> ...vs something like part where you explicitly state everything you want to style
20:30:58 <masonf> ack Michael
20:31:15 <dandclark> Michael_Warren0: I don't think it breaks all encapsulation. Breaks outside in.
20:31:35 <dandclark> ...That's what folks who are used to how framework components expect.
20:31:38 <gregwhitworth> to throw a wrench in this I would prefer to have web components and slots not require a shadow
20:31:42 <dandclark> ...The styles declared in component can't get out, but styles outside can get in
20:31:56 <justinf> q+
20:32:00 <dandclark> ...Doesn't break all encapsulation that way. Breaks outside in but in a way folks want.
20:32:07 <masonf> +1 that's the complaint I've heard the most.
20:32:11 <dandclark> ...They have to deal with this today with React components
20:32:51 <sabidussi_marco> sabidussi_marco has joined #webcomponents
20:33:04 <dandclark> ...In some respects to the q of whether theyre sufficently different, comes down to the stylesheets. Looking at the issue there's not a lot of desire for limited API. Desire is for full application, and folks must manage risk of collisions
20:33:05 <masonf> ack justin
20:33:28 <dandclark> justinf: Open styleable and theming are different set of capabilities. What we walked about with `::theme` was related to parts
20:33:57 <dandclark> ...Opening up shadow root is how you expose stuff in shadow. What is the role of part in this? Want something more controlled that doesn't throw out encapsulation.
20:34:03 <gregwhitworth> justinf can you give/link to a quick summary/recap of your impression of ::theme?
20:34:14 <dandclark> ...Theme selector can target parts deep in shadow tree. Doesn't loose validity because we have this other use case.
20:34:22 <sorvell> q+
20:34:36 <dandclark> ...We can make a more targeted API. We went down that path but didn't finish.
20:34:37 <masonf> ack sorvell
20:34:42 <masonf> q+
20:34:44 <dandclark> sorvell: I want to echo Justin. This is a 'yes and'.
20:35:17 <Michael_Warren0> headless components is another big feature for open-stylable. in the case of headless comps where you do want to open up "all" of the internals for styling from the outside, how would ::theme work for that?
20:35:30 <gregwhitworth> q+
20:35:33 <dandclark> ...Problem is there are lots of use cases. Think if you did this with input. That div that you have contenteditable in, author can style it. This is about finishing part, making it reasonable. Like with open and closed shadow, there are different use cases.
20:35:37 <rniwa> q+
20:35:38 <dandclark> ...You can do this today
20:35:39 <miriam> q+
20:36:03 <Michael_Warren0> if ::theme is meant to not be an "all stylable" solution, we'd have to also solve for headless components too in an "unlimited" kind of way that might be cumbersome from the limitations of what ::theme would have
20:36:08 <sorvell> q+
20:36:16 <dandclark> masonf: There are 2 viewpoints in the room. Webcomponents users and webcomponent authors. Have heard often, 'I want slots'. Just want styles to keep working. That's the perspective of component users.
20:36:23 <masonf> q?
20:36:23 <dandclark> ...We keep going back and forth between those
20:36:24 <masonf> ack mason
20:37:06 <dandclark> justinf: I disagree with that characterization. People have problem with trying to fit component into page with existing stylesheet. People creating new components try the best they can with CSS custom props. Have limited styleability so can limp along with that.
20:37:25 <dandclark> masonf: Theres back compat, but also people used to doing this with non-shadow pages. They want to keep doing that.
20:37:30 <masonf> ack greg
20:37:49 <dandclark> gregwhitworth: 2 points. I feel like it's been eternity since I've seen what `theme` is. Is there a link?
20:38:00 <dandclark> TabAtkins: Variant on `part`. Doesn't exist in spec now.
20:38:12 <westbrook> https://css-tricks.com/part-theme-explainer/
20:38:32 <westbrook> Woops link through: https://meowni.ca/posts/shadow-dom/
20:38:47 <lea> q+
20:38:49 <dandclark> gregwhitworth: At salesforce we've moved away from native webcomponents. We have 3p extensions. People use extensions for e.g. a11y. They don't support native webcomponents.
20:39:10 <dandclark> ...We convert slots into light DOM
20:39:11 <westbrook> Inability to copy/paste right today: https://meowni.ca/posts/part-theme-explainer/
20:39:20 <masonf> q?
20:39:25 <dandclark> ...Don't get `slotted`, don't get `part`, but @@@ just works
20:39:28 <masonf> ack rniwa
20:39:57 <dandclark> rniwa: I think solution for open styleable shadow and theming could be coherent with each other. Have one solution with ability be strict
20:40:07 <dandclark> ...Could also apply all the styles. No design restriction that these need to be separate.
20:40:19 <dandclark> ...Not saying that's what we want but we should consider the possibility.
20:40:25 <dandclark> ...Problem seems to come up in many use cases.
20:40:38 <dandclark> ...Don't want 3-4 solutions to same problem. Want single solution for most use cases. Or maybe 2 solutions.
20:40:51 <gregwhitworth> +1 to @rniwa
20:40:55 <masonf> ack miriam
20:41:15 <dandclark> miriam: As author of page using components, and author of components, don't think it breaks down so easily.
20:41:24 <dandclark> ...Sometimes I have specialized parts, so part approach makes sense
20:41:31 <dandclark> ...But sometimes I just have a button I want you to style
20:41:43 <dandclark> ...`part` doesn't work great, need to give button a specialized name.
20:42:10 <dandclark> ...The other thing with `part` is that sometimes I have chunk of component I want to keep specialized. And other parts I want to expose for styling.
20:42:14 <dandclark> ...So not total either-or.
20:42:30 <dandclark> ...Want to expose some parts for global styles, and expose others selectively or keep hidden.
20:42:32 <gregwhitworth> +1 to miriam  as our base components team uses native shadow for this
20:42:36 <dandclark> ...So it's a false dichotomy.
20:42:42 <masonf> ack sorvell
20:43:04 <masonf> q+
20:43:14 <dandclark> sorvell: I agree with that. Enhancing parts is what I want to focus on because I think it's straightforward. But not a full set of solutions.
20:43:44 <masonf> ack lea
20:43:46 <dandclark> ...Potentially advancing open styleable helps with this. To mason -- I agree people want light dom slotting but I don't know how. Want your ideas, but separately
20:44:17 <gregwhitworth> Here is LWC's light DOM which takes a web component and renders it in Light DOM: https://lwc.dev/guide/light_dom
20:44:19 <dandclark> lea: Current style encapsulation is barrier for shadow DOM. One case is templating. Reusable widgets to enhance what HTML is able to do.
20:44:26 <justinf> a few slides on an idea for how to make ::theme() work with parts: https://docs.google.com/presentation/d/13GJAJ_1WwxwTmusXnfobveDdYdaOr1TW-YRPhCzLDtg/edit?usp=sharing
20:44:30 <rniwa> q+
20:44:31 <dandclark> ...All or nothing works well for templating, but not for reusable widgets
20:44:41 <dandclark> ...Encapsulation of some degree is desirable
20:44:56 <dandclark> ...right now we have the nothing, open styleable is the all, nothing cover all use cases
20:45:06 <dandclark> ...Want to opt in specific nodes, or remove specific nodes from what is exposed
20:45:26 <miriam> (this is still using the dichotomy that I'm trying to argue against)
20:45:30 <dandclark> ...Not saying open styleable shouldn't advance, it covers chunk of use cases. But we need more granularity.
20:45:37 <dandclark> ...I posed proposal yesterday about exposing a subset.
20:45:50 <miriam> q+
20:45:55 <dandclark> ...Not sure if want to center discussion around that, main focus is the problem
20:46:10 <sorvell> q+
20:46:13 <dandclark> ...I don't think I've ever needed full open styleability.
20:46:30 <dandclark> ...There's always something you don't want to expose. But almost everything is exposed when you use parts.
20:46:35 <TabAtkins> Big +1 on the "almost is important here"
20:46:49 <masonf> ack mason
20:46:50 <dandclark> masonf: Rniwa has good point that more granular API can maybe handle fully open styles.
20:46:52 <masonf> ack rniwa
20:47:07 <justinf> +1. another thing people don't always want to expose is the tree structure relationship between parts... yes, sometimes they do
20:47:10 <dandclark> rniwa: Going back to use cases, expanding `part` is one approach.
20:47:26 <dandclark> ...Can generalize it, make it work across different trees. That's `theme`
20:47:41 <dandclark> ...Other approach is define back of props in CSS, have a way to apply those in your tree
20:47:50 <dandclark> ...And I'm sure there are other proposals
20:47:58 <lea> In the spirit of throwing ideas out, here’s the very very rough draft I mentioned: https://github.com/w3c/csswg-drafts/issues/10939
20:48:24 <masonf> ack miriam
20:48:24 <dandclark> ...Can we go through more concrete proposals and evaluate which is more suitable for the use cases. People have vague ideas of what it should look like, but have been very vague about how we will accomplish it.
20:48:26 <Michael_Warren0> q+
20:48:27 <lea> though thinking some more, I wonder if what is more suitable is opting nodes *out*, rather than opting them *in*
20:48:59 <dandclark> miriam: I keep hearing assumption about this dichotomy that's not my experience. Mine is not that either i'm providing should or should not be fully styleable
20:49:15 <dandclark> ...My assumption is always the page author knows what styles should or should not go inside
20:49:23 <lea> q?
20:49:30 <dandclark> ...And from both ends I want to apply some of my global styles to some of the things in the component
20:49:34 <bkardell_> +1 to that bit Mia just said
20:49:39 <dandclark> ...It's not simple dichotomy
20:49:48 <dandclark> masonf: Makes sense, but what's the API look like?
20:49:48 <masonf> ack sorvell
20:50:03 <dandclark> sorvell: I agree, we need to look at this as differnt pieces of overall puzzle.
20:50:07 <justinf> q+
20:50:32 <dandclark> ...I want to focus on what I see as easier problem: We have syntax which is for opting parts of trees in, that's `part`. But falls over with composition. Exportparts sucks
20:50:41 <dandclark> ...Because no wildcards. So should add those
20:50:44 <masonf> qq+
20:50:47 <dandclark> ...But still sucks, it's too fiddly
20:50:52 <TabAtkins> Wildcards are an easy fix, sorvell's exact idea was proposed back in 2018 (I linked in the issue)
20:51:02 <dandclark> ...Deep composition -- inside this special container thing I want to target some buttons, I need combinators
20:51:06 <sanketj> q+
20:51:17 <dandclark> ...Shadow and deep from v0 spec was combinators into shadows
20:51:20 <westbrook> q+
20:51:23 <masonf> q-
20:51:32 <dandclark> ...We'd go really far with that capability but restricted to the `part` tree.
20:51:39 <dandclark> ...Then we have that aspect of theming
20:51:47 <dandclark> ...But don't know how that works in CSS
20:52:06 <dandclark> ...Those 2 thinks, fixing exportparts and making parts deeply addressable; at least for that aspect of the puzzle moves the ball forward
20:52:20 <dandclark> TabAtkins: Lea linked proposal from a few days ago that's exactly what you're saying sorvell.
20:52:27 <sanketj> q-
20:52:29 <dandclark> sorvell: Thanks!
20:52:37 <justinf> can someone repost the link?
20:52:51 <dandclark> masonf: The specific proposal is `part` exposes part of the tree but it painful to use, so this @@@.
20:53:05 <masonf> ack Michael
20:53:32 <TabAtkins> s/@@@/exposes all the parts as a reduced version of the shadow tree, selectable with combinators/
20:53:39 <dandclark> Michael_Warren0: It's tempting to think about the problem and solution from component perspective. But it's multidimensional. Depends on who you are relative to the cmponent and the application that's using it
20:53:40 <justinf> lea do you ahve the proposal link?
20:53:53 <lea> justinf: https://github.com/w3c/csswg-drafts/issues/10939
20:53:57 <justinf> thanks!
20:54:14 <dandclark> ... @@@ isn't necessarily theming because I'm not just changing a color, there are other bigger things like layout I'm changing.
20:54:39 <dandclark> ...E.g. Shoelace, author has no knowledge  of what exists in the component
20:54:56 <rniwa> q?
20:55:09 <masonf> ack justin
20:55:09 <dandclark> ...Want to narrow down the relationship between the component and the environment.
20:55:20 <westbrook> q-
20:55:20 <sorvell> Thanks so much Lea, this proposal is amazing (https://github.com/w3c/csswg-drafts/issues/10939)
20:55:27 <dandclark> justinf: To rniwa's point about concrete proposals. We had thing that exist, CSS props and parts
20:55:43 <dandclark> ...upcoming CSS features like mixins, vague versions of `theme`. Each has pros and cons.
20:55:55 <dandclark> ...gatherting that might help us make a rubric for evaluating other things.
20:56:05 <sorvell> q+
20:56:37 <dandclark> ...Important aspect of the solution is you can potentially merge different styles.
20:56:56 <masonf> ack sorvell
20:57:01 <dandclark> ...If you go through these you will come up with the types of objectsions you'll need to just solutions by
20:57:22 <dandclark> sorvell: We use style isolation in shadowDom as big hammer for core problem with CSS
20:57:46 <dandclark> ...Want page to have styling policy where I say some user of lib can style certain things. But can't style others.
20:57:58 <dandclark> E.g. input has placeholder. Lots of props you can set on placeholder that break the input.
20:58:09 <dandclark> s/E.g./...e.g.
20:58:20 <dandclark> ...If browser had way to limit what you can do with that, that would be good
20:58:33 <lea> thanks sorvell, glad I posted it then! Took me a while to press the submit button, I thought it was so outside the Overton window and so ambitious that I'd lose all credibility 🤣
20:58:33 <dandclark> ...It's just a CSS concept we don't have.
20:58:41 <masonf> q?
20:58:42 <dandclark> ...For lack of better word I'm calling it a policy
20:58:50 <justinf> q+
20:58:56 <masonf> ack justin
20:59:29 <dandclark> justinf: Looking at nonwebcomonent solutions as well. It's common in corporate environments it's common to have policy that bans certain selectors. Have to use opaque classnames.
20:59:36 <dandclark> ...That's common with solutions like userland CSS modules
20:59:53 <dandclark> ...Points to people not using selectors like they could.
21:00:03 <dandclark> ...Maybe also indicates we don't need the full selector feature set.
21:00:12 <dandclark> ...People get by now using IDs and opaque classnames.
21:00:14 <masonf> q?
21:00:31 <gregwhitworth> q+
21:00:36 <dandclark> ...I worry about exposing tree structure relationship of parts. Hvae seen components change where that changes, so that's a breaking change for the component.
21:00:36 <gregwhitworth> ack gregwhitworth
21:00:48 <sorvell> +q
21:00:54 <masonf> ack sorvell
21:01:04 <masonf> q+
21:01:34 <JRJurman> q+
21:01:37 <rniwa> q+
21:01:38 <dandclark> sorvell: I think this is a big space. Have webcomponents CG but don't have CSS horsepower in that group. Want more participation. Know there's interest in CSSWG but not sure how we can do that. Ideas for that would be awesome
21:01:40 <sanketj> q+
21:01:45 <justinf> q+
21:01:52 <dandclark> masonf: ONe specific idea was `::part` with some combinator. Can we look at that more?
21:01:59 <masonf> ack mason
21:02:04 <masonf> ack jrjurman
21:02:57 <dandclark> JRJurman: Thinking about what greg mentioned, I get the sense that as people put out components, if there was some way to expose some part for styling, there will probably be pressure to expose the whole thing. E.g. extensions that want to change everything.
21:03:22 <dandclark> ...Not sure if I'd ever want to say I"m making a thing and only some can be styled, then anticipate github issues about wanting more to be styleable
21:03:38 <dandclark> ...If people want to style it, there's pressure to let them
21:03:39 <masonf> ack rniwa
21:03:57 <dandclark> rniwa: focusing on theming use cases might be valuable way to limit discussion. Problem space is v big.
21:04:18 <dandclark> ...Despite I said needs to be solution for all of them, maybe don't need solution for all use cases.
21:04:22 <sorvell> q+
21:04:30 <masonf> ack sanket
21:04:34 <dandclark> masonf: +1 let;s pick solution and see what cases it solves
21:04:48 <dandclark> sanketj: I agree. Let's outline what proposals we have, what they solve.
21:04:54 <justinf> I'd like to present an idea for ::theme() that I think addresses a lot of problems with parts
21:04:55 <Michael_Warren0> +1 to Lea's proposal above. It seems like it would work for headless components (ie, in a tailwind global css env) and would work for design systems like web awesome
21:05:01 <dandclark> ...Maybe there's some lines we can continue to bring discussion forward
21:05:02 <masonf> ack justin
21:05:54 <justinf> https://docs.google.com/presentation/d/13GJAJ_1WwxwTmusXnfobveDdYdaOr1TW-YRPhCzLDtg/edit#slide=id.g2f8ba040b01_0_0
21:06:21 <dandclark> justinf: Tab and I looked at theme. Big problem was it selected too many things. People that added part attrs to their shadow maybe dind't want those to be exposed all the way up the tree
21:06:34 <dandclark> ...Component using child component doesn't necessarily want to expose all the child parts for theming
21:06:41 <dandclark> ...So wanted to make theming more targeteable.
21:07:16 <Michael_Warren0> to justin's point, a good thing about lea's proposal above is that it doesnt need names that would have conflicts
21:07:27 <dandclark> ...Also need a way to filter by host, but not by host tag name, might be different by component. Want host to opt into exposing things as theme, and establish some identifier for those. When selecting for those, select some theme name and part.
21:07:41 <Michael_Warren0> the point about having naming conflicts is a good one, so imo a solution should prevent that
21:07:42 <dandclark> ...Goes deeply down the page, is coherent with parts but more targeted.
21:08:06 <dandclark> ...Goes a long way towards letting design systems do what they want
21:08:12 <masonf> ack sorvell
21:08:17 <dandclark> sorvell: I think that's interesting idea.
21:08:21 <TabAtkins> I'd love to see that written as a rough proposal, it would help me understand it a little better.
21:08:44 <dandclark> ...The reason I like having solution that includes combinators is my mental model for sytling is needs to satisfy: want to style one, want to style all, want to style some, where typically that's some subtree
21:08:50 <lea> +1 to sorvell
21:09:26 <dandclark> ...Main point is: we have exportparts. We have parts. Not great, cumbersome -- don't work because need to export parts on all the things, becomes burdensome.
21:09:32 <TabAtkins> +1 to this
21:09:38 <dandclark> ...Adding wildcards is very simple way to achieve something useful
21:09:46 <dandclark> justinf: It's more broken because of name collisions
21:09:59 <westbrook> https://github.com/WICG/webcomponents/issues/1051#issuecomment-2375196189
21:10:03 <dandclark> TabAtkins: Forwarding and prefix-changing was part of original proposal
21:10:21 <dandclark> sorvell: It's completely unusable. Shoelace uses but that's about it because it's so cumbersome
21:10:22 <masonf> q?
21:10:29 <TabAtkins> exportparts="*" to forward all as-is, exportparts="foo-*: bar-*" to forward all the foo- prefixes, replaced with bar- prefixes
21:10:32 <dandclark> masonf: Seems like separate issue, but a good one
21:11:54 <kschmi> https://github.com/w3c/csswg-drafts/issues/10939
21:12:00 <masonf> Go here https://www.w3.org/events/meetings/19813be0-9902-4bad-8d50-3ad49ba792e6/
21:12:01 <Michael_Warren0> export parts seems tricky. if lea's proposal gets traction, i could see export parts being deprecated in favor of that feature. lea's proposal seems to be a re-imagining of parts in a more robust way
21:12:04 <masonf> and click the join button
21:13:30 <dandclark> sorvell: I beg your patience because I respec the people in this room. One of the things as a component user is when there's awesome new stuff added CSS, but we wonder if it will work in shadow DOM.
21:13:47 <dandclark> ...The more we can make stuff so these questions are worked out the better. E.g. how does `has` work with shadow DOM is unclear
21:13:47 <Michael_Warren0> +1000 to awesome css features in shadow dom
21:13:57 <dandclark> ...The more we can get a genral solution the better
21:14:02 <dandclark> lea: <presents her new proposal>
21:14:10 <dandclark> ...Filed this yesterday, wasn't sure if should post
21:15:11 <dandclark> ...Was thinking part is a huge pain point both when defining and using components. When defining because have to expose with reasonable names. When using you have to figure out names, build mental model of how fits together, and there's still stuff you can't do
21:15:40 <dandclark> ...I was thinking what is the real author intent? It's that we want to expose subset of shadow tree with `part`.
21:15:44 <dandclark> ...When people use part, over 90% of elements are exposed
21:15:51 <dandclark> ...Usually need reason *not* to expose something
21:16:02 <dandclark> ...Open styleable sort of solves this but usually still need to hide something
21:16:19 <dandclark> ...What if we had html attribute -- tentatively `export`; it just exports that element
21:16:36 <dandclark> ...Introduce combinator that gives you access to this exposed subtree. Don't know if you need mutiple or just once works
21:16:51 <justinf> q+
21:16:53 <dandclark> ...That subtee only consists of exposed elements.
21:16:55 <sorvell> q+
21:17:08 <dandclark> ...Within it, selectors just work normally but only apply to that subtree
21:17:31 <dandclark> ...You could even use attribute selectors on `part` , making `part` work better
21:17:53 <dandclark> ...Can introduce more granularity, cutting out subtrees, or even granularity on sub-element level
21:18:10 <Michael_Warren0> q+
21:18:13 <emilio> q+
21:18:14 <dandclark> ...Can even introduce syntax to allow aria to hook in
21:18:29 <dandclark> ...Or other parts of the platform. Depends on the overlap of what elements you want to expose for styling and for other purposes
21:18:44 <dandclark> ...Can also be used with native elements, instead of introducing a bunch of new pseudos
21:19:08 <dandclark> ...Maybe the element type would not be exposed so you can't use type selectors
21:19:20 <dandclark> ...Could even end up with a different structure then what you originally had
21:19:38 <dandclark> ...<walks though example with spinner, where exposed subteee is different>
21:19:58 <dandclark> ...But it could break expectations e.g. if you're applying grid
21:20:00 <dandclark> ...But part has the same problem
21:20:01 <bkardell_> q+
21:20:18 <miriam> q+
21:20:26 <bkardell_> q-
21:20:39 <rniwa> q?
21:20:59 <dandclark> ...Open questions: Has access to full flattened subtree? And what if the better approach is to opt out rather than opt in?
21:21:09 <masonf> ack justin
21:21:32 <miriam> q-
21:21:41 <dandclark> justinf: think we need virtual DOM in this other place, where component can produce virtual subtree.
21:21:59 <dandclark> ...One detail is that custom element tagnames aren't reliable as selectors. Host needs to apply a stable label.
21:22:31 <dandclark> ...Material-button could be under any tagname. For this type of component, I want to expose this type of thing inside of it. That applies deeply
21:22:37 <dandclark> lea: You can just use part
21:22:44 <dandclark> justinf: But that's applied from the outside
21:22:44 <emilio> q-
21:23:24 <masonf> ack sorvell
21:24:09 <dandclark> sorvell: I like the direction of this. Exploring stuff like how do you want to export this is good. Might have internal classes I don't want to expose, but fine to export others. Other thing i want to expore is it seems like we're circling this idea of a policy of how I want to expose styling. Does this idea need to be locked in shadow DOM?
21:24:23 <dandclark> ...I'm describing what I want to be styleable. That's sort of what scope is doing
21:24:30 <masonf> ack michael
21:24:36 <miriam> Scope is selector-in. It can't handle this sort of thing
21:24:51 <miriam> This sort of policy has to be DOM-out
21:25:02 <dandclark> Michael_Warren0: I think about this a lot -- stable names. Concern I have is applying that selector uses something considered internal to that component if it were a 3p. That introduces brittleness.
21:25:35 <dandclark> ...The component could change, that thing we exposed might not be the same anymore. Could break every selector. Needs to be something that isn't selector based. Maybe proposal doesn
21:25:56 <dandclark> ...'t let you use those. It's a place that can introduce brittleness. Class name might not exist later.
21:26:11 <sorvell> Rough... `@scope ... { appearance: exports-only; ... }`
21:26:11 <dandclark> masonf: Adding this export to your shadow means you're adding it to contract of your component
21:26:17 <astearns> q?
21:26:44 <dandclark> justinf: Might have classes that are internal that you don't want to be exposed. @@@
21:27:14 <dandclark> Michael_Warren0: I might refactor the component in a way that I don't know if it's breaking, because I don't know who's querying it.
21:27:27 <dandclark> ...Might want to thing about putting stable names back in this.
21:27:53 <miriam> sorvell: Happy to follow up on that at some point (an issue?) but I'm not sure what you see that scoped appearance property doing.
21:27:53 <dandclark> ...Want to make them truly stable so they can't be changed
21:28:12 <dandclark> lea: I heard discussions about theming. that's what the next breakout is about, but on a lower level
21:28:19 <astearns> https://www.w3.org/events/meetings/a9540089-cb3a-413b-966a-8c1034b31b11/ for the possible next session
21:40:03 <masonf> masonf has joined #webcomponents
21:44:05 <rniwa> rniwa has joined #webcomponents
21:44:15 <rniwa> rniwa has changed the topic to: "CSS Modules"
21:46:11 <kschmi> kschmi has joined #webcomponents
21:46:12 <annevk> annevk has joined #webcomponents
21:46:22 <alisonmaher> alisonmaher has joined #webcomponents
21:46:26 <alisonmaher> present+
21:46:41 <ethanjv> ethanjv has joined #webcomponents
21:46:44 <kouhei> kouhei has joined #webcomponents
21:46:46 <emilio> rniwa: dan, can you summarize the state of the proposal?
21:47:00 <westbrook> present+
21:47:01 <westbrook> q+
21:47:06 <emilio> dandclark: I can try to summarize the current state after this morning's discussion
21:47:18 <rniwa> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md
21:47:48 <emilio> dandclark: css modules allow you to import your styles from CSS and then apply them dynamically with adopted stylesheets
21:48:05 <emilio> ... I can have just one stylesheet and I can apply it to all those different shadow trees
21:48:10 <emilio> ... that all works quite nicely
21:48:20 <emilio> ... with declarative shadow dom this isn't the full story
21:48:31 <emilio> ... because I don't want to need script to do this
21:48:47 <emilio> ... we can look at other solutions to apply styles to declarative shadow trees
21:49:09 <emilio> ... inline styles are not great and duplicate stuff
21:49:19 <emilio> ... css modules might be the best way of dealing with this
21:49:42 <emilio> kschmi: I think something like this (slide 5) is the best way to go
21:49:51 <emilio> ... we had some discussion about <script> vs. <template>
21:49:56 <emilio> ... all of them have pros and cons
21:50:07 <emilio> ... <style> would apply to the light dom which we don't want
21:50:22 <emilio> annevk: <style type=module> won't right?
21:50:52 <emilio> kschmi: older browsers will apply it
21:50:57 <emilio> annevk: they shouldn't right?
21:51:12 <emilio> ... <style type=module> doesn't style the page now
21:51:18 <emilio> kschmi: seems it'd be an option then
21:51:27 <masonf> q?
21:51:28 <emilio> rniwa: <style> seems the more natural thing to do
21:51:32 <astearns> ack westbrook
21:51:35 <annevk> q+
21:51:36 <justinf> justinf has joined #webcomponents
21:51:47 <emilio> ... that way we can do <template> for html, <script> for script, and <style> for style
21:51:50 <justinf> q+
21:52:09 <emilio> westbrook: right now import with syntax is blink-only
21:52:16 <emilio> ... are other browsers opposed to something like that?
21:52:31 <hiroshige> hiroshige has joined #webcomponents
21:52:31 <obuckley> there's an interop proposal for Import attributes (+ CSS / JSON)
21:52:31 <obuckley> https://github.com/web-platform-tests/interop/issues/733
21:52:36 <masonf> ack anne
21:52:43 <emilio> annevk: we do support import with generally
21:52:47 <emilio> ... might not support css yet
21:52:57 <emilio> ... wonder if all browsers handle CSP around that correctly
21:53:09 <justinf> assert was removed from Chrome
21:53:10 <emilio> ... there's also the big syntax change from assert to with
21:53:16 <emilio> ... we're generally supportive
21:53:22 <astearns> "official" support: https://github.com/WebKit/standards-positions/issues/77
21:53:23 <justinf> I don't think Chrome has implemented the fetch destination yet
21:53:34 <masonf> emilio: for what it's worth, same here. Only blocking thing is time to implement it.
21:53:43 <masonf> q?
21:53:45 <emilio> emilio: same, on Mozilla's side, send patches? :)
21:53:53 <emilio> annevk: can I ask something else?
21:53:53 <justinf> q+
21:54:04 <emilio> ... how the specified thing relates to the content
21:54:15 <emilio> ... `specifier=/foo.css` in the slide
21:54:37 <emilio> kschmi: it's putting it into the module map with that specifier being the key
21:54:48 <emilio> ... it's effectively an identifier
21:54:51 <sanketj> q+
21:54:55 <masonf> ack justin
21:54:58 <emilio> annevk: does script support that?
21:55:11 <emilio> justinf: I think it's a great idea to use the script tag
21:55:21 <emilio> ... because this approach applies to anything in the module map
21:55:45 <emilio> ... you want to inline a JS module but still be able to import it from other JS modules
21:56:00 <emilio> annevk: would you want it to execute it in today's browsers or not?
21:56:09 <emilio> justinf: Maybe we add another type
21:56:24 <emilio> ... but you might want this for WASM as well right?
21:56:32 <emilio> ... I think putting this in script is really powerful
21:56:49 <emilio> annevk: isn't WASM effectively a byte sequence? How would that work inline?
21:56:58 <emilio> justinf: dunno, but we have the module graph
21:57:09 <masonf> q?
21:57:26 <emilio> ... if we do it in a way that's potentially compatible with other things in the module graph then it's great
21:57:33 <emilio> rniwa: but <script> can't be nested
21:57:41 <emilio> justinf: you can escape it right?
21:57:59 <emilio> annevk: you can escape the end tag, it's very ugly
21:58:15 <emilio> ... like if you have a backslash before the closing tag
21:58:34 <hiroshige> q+
21:58:41 <annevk> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3E%0Aw(%22%3Cscript%3E%3C%5C%2Fscript%3E%22)%0A%3C%2Fscript%3E
21:58:52 <emilio> justinf: I think it's potentially very powerful and it works beyond CSS
21:59:00 <masonf> ack sanket
21:59:27 <emilio> sanketj: two things seems separate: (1) what elements we use. (2) how does the attribute work
21:59:38 <emilio> ... might be separate discussions, can we scope to one of them?
21:59:47 <masonf> ack hiroshige
21:59:52 <emilio> hiroshige: same feeling
22:00:01 <emilio> ... re how it works, module maps are URL-keyed
22:00:18 <emilio> ... but this is equivalent to specifying the URL
22:00:32 <emilio> ... anyways I think there's ways of making the things consistently work
22:01:04 <emilio> ... if we are to specify an URL, it might also be an option given importmap has a similar ability
22:01:44 <masonf> q?
22:01:44 <emilio> ... here we specify the url in the inline script but is similar to intercept the url request
22:01:44 <emilio> q+
22:02:01 <emilio> rniwa: so you're seing `specifier` is like a url, then what
22:02:13 <emilio> hiroshige: then it looks like intercepting the request
22:02:26 <westbrook> q+
22:02:33 <emilio> ... instead of actually requesting the thing
22:02:56 <sanketj> q+
22:03:00 <dandclark> q+ to talk about multiple imports
22:03:17 <JaseW> JaseW has joined #webcomponents
22:03:31 <emilio> rniwa: so there's a conflict between this and the file that exists (`foo.css`)
22:03:38 <masonf> masonf: there are also timing issues here - if you use the URL/name before it's defined, that could result in a network request.
22:03:39 <annevk> In particular if a script does import "/foo.js" as well, what happens? There might be a race.
22:03:45 <justinf> the "conflict" is useful
22:04:03 <justinf> you want to dedupe between modules that import /foo.css and the inline
22:04:10 <masonf> emilio: what if you request foo.css synchronously and you haven't sent the script tag yet.
22:04:12 <JaseW> present+
22:04:19 <masonf> emilio: do JS modules have an answer for that? Or is this new?
22:04:37 <justinf> we need to break ties here
22:04:50 <emilio> annevk: I think you parse it and insert it in the module map
22:04:56 <emilio> emilio: but you might already have started a fetch
22:05:23 <rniwa> q?
22:05:31 <emilio> dandclark: I think first one should win, and if we parse the inline one after we've tried to fetch we either ignore or fail
22:05:37 <emilio> annevk: either override or fail
22:05:43 <sorvell> q+
22:05:47 <masonf> ack emilio
22:05:50 <dandclark> q-
22:05:52 <emilio> dandclark: don't think we want to override
22:05:57 <emilio> annevk: override and log to console?
22:06:11 <annevk> s/override/bail/
22:06:24 <masonf> ack westbrook
22:06:28 <emilio> westbrook: 2 cents re. element names
22:06:37 <emilio> ... really like the idea of different modules using specific elements
22:06:41 <kzms2> present+
22:06:47 <emilio> ... so <script> for script modules, <template> for html, <style> for style
22:06:56 <masonf> +1
22:06:57 <emilio> ... that opens the possibilities to normalize the attributes
22:07:14 <justinf> what about resources that don't have tags with them?
22:07:17 <emilio> ... so type=module on <style> does the same for style as type=module for <template>
22:07:21 <masonf> <json>
22:07:25 <emilio> ... it has a ceiling which is where do you put the json module
22:07:32 <justinf> a new raw text element?
22:08:01 <emilio> ... because it fails apart I wonder if it makes sense to use <script>
22:08:01 <masonf> ack sanket
22:08:02 <dandclark> q+ To talk about <script> tags and no-JS
22:08:12 <emilio> ... but given that falls apart for <template>...
22:08:21 <justinf> I don't think <script> falls apart with <template>
22:08:25 <emilio> sanketj: perhaps json and script modules should use <script>?
22:08:39 <emilio> ... the other thing is that you can reuse the type
22:08:41 <masonf> ack sorvell
22:08:42 <emilio> ... attribute
22:09:04 <emilio> sorvell: that throws me a little bit because it seems we need a solution for inline modules generally
22:09:08 <emilio> ... even inline JS modules
22:09:17 <emilio> annevk: I think TC39 is working on stuff around that
22:09:27 <masonf> q?
22:09:28 <emilio> justinf: they're working on it with JS syntax
22:09:51 <emilio> annevk: but we duplicate it with script type=inline-module
22:10:26 <rniwa> q?
22:10:27 <emilio> justinf: I don't think it is a duplicate of the module declaration proposal because that gives you an object, not an specifier
22:10:41 <emilio> sorvell: if we have <script> we have inline or out of line
22:10:52 <emilio> ... but if we use <style>, we'd need <link> for out of line styles
22:11:32 <emilio> emilio: you don't need out-of-line modules right? You'd import the url directly
22:12:14 <justinf> we want <script> to be able to load non-JS modules, right?
22:12:20 <emilio> dandclark: you'll be able to do `import "myStyles.css" with { type: "style" }`
22:12:23 <justinf> isn't that how HTML modules are supposed to work?
22:12:29 <emilio> annevk: what if you just have the `<template>` thing?
22:12:38 <justinf> <script type="html" src="/foo.html"></script>
22:12:41 <emilio> dandclark: we'd make the template either trigger the fetch
22:12:50 <emilio> ... leaning not to do that
22:12:59 <astearns> s/"style"/"css"/
22:13:21 <emilio> ... I think it's clearer if the template attribute just pulls from the module map
22:13:48 <justinf> +1 to masonf
22:14:01 <masonf> q?
22:14:09 <masonf> q+ westbrook
22:14:12 <hiroshige> q+
22:14:12 <justinf> q+
22:14:12 <emilio> masonf: There are two different things, `<script>` adds to the module map, and template pulls from it or fetches
22:14:15 <masonf> westbrook I added you to the queue
22:14:21 <emilio> emilio: why would you fetch instead of using `<link>`?
22:14:27 <emilio> westbrook: `<link>` doesn't add to the module map
22:14:37 <emilio> masonf: less typing too?
22:14:48 <masonf> ack dandclark
22:14:48 <Zakim> dandclark, you wanted to talk about <script> tags and no-JS
22:14:55 <emilio> dandclark: I agree these are two separate features
22:15:08 <emilio> ... we can probably do `<template adoptedstylesheets>` consume from the module map
22:15:19 <emilio> ... then figure out if that should do the fetch and add to the module map
22:15:24 <emilio> ... we need to give it some thought
22:15:28 <emilio> q+
22:15:32 <sorvell> q+
22:15:39 <rniwa> q+
22:15:39 <kouhei> q+
22:15:41 <emilio> ... feedback would be great
22:15:44 <masonf> ack westbrook
22:16:05 <emilio> westbrook: I really like the idea that adoptedstylesheets is the declarative syntax with import with type=css and then can be brought to have inline module declarations
22:16:10 <emilio> ... I think that's valuable as a developer
22:16:29 <hiroshige> q-
22:16:42 <emilio> ... not so much about `<link>`, links are not for styling custom elements
22:16:49 <emilio> emilio: you can
22:17:17 <astearns> (disagreements on current reality)
22:17:46 <hiroshige> FYI as for how to name/import inline modules: previous discussions at https://github.com/whatwg/html/issues/7367 https://github.com/whatwg/html/issues/7415
22:18:08 <dandclark> emilio: What's the difference between this <link href> and between requesting a URL in the module map?
22:18:28 <astearns> s/in the module/not in the module/
22:18:29 <masonf> ack justin
22:18:32 <emilio> masonf: we're debating the less useful part of this proposal
22:18:45 <emilio> justinf: I want to reiterate that a huge part of the value is using the module map
22:18:51 <emilio> ... we have CSS modules on the module graph
22:19:10 <emilio> ... being able to deduplicate the styles via the module graph is a critical
22:19:27 <nidhi4> nidhi4 has joined #webcomponents
22:20:21 <dandclark> emilio: I agree with that, but what I was discussing was the difference between if foo.css is not in the module graph -- We were discussing whether this attribute could trigger a fetch. I don't think we want that. If you say adoptedstylesheets=foo.css triggers the fetch, isn't the behavior we have now with <link>?
22:20:43 <dandclark> justinf: But <link> doesn't put them in the module graph
22:20:57 <dandclark> ...We need it to populate the module graph
22:21:20 <masonf> q?
22:21:24 <dandclark> ...Seems OK that having it populate the module graph here is OK.
22:21:57 <dandclark> annevk: Emilio is talking about the case where the module graph is not already populated
22:22:04 <dandclark> justinf: It's the same. You can have race conditions
22:22:13 <dandclark> ...See the request before you have the script tag that defines it
22:22:23 <dandclark> annevk: But then there is something in the module graph
22:22:58 <emilio> dandclark: you suspend and wait until the initial fetch comes back
22:23:04 <emilio> ... you have an empty entry in the module map
22:23:39 <hiroshige> q+
22:24:54 <dandclark> emilio: So I'm clear, the only difference between foo.css not being in module map, and whether we trigger fetch or not here. I want to make it clear that if you hit this, assuming we trigger a fetch, the whole point of that is maybe some JS eventually will import this as a CSS module and it's already there.
22:25:07 <dandclark> ...If you use a link the CSS is there in the browser cache but not the module map
22:25:20 <dandclark> ...And if you were to import it, would have 2 sheets technically
22:25:27 <rniwa> ack emilio
22:25:39 <dandclark> ...Not opposed to triggering fetch but feels like duplicating a lot with link
22:25:42 <justinf> q+
22:25:56 <sanketj> q+
22:26:17 <masonf> ack sorvell
22:26:49 <emilio> sorvell: just a point of understanding, is there a difference with `<link>` with the browser cache? Is that different from the JS module graphi
22:27:24 <dandclark> emilio: It shouldn't trigger fetch
22:27:32 <emilio> emilio: the browser cache exists, but if you disable you most likely don't trigger multiple fetches
22:27:39 <masonf> ack rniwa
22:27:50 <emilio> sorvell: agree this is the less interesting bit but should be supported
22:28:12 <emilio> rniwa: I wonder if we could use a `#` at the beginning
22:28:41 <emilio> ... so that you'd use `specifier="#foo"`
22:28:49 <justinf> qq+
22:29:29 <dandclark> emilio: But I thought we were saying that you should be able to trigger a regular fetch if the entry isn't there already.
22:29:39 <dandclark> q+
22:29:43 <emilio> justinf: it's a feature, not a bug, that it uses the same url map as js modules
22:30:00 <masonf> ack justinf
22:30:00 <Zakim> justinf, you wanted to react to rniwa
22:30:07 <emilio> ... when we do SSR we want to not pull the css if we've sent it already
22:30:17 <emilio> rniwa: wdym with sending the css?
22:30:18 <kschmi0> kschmi0 has joined #webcomponents
22:30:27 <emilio> justinf: you have a module map with mixed css and js
22:31:06 <emilio> ... your server code loads this and tracks the URL and outputs the declarative CSS module using the same specifier as your JS modules use
22:31:07 <westbrook> q+
22:31:17 <emilio> ... that way if you send the JS module to the client it's already in the module map
22:31:34 <emilio> rniwa: that doesn't affect whether you can use a prefix right?
22:31:45 <emilio> justinf: in JS you wouldn't import with a prefix
22:31:50 <emilio> annevk: what's the point of the prefix
22:32:03 <emilio> rniwa: the point is to avoid the confusion between actual files
22:32:08 <emilio> ... and the inline things
22:32:25 <justinf> importmaps let you use bare specifiers
22:32:29 <masonf> q?
22:32:32 <emilio> justinf: but it's not a confusion, it's a feature
22:32:46 <hiroshige> FYI as for how to name/import inline modules: previous discussions at https://github.com/whatwg/html/issues/7367 https://github.com/whatwg/html/issues/7415
22:32:47 <emilio> dandclark: do we want to allow random module specifiers like external domains or something?
22:32:55 <emilio> emilio: should probably be same origin
22:33:11 <justinf> JS imports don't have to be same origin
22:33:17 <emilio> hiroshige: previously has been proposed to use a `:` or some other special URL to separate inline modules
22:33:31 <rniwa> q?
22:33:32 <hiroshige> q-
22:33:36 <masonf> ack kouhei
22:33:46 <emilio> rniwa: I see arguments for both, maybe the overriding with the inline thing is an anti-feature and we don't want that
22:34:03 <emilio> kouhei: was going to say the same thing
22:34:04 <sorvell> q+
22:34:05 <annevk> annevk has joined #webcomponents
22:34:14 <emilio> ... we generally don't want to mix inline modules from fetch modules
22:34:16 <masonf> ack justin
22:34:26 <emilio> justinf: in the use cases we have nobody is writing this by hand
22:34:36 <emilio> ... you have an implementation of web components in js
22:34:42 <emilio> ... which have css imports
22:34:57 <annevk> This seems like it would be the first time we have specifiers in markup, right? It does seem a little confusing.
22:35:34 <emilio> ... so SSR would use this feature and eventually it will be pulled into the JS
22:36:00 <rniwa> q+
22:36:01 <justinf> In JS:
22:36:01 <justinf> ```
22:36:01 <justinf> import styles from './styles.css';
22:36:01 <justinf> class MyElement extends HTMLElement {
22:36:05 <kouhei> q+
22:36:15 <justinf> argh... I won't try write code here
22:36:29 <emilio> sorvell: So I have an SSRd component and a non-SSRd one you want to use the non-SSRd one independently of whether you've SSRd a component before
22:37:05 <emilio> hiroshige: but you could use the prefixed specifier in inline and SSR case if you set up the module map correctly
22:38:09 <emilio> ... you can set it to look the local specified and then the network, or just inline then fail
22:38:20 <emilio> ... same specifier can be used anywhere within a document
22:38:21 <masonf> zakim, close the queue
22:38:22 <Zakim> ok, masonf, the speaker queue is closed
22:38:24 <masonf> q?
22:38:37 <masonf> ack sanketj
22:38:57 <emilio> sanketj: this new specifier (name tbd) is something that we can use to solve declarative modules in general
22:39:23 <emilio> ... specifier should go in <script> / <style> / <template>, and you could use it to put stuff declaratively in the module map
22:39:28 <emilio> ... is that correct?
22:39:29 <emilio> (yes)
22:39:37 <masonf> ack dandclark
22:39:42 <masonf> ack westbrook
22:40:19 <emilio> westbrook: having listened to the questions, could a link tag be aumented to inject the content in the module graph?
22:40:20 <sorvell> https://github.com/tc39/proposal-module-declarations specifies `module name {...}` in JS so this doesn't really work for CSS.
22:40:23 <masonf> ack sorvell
22:40:31 <justinf> So here's an example of JS importing CSS: https://lit.dev/playground/#gist=9ffa049eb690b710ba9e39504c07f931  When we SSR that we want to emit the styles as a declarative CSS module, but when we later load the JS, we want that to load the _same_ CSS module instance.
22:40:37 <emilio> sorvell: I agree this seems like a general module inlining problem
22:40:53 <masonf> ack rniwa
22:40:57 <dandclark> Re: westrbrook, is that <link rel="modulepreload">? https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/modulepreload
22:40:58 <emilio> ... linked above the JS proposal, it's within JS so doesn't work for us
22:41:20 <justinf> q?
22:41:22 <justinf> q+
22:41:28 <emilio> rniwa: the idea that we want to share namespace to solve the general namespace inlining it seems like reinventing importmaps
22:41:41 <masonf> ack kouhei
22:41:41 <emilio> ack kouhei
22:41:47 <rniwa> q?
22:41:52 <masonf> zakim, open the queue
22:41:52 <Zakim> ok, masonf, the speaker queue is open
22:42:17 <emilio> justinf: this is similar to import maps in the sense that it can populate the module graph
22:42:31 <emilio> ... but there's a bit difference because it's also inlining the contents
22:42:38 <emilio> ... but also it doesn't have to come at the top of the file
22:42:55 <emilio> ... which is an important use case because you don't know what elements you're going to render
22:43:10 <emilio> ... so they make them uniquely different from importmaps
22:43:26 <emilio> hiroshige: because of that the importmap is has complex implications
22:43:34 <masonf> q?
22:43:45 <annevk> q+
22:43:55 <kouhei> q+
22:43:57 <masonf> ack anne
22:44:10 <emilio> annevk: afaict we don't have any attrs that have module specifiers
22:44:11 <dandclark> q+
22:44:19 <emilio> ... and it's confusing that it looks a lot like a URL but isn't a URL
22:44:32 <justinf> as part of the import map proposal, we used to talk about the import: prefix for specifiers in HTML
22:44:38 <emilio> ... I understand why JS did that but from HTML perspective it's much less clear
22:44:41 <emilio> q+
22:44:55 <masonf> ack kouhei
22:44:56 <emilio> ... naive assumption would be that you'd just resolve /foo.css and start loading
22:45:05 <justinf> so you could do <img src="import:cool-package/hero.jpeg">
22:45:10 <emilio> kouhei: implementation wise this looks complex
22:45:32 <emilio> ... specially re. failure cases
22:45:34 <masonf> ack dan
22:45:51 <emilio> dandclark: next steps, we have explainers r/n, we want to put it through WHATWG stages
22:46:08 <emilio> ... trying to get those filed and tag people
22:46:09 <emilio> ack emilio
22:46:10 <kschmi0> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ShadowDOM/explainer.md
22:46:14 <masonf> ack emilio
22:58:57 <masonf> masonf has joined #webcomponents
23:01:09 <sorvell> sorvell has joined #webcomponents
23:02:37 <sorvell> #tpachelp
23:03:15 <masonf> present+
23:03:22 <westbrook> present+
23:03:22 <JRJurman3> JRJurman3 has joined #webcomponents
23:03:52 <miriam> present+
23:04:07 <rniwa> rniwa has joined #webcomponents
23:04:10 <JRJurman3> present+
23:04:13 <rniwa> rniwa has changed the topic to: "DOM Parts"
23:04:24 <rniwa> present+
23:04:50 <robglidden> robglidden has joined #webcomponents
23:05:00 <keithamus> lea: not sure I am familiar with the later shape
23:05:06 <eemeli> eemeli has joined #webcomponents
23:05:07 <keithamus> masonf: slides are an overview?
23:05:19 <keithamus> justinf: this is a template API, another motivation for DOM parts.
23:05:25 <keithamus> scribe+
23:05:28 <keithamus> present+
23:05:36 <tomayac> tomayac has joined #webcomponents
23:05:43 <sorvell> present+
23:05:47 <eemeli> present+
23:05:52 <tomayac> present+
23:05:52 <TabAtkins> TabAtkins has left #webcomponents
23:05:56 <keithamus> rniwa: chromium prototype first?
23:06:14 <sorvell> Lea what happened to "Integrating UI components is too damn hard!"?
23:06:19 <keithamus> masonf: two links - imperative & declarative. Implemented majority of both
23:06:25 <rniwa> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts-Imperative.md
23:06:25 <rniwa> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/DOM-Parts-Declarative-Template.md
23:06:28 <lea> @sorvell: It was in the previous slot!
23:06:39 <keithamus> ... general concept: dom parts marks node in tree, retrieve reference to those with imperative API
23:06:52 <keithamus> ... node part marks node, attribute part marks attribute child node part marks a range of nodes
23:07:02 <lea> present+
23:07:17 <keithamus> ... there is an imperative API for constructing node part, it'll be marked in the DOM tree and you can keep track as it moves around
23:07:27 <keithamus> ... similarly for child nodes & attribute
23:07:51 <keithamus> ... more interesting is declarative syntax. You can opt in with parseparts attribute, within that subtree {{}} mustache syntax will give you a part created there
23:08:08 <keithamus> ... {{}} within attribute or within a node you'll get a attribute or node part respectively
23:08:24 <masonf> {{#}} dsfsdf {{/}}
23:08:39 <keithamus> ... child node part delimiters
23:08:53 <keithamus> ... it looks like the explainer is outdated vs implementation
23:09:11 <keithamus> ... this is all subject to bikeshedding but the takeaway is the concepts. Child node part is between two markers
23:09:17 <keithamus> ... that's the broad strokes.
23:09:29 <sorvell> @lea are there minutes available somewhere?
23:09:39 <keithamus> ... How do you use those parts? You can do it on template element or document fragment to getPartRoot() - then ask that for its parts.
23:09:53 <keithamus> ... so if you have a template you can get the parts without traversing
23:10:02 <keithamus> ... value proposition being the parts are kept track of by the browser
23:10:12 <keithamus> rniwa: did you add clone with the parts?
23:10:39 <keithamus> masonf: yes. You can clone a tree and get parts attached that were attached to the original tree. So you get a stamped out copy where you know where all the parts were
23:10:45 <sorvell> @lea thanks so much
23:10:53 <keithamus> masonf: they're kept track of as the browser goes through them
23:10:56 <sorvell> q+
23:11:46 <keithamus> masonf: Various teams in google have tried this out. How ergonomic/performant. Interesting thing is perf is tough. One possible competing technique is a compiled framework can do firstChild nextSibling which can get the nodes very fast.
23:12:12 <keithamus> ... trying to replace with DOMparts can be challenging compared to compile ahead. At best its on par, at worst its slower
23:12:48 <keithamus> ... there are other perf tradeoffs. You attach parts to interesting nodes - there is a question about if you want to keep track of dom mutations. Should I keep track of where the part went? If so it takes work and slows parts of the browser down
23:12:55 <keithamus> ... if you don't then its less useful
23:13:32 <keithamus> tomayac: declarative shadowroots? with stamped out content? Would it be clonable and work?
23:13:36 <justinf> q+
23:13:37 <keithamus> masonf: yes
23:13:59 <keithamus> tomayac: if you have the same DSD several times on the page would it be copied?
23:14:02 <lea> q?
23:14:05 <lea> q+
23:14:06 <keithamus> masonf: this does not solve the duplicate DSD problem
23:14:12 <keithamus> tomayac: could it?
23:14:25 <sanketj> q
23:14:30 <sanketj> q+
23:14:33 <keithamus> masonf: it just requires additional synax
23:14:37 <masonf> ack sorvell
23:14:38 <keithamus> ... it may be orthogonal
23:15:04 <masonf> qq+
23:15:10 <keithamus> sorvell: ask more about perf: initially the hope we could justify on the basis of building block of more interesting things, but also justifable on its own if it improves perf
23:15:27 <keithamus> ... creating DOM with template is really fast. But you're saying this isn't a win?
23:15:51 <keithamus> ... assuming we build other features, have you looked at how much perf we give up in more complex cases?
23:16:06 <keithamus> ... With the minimal feature set is it a few % or twice as slow or something?
23:16:37 <keithamus> masonf: I think this is an ergonomic win and JS size win. The perf tradeoff is you cant make it a lot slower. So its a no-go. I don't think its a perf win but perf parity.
23:16:49 <rniwa> q?
23:16:49 <keithamus> ... that's tough to do
23:17:38 <keithamus> Thomas Nguyen: I think direct compiled approach is a stragegy that no one does. Theoretical limit. Compared to other frameworks this did better. Some signal that there's some promise here.
23:18:13 <keithamus> ... even compared to direct compile its like the same line. It sometimes did better.
23:18:26 <keithamus> masonf: the best best numbers were where nodes weren't even tracked?
23:18:30 <masonf> acl mason
23:18:34 <masonf> ack mason
23:18:35 <Zakim> masonf, you wanted to react to sorvell
23:18:35 <keithamus> Thomas Nguyen: The general one seemed fine
23:18:55 <masonf> ack justinf
23:18:58 <masonf> ack lea
23:19:09 <keithamus> justinf: its not just perf, but if perf is at parity that's awesome.
23:19:36 <keithamus> lea: I wanted to talk about a different point - the syntax. It's the double curlies. But without a way to override that - how do you combine that with tools like eleventy
23:19:36 <rniwa> q?
23:19:40 <keithamus> qq+
23:19:43 <rniwa> q+
23:19:53 <keithamus> lea: how do you generate templates with something like that? Turn off the pipeline?
23:20:09 <justinf> q+
23:20:29 <keithamus> keithamus: you can configure this in lots of tools like 11ty, mustache
23:20:37 <keithamus> lea: so why not both? Why not configure this in the browser?
23:20:39 <lea> expressions="{{ }}"
23:20:43 <keithamus> like this^
23:20:51 <lea> expressions="{ }"
23:20:54 <keithamus> s/like this^ /lea: like this^
23:20:59 <lea> expressions="[ ]"
23:21:04 <keithamus> lea: or something like this ^
23:21:07 <westbrook> <meta name="dompartdelineator" value="!magic! !/magic!" />
23:21:16 <masonf> qq+
23:21:20 <keithamus> ... you could put it on ancestors, subtrees; double curlies by default.
23:21:28 <keithamus> ... would it make it harder to implement?
23:21:53 <masonf> ack mason
23:21:53 <Zakim> masonf, you wanted to react to lea
23:21:57 <keithamus> masonf: nothing fundementally. This already requires an attribute so we could extend that but there are strange things, e.g. angle brackets could be bad.
23:22:03 <keithamus> ack keithamus
23:22:03 <Zakim> keithamus, you wanted to react to lea
23:22:08 <masonf> ack sanket
23:22:29 <westbrook> q+
23:22:40 <keithamus> sanketj: dynamic scenarios; attach parts and the thing follows you around. Are there use cases to set a part and move it elsewhere? Is there something interesting with SSR?
23:22:55 <keithamus> masonf: I didn't get much feedback when we removed this feature - so I think its peripheral
23:23:02 <keithamus> justinf: ???
23:23:14 <keithamus> sanketj: is it useful to do that? The context might be different
23:23:25 <keithamus> masonf: if you change orders... ???
23:23:38 <keithamus> justinf: once you've got the list of parts you just use that list. I've never seen that.
23:24:01 <keithamus> sanketj: in EdgeHTML we had this thing; cling, it would follow you around - we looked at removing it
23:24:06 <masonf> q?
23:24:10 <keithamus> masonf: all of our benchmarks were write-once read-once
23:24:11 <masonf> ack rniwa
23:24:32 <keithamus> rniwa: one interesting thing to explore is whether full template instantation would have any perf improvement over existing solutions
23:24:53 <keithamus> ... another point is reducing JS that every website ships is generally a good idea. Removing a bunch of script for lib+frameworks is probably a win
23:25:21 <keithamus> ... I think going back to the delimiters being configurable - it would complicate the implementation and I worry if it would be as performant as the non-configurable one
23:25:26 <eemeli> q+
23:25:42 <keithamus> masonf: having an impl I don't disagree but I bet it comes pretty close.
23:26:07 <keithamus> justinf: Can I talk about JS template API?
23:26:08 <rniwa> q?
23:26:28 <rniwa> ack westbrook
23:27:10 <keithamus> westbrook: Glad perf is on par. Dom parts that leads onto templating unlocks - when people ask for custom elements, shadowdom, open styleable. What they want is templating. They sometimes don't even want slots. Just templating.
23:27:28 <sorvell> q+
23:27:29 <keithamus> ... as this gets all the way through to template instantiation are we getting enough of a non negative to drive this?
23:27:38 <keithamus> ... this would relieve other areas.
23:27:58 <keithamus> ack justinf
23:28:11 <westbrook> ack eemeli
23:28:30 <keithamus> eemeli: much same qs as westbrook - whats the positive driving force behind dom parts. If not perf, ergonomics? What is the reason we _should_ vs should not.
23:28:41 <keithamus> ... all the things that can be done with DOM parts can be done now, but with some JS
23:28:44 <iteriani> iteriani has joined #webcomponents
23:28:55 <keithamus> ... so why do we need this new way of doing this thing? What it selling this?
23:29:42 <keithamus> sorvell: I agree with westbrook on templating. We need a light dom slot solution and no one agreed. Templating might be it
23:29:51 <rniwa> q?
23:29:57 <rniwa> ack sorvell
23:29:57 <keithamus> ack sorvell
23:30:12 <keithamus> justinf: DOM parts is the low level api... but *presents slides*
23:30:26 <iteriani> we need a solution that framework owners can incrementally adopt
23:30:39 <justinf> https://docs.google.com/presentation/d/1vioNq2sVzWbbRUsHt4EOkdZ0RUjEOfNE2jlMIcKZrZc/edit?usp=sharing
23:30:52 <iteriani> and then build up so that frameworks can share rendering solutions instead of fighting over js-framework-benchmark until 2050
23:32:44 <sorvell> there's also a nuanced performance argument related to bytes over the wire: dom parts: "template + render data + other" v. today: "all rendered html + render data (used in hydration) + other"... where dom parts is less bytes.. maybe?
23:36:05 <sorvell> q+
23:37:07 <eemeli> q+
23:38:22 <sanketj> q?
23:39:05 <keithamus> sorvell: I want to make sure people understand the motiviation for a JS api for generating html; why wouldn't you just in JS create the HTML to produce the right stamped output
23:39:40 <lea> q?
23:40:01 <keithamus> justinf: convenience over DOM parts API - delims have real expressions in them, so similar to eg JSX. But the DOM parts have no expressions. You're delocating expressions from where they belong. Then you have to get the parts and fill them
23:40:42 <keithamus> sorvell: isn't it also the case that the expressions in DOM parts are empty? This is the crux of the issue - once you put some identifier in HTML that's an expression all of a sudden you've got a DSL. You sidestep the whole issue by using JavaScript.
23:41:54 <obuckley> like a list of "card" components on a products page
23:42:02 <obuckley> and provides a nice SSR API
23:43:28 <eemeli> qq+
23:45:07 <keithamus> eemeli: I really like the html tagged template literal idea. I presume though that the tagged template is that it would return HTML
23:45:20 <keithamus> eemeli: it can hide all of the magic but give me a documentfragment
23:45:34 <keithamus> ... it doesnt support DOM parts but I would argue it gives better utility
23:45:50 <keithamus> justinf: you need to have an intermediate representation so you can render multiple times
23:46:24 <rniwa> rniwa has joined #webcomponents
23:46:47 <keithamus> justinf: you cant render in two places
23:46:50 <keithamus> rniwa: we're over time
23:47:34 <keithamus> justinf: i had a slide on JSX and whatabouts. If JS ever added JSX you could produce the same template result
23:47:43 <keithamus> ... or functions that produce templateresults
23:49:03 <keithamus> Zakim, close queue
23:49:04 <Zakim> ok, keithamus, the speaker queue is closed