Custom Tag names (e.g. foo-menu-item, foo-carousel-item)

[jorenbroekema]

Similar to #705 but it's pretty old and got closed.
While it's nice that we can import just the class and register with our own tag name, it doesn't really fix the issue that there's a lot of hard coupling in components with other components' tag names.
Examples:

• sl-menu inside sl-dropdown
• sl-menu-item inside sl-menu
• sl-carousel-item inside sl-carousel

While I appreciate that Shoelace is mostly made extendible through CSS parts and theming, there are often use cases for extending the class, creating overrides or additions. While you can still use the original tag name, there's use cases for using a different tag name, for 2 reasons for me personally:

• We just like creating a CE name that fits our brand, we certainly could stick with sl-comp-name but what if we don't want to?
• Scoped Elements, this is still very relevant in 2025.

Suggestion

Elements that have some kind of coupling to other CE names to use an overridable (protected accessor) getter that returns a map of CE names (below is just pseudo code to illustrate):

class ShoelaceMenu extends LitElement {
  protected get elementMap() {
    return {
      menuItem: 'sl-menu-item',
    }
  }
  
  // example private method that's using the map, e.g. to find the active menu item or whatever
  private getMenuItems() {
    return [...this.shadowRoot.querySelectorAll(this.elementMap.menuItem)];
  }
}

Then the extender can do:

class FooMenu extends LitElement {
  protected get elementMap() {
    return {
      // could also query the scoped elements registry for it rather than hardcoded
      menuItem: 'foo-menu-item',
    }
  }
}

<foo-menu>
  <foo-menu-item></foo-menu-item>
</foo-menu>

Let me know if you'd be interested this, I'm happy to start a PR, maybe for 1 component per PR at a time to keep things easy to review, maybe to a specific branch until we finish it for all comps that require it?

[schilchSICKAG]

I think this is really interesting. However, it does not work out completely because there are also occurrences of components directly in the render function, e.g. https://github.com/shoelace-style/shoelace/blob/next/src/components/breadcrumb/breadcrumb.component.ts#L96. You would have to use dynamic rendering for each of those cases :(

[claviska]

This, and there are other challenges I've faced in the past with a similar project trying to "scope" elements that will add burden for us as maintainers without adding any value for the majority of users.

I think the right strategy is to wait until browsers support a stable version of the scoped custom elements registry. I recall hearing a browser experimenting with it recently, but IIRC there's still no specification, just @justinfagnani's proposal which is also linked from Chrome's Platform Status page.

While I appreciate the utility of being able to scope custom elements, in my experience, this feature is usually requested to support microarchitectures. (I'm not suggesting this is your use case, but it seems to be the most common.)

The problem with microarchitectures is they tend to make user experiences worse by shimming in multiple versions of the same library onto a single page so developers can build apps in silos without fear of conflicts. This results in bigger bundles, longer load times, and visual + behavioral differences.

I don't think Shoelace or Web Awesome should facilitate such a pattern as a solution for, let's call it, poor software architecting.