The output of element and svelte:element styles are inconsistent

[Serator]

Describe the bug

The output of the same styles in div and svelte:element this="div" is different.

Very similar to #15309.

Reproduction

Svelte 5.33.18 ❌

Severity

annoyance

[maxmmyron]

What is the intended behavior here? Should styles always be normalized?

It seems like in all cases other than regular elements with string styles (e.g.: <div style="color:red; something:else;"></div>), the styles are normalized (invalid properties removed, colors transformed to rgb, etc.).

[Serator]

What we have here is not quite normalization (IMHO). Here's a more extended example. SSR will output color:red;position-area:top center in all 3 cases. But, for example, in Firefox, which does not currently support CSS position-area property in the stable version will output this:

Whereas Chrome will output this:

I suppose the various polyfills will also end up broken in case there is nothing to pollfill in the final HTML, but I haven't tested this.

Personally, I would like to see the source code in all use cases, so the original “color bug” that started it all had to do with the fact that I couldn't understand why the final code was different from the source. It turned out that svelte:element had been used.

[7nik]

Aside from the outputs not being exactly the same, what is the issue? What does it break?

Edit: elaboration about the current behavior: on SSR there is basically no other way to output the input styles as is. Then the styles get hydrated. Then, subsequent style changes get applied via elem.style.cssText or elem.style.setProperty as the most performant ways, but updating the style attribute is left to the browser. In the case of svelte:element because it's impossible to change the element's nodeName, it always created from scratch. So it's wasteful setting style attribute that likely will be overwritten by more fast elem.style.cssText.

[Serator]

Aside from the outputs not being exactly the same, what is the issue? What does it break?

Nothing at the moment. The issues I see:

• Differences in output are small things and can be tolerated in favor of performance.
• It makes more sense to me that if a CSS property is not supported (perhaps due to a typo in writing the property or its value), it is quietly rejected and you won't see a warning like this in the developer tools (repro):

• Another little thing I noticed is that if you rely on the presence of the style attribute, Svelte will not create a class to apply styles locally (e.g. svelte-2izka1) in case the entire CSS property in the style directive is invalid. This is easier to see in this example, where styles are not applied to the middle div.

• There may be issues with CSS polyfills, but I haven't researched this issue.

[7nik]

Svelte will not create a class to apply styles locally (e.g. svelte-2izka1) in case the entire CSS property in the style directive

It's a bug, opened #16162

CSS polyfills

I see only a decade old polyfills. And basically never heard of them, probably because many properties impossible to polyfill, many others are heavy ( = laggy site), plus looking dynamically added classes and styles. So no wonder they didn't lift.

[Serator]

Since #16162 looks like the only thing that, in theory, is realistically fixable right now, I'll close this issue. Thanks.