issue #1748 - Custom elements light dom, open / closed

[crisward]

trafficstars

This is based on the pull request #4073 and issue #1748

The idea is to allow web components to render to light dom. As this may be something you don't want to do for all components within an app the option is included as part of the svelte:options tag.

<svelte:options tag="my-app" shadowdom="none" />

For completeness I've also included

<svelte:options tag="my-app" shadowdom="none" />
<svelte:options tag="my-app" shadowdom="open" />
<svelte:options tag="my-app" shadowdom="closed" />

The main reason I have for needing light dom is to be able to create forms which auto-complete correctly as this currently doesn't work with shadow dom in chrome and safari. Though there are open tickets for this with the browsers. (eg https://bugs.chromium.org/p/chromium/issues/detail?id=746593)

If the tag is set to shadowdom="none" the css is processed as though it's a svelte element with the class addition and hashes, which gives some level of encapsulation even with light dom.

Outstanding on this is slots. Not sure how these can be handled with light dom as Sveltes html is being appended to the innerHTML of the tag, as opposed to transposing the existing html into the slot. Lit-element just says if you don't use shadowdom you can't have slots or encapsulated css - (https://lit-element.polymer-project.org/guide/templates#renderroot). As svelte already simulate slots, it'd be nice to get this to work. Any pointers would be gladly received.

[crisward]

Removed the WIP as I've added some tests and manually tried this out. Adding slots to lightdom web components is probably worth doing as a separate PR as this feature is pretty useful as is. Not sure how useful the closed option is, but it's at least complete that way.

This doesn't break, only adds to the api. Could add to the docs too if that helps.

Welcome any feedback. Also thanks to @fsodano for starting this off. Wasn't sure how to add to his PR so opened this one instead.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vospascal]

any clue wy this great addition is not merged yet? some extra work on webcomponent/custom-elements on the svelte side of things would realy help move a lot of people to this stack

[crisward]

@vospascal I wrote a wrapper to help with this - https://github.com/crisward/svelte-tag which may help as a stop gap. It has simulated slots for light dom too.

[vospascal]

@vospascal I wrote a wrapper to help with this - https://github.com/crisward/svelte-tag which may help as a stop gap. It has simulated slots for light dom too.

@crisward yea i saw that thnx, but would be nicer to have that fixed in svelte ;-) im trying to find out what issues are still open when it comes down to custom-elements in svelte

[javadude24]

I love everything about Svelte & SvelteKit but this restriction on custom element always using shadow dom. In order to build the large system i am designing, and pushing Svelte as the preferred choice for web components, it has to allow global inheritance of styles. Why is it taking so long to get this option? what is the issue?

[sreimchen]

Would be awesome to see more support on this important topic (in my opinion atleast). To use Svelte/SvelteKit components in a framework agnostic manner I do not see any other (effective) way than the use of Custom Components (Webcomponents). But since Shadow DOM limits the feature set of those components the developer should have the choice of the output target (here light DOM and open Shadow DOM). Since there is so much discussion going on (since about 4 years now) there should be viable options or atleast very good reasons against implementing those changes... love Svelte but this aint fun :/ I know @Rich-Harris has his concerns about this (and I agree with many statements) but there seem to be other reasons that block progress on this topic that I do not find. May someone help me understand? Are there other possible ways to build a highly reactive framework agnostic UI library with Svelte or SvelteKit (e.g. output: package)?

[patricknelson]

Echoing what I said on #1748:

For those watching this issue but not already aware, it appears this is slated for implementation in Svelte v4 via #8457! 🎉 It appears that migration from @crisward's svelte-tag library above to Svelte v4's custom elements implementation should be fairly minimal, so in the meantime, I'll be using that.

As an extra note here: FWIW, it appears that closed will not be an option, simply open (default) and none via the <svelte:options ...> tag @crisward mentioned above. https://github.com/sveltejs/svelte/pull/8457/commits/840a7bed4b613dfe48f595550f296b45a8ee033c#diff-dddd19094e9a8a1a9455380d8f15f55cd091bc6013e4f4fe7ca7ce13a6888ac8R558

[dummdidumm]

Closed via #8457, to be released in Svelte 4

[patricknelson]

p.s. on @crisward's last point above on the light DOM:

Outstanding on this is slots. Not sure how these can be handled with light dom as Sveltes html is being appended to the innerHTML of the tag

After some work, svelte-retag supports Svelte slots in the light DOM (along with a few other useful features). 🙂 In this case, the solution is to wrap the rendering of the Svelte component and separate it out from the slots (along with some other fancy footwork).

I'd be interested in hearing whatever feedback you might have if any of you happen to have a chance to try it out.