Critical Usability Issue: Flash of unstyled content in `@builder.io/sdk-svelte` due to Mitosis translation bug about builder HOT 13 CLOSED

This is actually kind of doubly worse, because the exact same issue is occuring with Script tags, but these seem to be replaced before the browser starts executing

<script context="module"></script>
<script>export let scriptStr;
export let id = undefined;
</script>

<svelte:element this={"script"} {id}>{@html scriptStr}</svelte:element>

from builder.

@samijaber awesome looks to be working now

from builder.

@samijaber do you have any ETA for when this might get fixed? It's probably affecting every svelte site using builder.io and preventing our organisations projects from adopting it.

Thank you in advance

from builder.

@samijaber happy to attempt giving this a PR if you can point me in the right direction

from builder.

Hey @AlbertMarashi, thanks for filing this bug. We are still looking into the issue and will report back when we have an update.

from builder.

@AlbertMarashi We fixed a styling bug in the latest SDK: v0.6.3

I believe it should fix your issue. Could you test it and let me know?

from builder.

Hi @samijaber

No unfortunately it did not fix the issue the issue arises from this mitosis component being improperly converted to Svelte code

The output of the component looks like this:

<script context="module"></script>

<script>export let styles;
export let id = undefined;
</script>

<svelte:element this={"sty" + "le"} {id}>{@html styles}</svelte:element>

The particular issue is this section {@html styles} - Svelte is adding a HTML comment inside the CSS which is not valid CSS and breaks parsing.

The reason for this I assume is that svelte expects the @html to be rendering HTML and not CSS, and uses these comments to manage hydration (removing and adding HTML nodes between the inserted <!-- HTML_TAG_START --> and comment nodes

There's a few ways to correctly approach this in svelte:

<script>
export let styles;
export let id = undefined;
</script>

{@html `<style id="${id}">${styles}</style>`}

Or:

<script>
export let styles;
export let id = undefined;

$: style_tag = `<style id="${id}">${styles}</style>`;

</script>

{@html style_tag}

Or

<script>
export let styles;
export let id = undefined;
</script>

<svelte:element this="style" {id}>{styles}</svelte:element>

from builder.

sveltejs/svelte#9341 I created an issue for this in Svelte but I believe this is a mitosis bug rather than a Svelte bug (although svelte should be warning about this or something)

from builder.

here's an example of the approach @AlbertMarashi mentioned above https://svelte.dev/repl/0c0942ba74b74d82a2f19c024053775a?version=4.2.2

Note: to ensure svelte preprocess does not pick up the style tag, it also has to be broken up/escaped in string literals, there are several ways to do this, eg the + concatenation in the original mitosis output or putting parts of it in a template expression.

from builder.

And maybe even more important:

Svelte does not sanitize expressions before injecting HTML. If the data comes from an untrusted source, you must sanitize it, or you are exposing your users to an XSS vulnerability.

https://svelte.dev/docs/special-tags#html

If mitosis emits code that allows untrustred/unescaped content in script or style tags this way, it should be documented.

from builder.

@samijaber this seems to be like a major show stopper from anyone seriously adopting builder.io for SvelteKit websites, having FOUC is a relatively large SEO & accessibility issue, not to mention this issue is also prevalent in <script> tags because it uses a similar mitosis component

from builder.

@AlbertMarashi we have found the fix and are doing some final testing. A new version without the issue will be released very soon.

from builder.

Version 0.6.4 of the Svelte SDK should have a fix for the FOUC. SSR'd content should now have styles rendering properly.

We added a bunch of testing that shows styles working. I am going to mark this issue as closed, but feel free to comment/reopen if you see otherwise.

from builder.