We’re using BEM and host selectors like :host(component-name) to prevent collisions. I guess you could include something like tailwind if you want the utility class approach. But you’d probably need :host() and ::slotted() at some point

To avoid FOUC, we have all of the elements set to visibility: hidden in the global document, then the shadow DOM stylesheet will override that and make them visible.

For any elements CSR'd after page load, we use that same stylesheet as a CSSStylesheet (or <style> if browser doesn't support)

As mentioned in another thread, we're using a link tag pointing to an external stylesheet. For build simplicity and caching, we have one stylesheet for the entire component library. So browsers should only fetch the stylesheet for the first component.

Making a custom element submit forms like <button> elements, without JS. I've encountered this issue a bunch working in e-commerce.

Oh I didn’t realize that. When you say checking whether the 2 are the same, is it comparing strings of HTML? I’ve been a little paranoid about perf ramifications of morphdom, but haven’t found a better solution. (Other than managing shadow DOM with imperative JS)

I’m not super familiar with lit-html source code, but doesn’t it have its own diffing logic?

I just worked on a mustache + morphdom combo integration with ReactiveElement at work. Seems to be working well, but not battle-tested yet

Not 100% what you're looking for, but there's some interesting nuggets here github.com/ChrisShank/p.... My favorite takeaway here is annotating the markup with "event intentions", and then orchestrating the events in single place via event bubbling.

Would a combo of morphdom/idiomorph and an HTML templating lib (mustache, handelbars, pug, etc) work? Not quite clear on what the workflow would be for integrating a reactive library with markup it didn't make 🤔

Now importNode and cloneNode have the same performance in Chrome: issues.chromium.org/issues/37124...

I'm happy frameworks can get simpler, but also because Lit, which always uses importNode, probably just got faster too.

Filing issues for browser implementation bugs is a good thing for everyone!

We’re currently using Mustache, and we have a PHP compiler for it on the server and a JS compiler on the client. You only really need a string of HTML, and you can configure your JS bundler to create a loader for your template files.

Is the public api React/Svelte components, each which render a web component with declarative shadow DOM?

Was that ever a requirement/consideration for the previous React library?

Curious about SSR and if that ever came up as a requirement. It’s been a critical requirement in my experience in web and e-commerce, so I’m a bit surprised that it’s all client-side Preact. Though my assumption could be wrong!

Also not using Lit styles. (We're maintaining our own server integrations for injecting DSD and styles.) Is the async batching part of the prop/attr bookkeeping? What Lit does for that is great, but I'm thinking about whether a different implementation without asynchronicity would be better for us